Old system to new, without the big-bang cutover that concentrates every risk on a single weekend. We map what runs today and what depends on it, then run the new path beside the old one and move traffic a slice at a time, with rollback available throughout. Equivalence is proven by shadow-running against real production traffic rather than by a testing phase everyone hopes was thorough enough. Sometimes the honest recommendation is to leave a system alone, and where that is true we will say so.
The same four moves on every engagement of this kind. No discovery phase that bills for months before anything runs.
We write tests against the old system's actual behaviour, including the bugs people now depend on. You cannot safely replace what nobody has described.
The new path is built alongside the old one and fed the same inputs, with outputs compared automatically until they agree.
One route at a time, a percentage at a time, with a rollback tested before each move. There is no big-bang cutover weekend.
The old path is retired only once nothing is calling it, and the comparison harness has been quiet for an agreed period.
We map what runs now, what it costs, and where it actually breaks. Nothing changes in this step. The point is a shared and accurate picture, because most failed modernisations begin with a plan built on an out-of-date diagram.
New paths run beside the old system and take traffic only once they have earned it. Big-bang cutovers concentrate all the risk on a single weekend, which is exactly when nobody senior is available.
Shadow-running the new path against production and comparing the answers, so the decision to switch is based on evidence rather than on a testing phase everyone hopes was thorough enough.
The point is not a system only we understand. Tests, documentation and the release process go with it, and your engineers are in the work throughout rather than briefed at the end.
Have a system nobody wants to touch?
Scope this with usOld systems are where the most valuable and least documented business logic lives. That makes them an unusually good fit for AI as a reading tool, and an unusually bad one for AI as a rewriting tool.
Models are genuinely useful for summarising unfamiliar code, tracing a path through it and drafting the questions worth asking. Every finding is then verified against production behaviour.
Draft documentation and characterisation tests generated from the code, reviewed by an engineer before anything is trusted. It is a first pass, not an answer.
We do not let a model rewrite a system whose behaviour is the specification. The value is in comprehension and coverage, and the sign-off stays with a person.
Side-by-side running is how we work, not a premium option. If a cutover genuinely needs a window, we say so early and explain why.
Old systems encode years of decisions nobody wrote down. We treat that as a specification to be discovered rather than a mess to be cleared away.
Modernisation stalls when nothing visible ships for months. Something moves to the new path each fortnight, so progress is observable rather than asserted.
Some systems are cheaper to leave alone. Where that is true it is what we will recommend, even though the smaller engagement is worth less to us.
The questions that come up most on a first call about this practice, answered the way we would answer them on the phone.
Usually not, and we would push back on that plan. The value is normally in a few components, and the rest keeps running because it works.