The system still runs the business and nobody wants to touch it. Work that moves it onto something maintainable a piece at a time, with behaviour proven unchanged at each step.
Somewhere in your estate is a system everyone works around. It has not been replaced because the person who understood it left, the vendor stopped answering the phone, and the rules that keep the invoices correct live only in code. A rewrite sounds clean until you cost the parallel run and the freeze it needs. The quieter route is to establish what the thing really does, pin that down in tests, and move capabilities out one at a time while it keeps running.
Build the replacement alongside, in full, then switch over on a chosen date. It is honest about the end state and easy to fund as one project.
A stable interface goes in front of the old system, then capabilities move behind it one at a time, with both paths live until the new one is trusted.
Modernisation is a decision per capability. A system is rarely uniform: the pricing engine may be worth rebuilding while the batch that posts the ledger should be left exactly as it is. So the route gets chosen per capability rather than for the whole estate, and a single programme usually runs two or three of them at once.
Some systems should be left alone, and it is worth saying what one looks like. It is stable, the rate of change against it is close to zero, it runs on hardware and an operating system that are still patched, and the cost of its existence is a licence rather than a queue of blocked work. A system like that is a paid-off asset rather than technical debt, and touching it buys you nothing.
Encapsulate, re-host, re-architect, rebuild. The choice between them is mostly economics: how often the capability changes, how well anyone understands its behaviour, and what the business would lose in the hours it was unavailable.
The order matters more than the tooling. Nothing moves until the current behaviour can be demonstrated, because a migration you cannot check is a rewrite with extra steps.
We work through the code, the schema, the jobs and the traffic it serves, separating what is used from what merely exists. You end up with a map of the system and a list of the behaviours any replacement has to reproduce.
Characterisation tests capture what the system does today, correct or not, so a change in behaviour later shows up as a failing test rather than a support call. You review the suite and mark which behaviours are deliberate and which are bugs you live with.
Before anything moves, the system needs places where traffic can be redirected and compared: an interface at the boundary, routing in front of it, and enough logging to tell the two paths apart. This is where the architecture decisions get written down, alternatives included.
One capability moves at a time. Both paths run against real traffic until the new one matches, then the old is switched off and its code deleted rather than left to rot as a fallback. Each slice ships and reverses on its own.
The last slice is not the end of the job. Runbooks, dashboards and on-call procedures ship with the system, and the people who built it are the ones who write them. You finish holding something your own team can run without us in the room.
Most of it. The incremental route exists because a freeze long enough to rewrite a working system is rarely something a business can afford. New features land in whichever path already owns that capability, which does mean some work gets built twice in the overlap. That cost is real and we would rather name it than pretend the overlap is free.
Describe the problem in a paragraph and we will tell you which service applies.
