Modernizing Legacy Systems Without a Big-Bang Rewrite

Why a big-bang rewrite is risky

Old systems hold more business rules than anyone remembers: a special case for one customer, or the rounding method accounting relies on. These are rarely documented and live only in the code. In a full rewrite they get lost at some point, and you find out after launch.

Another problem is that while the team rewrites, the old system still needs bug fixes and features, so work is done twice. The business waits months without seeing anything, and if budget or patience runs out halfway, there is nothing usable to show for it.

The strangler approach: let the new grow around the old

The name comes from strangler fig trees that grow around a host tree and gradually replace it. In software it means building new capabilities beside the existing system and moving usage over one slice at a time, until nothing depends on the old system and you can switch it off.

Put a routing layer in front, such as a reverse proxy or API gateway, that decides which requests go to the old system and which go to the new one. Start with a slice that separates easily and shows clear value, such as product search or an order status page, rather than something tied to everything, like pricing.

Finding seams and adding an API layer

A seam is a join in the system where behaviour can be changed without editing everything around it: a boundary between modules, a separable set of database tables, or a file another system reads. Start by tracing who calls whom and where data flows, then pick the point where you can cut most cleanly.

Next, wrap the old system in an API layer so new screens, mobile apps and other systems call that layer instead of reaching into the database directly. The layer hides the mess behind it and lets you change the back end later without callers noticing.

Before touching old code, write tests that capture current behaviour, even where it looks odd, so you know immediately when the new version answers differently.

• Map dependencies between modules and shared database tables.
• Choose a first slice that is easy to separate and visible to users.
• Write tests recording current behaviour before changing anything.
• Add an API layer or gateway as the single front door.

Migrating data carefully

Data is often the hardest part, because old data is inconsistent: phone numbers typed ten different ways, or Thai names stored with the wrong encoding. Clean it and define a target format before moving, and rehearse the migration on real data several times before the actual day.

A safe pattern is to keep the old system as the source of truth at first, sync data to the new one, and compare results on both sides until you trust it. Only then switch the new system to be the source. After the move, keep the old system read-only for a while in case you need to go back.

A change you can undo is cheaper than a change that must be right the first time.

Running old and new side by side

The period when both systems coexist is the riskiest, and it usually lasts longer than planned. Use feature flags to show the new feature to a small group of users first and widen it gradually. If something goes wrong, you can switch back in minutes without deploying again.

Set up monitoring that compares both sides, such as order totals, error counts and response times, and set a real date for shutting down the old system. Otherwise both stay forever and you pay to maintain two of everything.