The system still works.That is exactly why it is risky.
Bring an ageing Java system up to date without a big-bang rewrite, while it keeps serving the business that runs on it.
Somewhere in your organisation there is an application nobody wants to touch. It handles orders, invoices, planning or customer data every day. It runs on a Java version that stopped receiving security fixes years ago, it is deployed by hand by the one person who remembers how, and every change takes longer than the last because nobody dares to change anything else. Replacing it outright has been discussed more than once, and shelved every time, because the business cannot stop while a new one is built.
Experus modernises that system in place. The existing behaviour is pinned down with tests first, the runtime, frameworks and dependencies are brought to current supported versions one module at a time, and deployment, monitoring and backups are automated so the application stops depending on individual memory. Users keep working throughout; each stage ships to production on its own and can be paused before the next one starts.
The result is not a new system with new bugs and a retraining programme. It is the system your people already know, on supported software, with a release process any engineer can run and a codebase your next hire can read. Where a genuine rewrite of a component is the cheaper option, you will hear that in the assessment, with the reasoning written down.
When this is the right fit
- Your application runs on a Java or Spring version that no longer receives security updates, and your auditor or insurer is asking.
- One person knows how to build, deploy or debug the system; a holiday or resignation would block every fix.
- Every change takes weeks of manual regression testing because there are no automated tests, so small requests queue up for months.
- The database has grown organically for a decade: unused tables, undocumented columns, triggers nobody understands, and a schema that fights every feature.
- You want to move the application to containers or the cloud, but it still expects a hand-configured server and local files.
What you get
A written assessment and phased roadmap
An inventory of what the system contains, risks ranked by likelihood and impact, and a staged plan with an estimate per stage that states its assumptions. Every stage is independently useful.
A safety net of tests around existing behaviour
Characterisation tests written against what the application does today, before anything changes, as JUnit tests run on every commit. If an upgrade changes a calculation or report, the tests tell you before your users do.
Current runtimes, frameworks and dependencies
Java on a long-term-support release, Spring Boot on a supported version, and third-party libraries brought forward and scanned for vulnerabilities in the build. Done module by module, each step verified in production before the next.
Repeatable builds, deployment and monitoring
The application packaged as a Docker image, built and deployed by CI/CD rather than by hand, on Kubernetes or a plain container host as your scale justifies. Monitoring, alerting, logs and tested backups are included.
A cleaner data layer with rehearsed cut-overs
Versioned PostgreSQL schema and data migrations, rehearsed against a copy of production, with a documented rollback for every cut-over. If the system sits on another database, the assessment says whether a move pays off.
How it works
Assess
Experus reads the code, database and deployment set-up and talks to the maintainers. You receive a written report and phased roadmap.
Stabilise
Before any upgrade, the build is made reproducible and characterisation tests cover the behaviour that matters. The system stops depending on one person.
Modernise in stages
Upgrades land one module at a time, each verified in production before the next. A monolith is split only where it pays for itself.
Hand over or stay
After each phase the code, pipelines and documentation sit in your accounts. Your team takes over, or Experus stays on for the next phase.
The stack behind it
Kotlin & Java
Spring Boot
PostgreSQL
React & TypeScript
Docker & Kubernetes
CI/CD
Monitoring & alerting
Hetzner, AWS, Azure & DigitalOcean
Typical engagement
An assessment that maps the risks and a phased roadmap, then delivery in stages you can pause between while the existing system keeps running. The assessment is fixed-price with a written report as its deliverable; each subsequent phase is estimated separately, with its assumptions attached, so you commit to one stage at a time rather than to the whole roadmap. Phases are billed per day worked, within a cap agreed in writing.
Questions you might have
How is this priced? A rewrite would come with one number.
The assessment is a fixed price with a written report as its deliverable. Each phase of the roadmap is then estimated on its own, with the assumptions written down, and you decide whether to proceed one phase at a time. That is deliberately different from a single number for a rewrite: it keeps the largest unknown, the size of the job, from being guessed up front and paid for in surprises later. The system keeps running throughout, so there is no period in which you are paying for two systems at once. Each phase is billed per day worked, within a cap agreed in writing, and once the system is modernised it can stay with Experus under a monthly retained agreement.
Who owns the code, the pipelines and the infrastructure afterwards?
You do. The code lives in your repositories from the first commit; intellectual property in the delivered work transfers to you on payment. Everything runs in your cloud or hosting accounts and is documented in plain language; there is no Experus-owned tooling, licence or hosting layer in the middle. If you decide to bring the work in-house or to another supplier, they inherit a system with tests, a working pipeline and a written design, not a dependency on Experus.
What happens if the Experus engineer is unavailable, or the relationship ends?
The work is done in a way that assumes exactly that: every change is in version control with a readable history, the build and deployment are automated rather than remembered, and the design decisions are written down as they are made, so any competent Java or Kotlin engineer can pick the system up from the repository and the documentation. Every engagement has agreed dates in writing; if those cannot be met you are told immediately, with the choice to reschedule or to stop and pay only for what has been delivered. Work in progress lives in your repositories and your accounts from day one, so nothing is lost on a laptop. If the engineer on your project is unavailable for longer, a trusted specialist from the Experus network can step in, with your agreement.
How long does it take?
It depends on the size of the system, how far behind it is and how much of its behaviour is documented, and the honest answer only exists after the assessment. What can be said in advance is how the time is spent: the first stage, making the build reproducible and putting tests around the existing behaviour, is the foundation everything else stands on, and it is also the stage that makes the system safer to leave alone if you have to pause. Upgrades then land in production module by module, so you see progress in your own environment throughout rather than waiting for a single go-live.
Find out what the system is really carrying
Describe the application, roughly how old it is and what worries you about it. Experus will reply with a few questions and, if it fits, a proposal for an assessment. No obligation, and a clear answer if a modernisation is not the right move.