The problem migration teams keep hitting.
Most legacy systems are not broken. They are worse: they work. They invoice customers, move data, run reports, and encode ten years of business exceptions that nobody wrote down.
The risk is rarely the old code alone. It is the invisible contract between the old code, the database, the operators, the nightly jobs, and the downstream systems that quietly depend on all of it.
What we actually build, in order.
We usually start by making the legacy system observable. Logs, data flows, job schedules, failure modes, user paths, and integration points need to be visible before they can be replaced.
Then we isolate one bounded slice. An API, a workflow, a reporting module, a data pipeline, or a frontend shell. We migrate by cutting load-bearing pieces one at a time, not by promising a clean rewrite.
What we don't do.
We do not sell big-bang rewrites. We do not call a system legacy just because it uses an old framework. We do not replace stable software without understanding why it survived.
We also do not take migration work where the plan is mainly theatre: new architecture diagrams, no cutover path, no operator buy-in, and no budget for the difficult middle.