Before we touch a line of code on a legacy modernisation, we spend two weeks not writing any. Here's what those two weeks actually look like.
Week one — the estate
We inventory what's really running: systems, versions, dependencies, integration points, and the undocumented ones nobody mentions until they break.
Every component gets a risk and obsolescence score — out-of-support platforms, single points of failure, and code only one person understands. By the end of the week, the black box has a map.
Week two — the map and the plan
We map how data and processes flow across the estate, because the risk in legacy systems is almost never the individual component — it's the integration nobody fully owns.
From there we build a phased roadmap that sequences the work by risk and business disruption, not by what's technically interesting. The output is a target architecture, a sequenced migration roadmap, and a clear view of what breaks if you do nothing.
Why not just start rebuilding?
The temptation on a modernisation project is to start rebuilding the part you understand best on day one. Thirty years of delivery says that's exactly how you end up with a half-migrated estate and two systems to maintain instead of one.
Slower at the start. Far cheaper by the end.