Engineering
Replacing a legacy application without a big-bang cutover
How the strangler pattern lets an agency modernize one function at a time while the old system keeps running.
The riskiest way to replace an old system is to build a new one in parallel for two years and switch everyone over on a weekend. The strangler pattern is the alternative: put a façade in front of the old system and move functions behind it to the new system one at a time.
The mechanics
- Introduce a routing layer, often an API gateway or a reverse proxy, in front of the legacy application.
- Pick a bounded function, such as address lookup or fee calculation, and rebuild it in the new system.
- Route requests for that function to the new implementation while everything else still goes to the old one.
- Verify behavior, often by running both and comparing results for a period.
- Repeat until the old system handles nothing, then retire it.
Why it suits public agencies
Budgets are annual. Each increment can be scoped, priced, and accepted within a fiscal year. Risk is spread across many small cutovers instead of one large one. Staff learn the new system gradually. If a phase runs into trouble, the previous state still works.
What makes it hard
Shared databases are the usual obstacle. When the old and new systems both need the same tables, you need a plan for ownership of each dataset and synchronization during the transition. Business rules buried in old code have to be extracted and documented, which is slow but is also the most valuable output of the whole exercise.
What we recommend
Start with a function that is well understood, low risk, and visibly painful in the old system. A quick, safe win builds confidence with staff and leadership. Document every extracted business rule in plain language and keep that document as a living asset. Measure comparison results and publish them internally, so the decision to cut over each function is based on evidence.