Legacy modernisation without a big-bang rewrite: the strangler pattern in practice

Most companies in their second decade run on a system that was right in 2014 and is expensive in 2026: slow releases, one developer who understands it, a server nobody dares to touch. The instinct is to rewrite it. The data says rewrites overrun and often fail. The alternative is to strangle the old system gradually, and it works.

01Why rewrites fail

A rewrite freezes the old system while the new one is built, so the business waits for a year or more with no improvement. The team rediscovers every business rule hidden in the old code, usually in production. And the new system launches with all the risk at once. The strangler pattern avoids all three problems by replacing the system one capability at a time behind a stable interface.

02The pattern in four steps

• Put a facade in front of the legacy system: an API gateway, a reverse proxy or a thin service layer that every client talks to.
• Pick one capability with high value and low coupling, such as reporting, notifications or product search. Rebuild it as a separate service.
• Route traffic for that capability to the new service. Keep the old code path as a fallback until the numbers prove the new one.
• Repeat. Each iteration shrinks the legacy system until what remains is small enough to retire.

03Choosing the first slice

Good first candidates are read-heavy, well understood and painful today: a reporting module that times out, a search that nobody trusts, an integration that breaks monthly. Bad first candidates are the core transaction engine and anything with regulatory consequences. Prove the method on something visible but safe.

04Data is the hard part

Code can be replaced in slices. A shared database resists it. The usual approach is to let the new service read from the legacy database at first, then own its data and sync back, then cut the link. Change-data-capture tools make the sync practical. Plan this per slice; it is where most of the effort goes.

05Cloud-native, but only where it pays

Containers, managed databases and a CI/CD pipeline are worth adopting early because they make every later slice cheaper. Kubernetes, event streaming and microservices for everything are not. A mid-size company is usually best served by a small number of services on a managed platform (AWS, Azure or Google Cloud), with infrastructure defined as code and observability from day one.

06AI tools in modernisation

In 2026 AI coding assistants materially speed up the tedious parts: documenting legacy code, generating characterisation tests, translating between frameworks and spotting dead code. They do not replace the architect who decides the slices or the tester who proves behaviour did not change. Used under review, they shorten each iteration.

07What a six-month programme looks like

• Month one: inventory, dependency map, facade in place, CI pipeline and test harness around the legacy system.
• Months two to three: first slice rebuilt, deployed behind a feature flag, measured against the old path.
• Months four to six: two to three further slices, data ownership moved, legacy modules retired as they empty.
• Every month: a demo to the business and a cost and risk review.

08How Synova helps

Our IT Advisory team maps the system and designs the slices; our development teams in Ho Chi Minh City rebuild them in .NET, Java, Node.js or Python on your cloud, with the legacy system running until each slice is proven.