Context
A business running on systems old enough that every change was risky — but too load-bearing to pause while a replacement was built.
The problem
Documentation had drifted from reality; behavior had to be recovered from the running system.
A big-bang rewrite was organizationally and financially unacceptable.
The team had to keep shipping business changes during the migration.
The system
Critical decisions
Strangler-pattern migration over rewrite
Route traffic capability by capability to new services, with the old system as the always-available fallback.
Characterization tests before refactoring
Capture what the system actually does — including the accidental behavior customers depend on — before changing how it does it.
Parallel-run verification at cutover
New and old compute side by side with automated diffing until divergence approaches zero; cutover becomes evidence-based, not hopeful.
Execution
Capability inventory, risk-ranked sequence, and a standing rule: any slice can be rolled back in minutes. Business releases continued on the legacy path until each slice proved itself.
Outcome
- Modern platform reached without an operational interruption.
- Every migration slice reversible, and several were reversed and retried — invisibly to users.
- [Quantified outcomes to confirm before publication]
Lessons
- Migration sequencing is risk management expressed as architecture.
- Parallel-run diffing converts cutover anxiety into data.
- The legacy system is the spec — read it, do not trust the docs.
Have a similar problem?
Discuss an AI initiative