The challenge
A manufacturer depended on an in-house system whose original authors had long left. It ran on an unsupported runtime, any change risked halting production, and a big-bang rewrite had already been attempted once and abandoned.
Our approach
We started with an assessment that produced a costed, sequenced roadmap instead of a rewrite pitch. Then a strangler-fig migration: an API façade in front of the legacy system, one bounded capability moved at a time behind feature flags, with the old and new paths running in parallel and compared against each other before each cutover.
The outcome
The first slice reached production inside three months and the line never stopped. Because each capability moved independently, the programme stayed fundable in phases rather than needing one large up-front commitment.
Why this approach
A big-bang rewrite had already been tried and abandoned — which is the usual ending, because the hardest part of replacing an old system is not writing new code, it is discovering the undocumented business rules the old code has been quietly enforcing for fifteen years. Running old and new in parallel and comparing their outputs turned those rules from midnight surprises into findings: every discrepancy was a rule surfacing, on a schedule the business controlled.
The API façade did double duty. It let capabilities move one at a time behind feature flags, and it meant the production line never depended on the migration’s progress — the old path stayed available until the new one had proven itself on real traffic.
If you are facing something similar
The system that “cannot be touched” usually can — in slices, behind a façade, with parallel-run proof at each step. Our rewrite-vs-modernize guide walks through how to make that call honestly, and the legacy modernization service starts with an assessment that prices the roadmap before you commit to it.