Most established businesses run on software that is older than anyone would like: a desktop application from the 2000s, a heavily customised system nobody fully understands, or a database with business rules hidden in stored procedures. It works, and that is exactly the problem. It is too important to switch off and too fragile to change quickly.
The instinctive answer is to rewrite it from scratch. That is usually the riskiest option available.
Why big-bang rewrites fail so often
- The old system encodes years of rules and edge cases that nobody wrote down. The rewrite rediscovers them one production incident at a time.
- The business keeps changing while the rewrite is built, so the target moves.
- Nothing reaches users until everything is finished, so there is no early value and no early feedback.
- Cut-over day carries all the risk at once.
The strangler fig pattern
The name, coined by Martin Fowler, comes from a fig that grows around a host tree until it can stand on its own. Applied to software, you build new functionality around the edges of the old system and move users across one capability at a time, until the legacy system has nothing left to do.
- Put a routing layer, such as an API gateway or proxy, in front of the legacy system, so you can decide request by request which system handles it.
- Pick one well-bounded capability, such as customer lookup, quoting or reporting, and build it in the new system.
- Route that capability to the new system, keep the rest on the old one, and keep data in sync between them during the transition.
- Repeat, capability by capability, retiring old code as you go.
What to modernize first
- Areas that change most often, where the old system slows the business down.
- Capabilities with clear boundaries and few dependencies.
- Parts with the highest operating cost or security risk, such as unsupported runtimes.
- Leave stable, rarely changed functions until last; they may never need replacing.
Make the old system safe to change
Before moving anything, add tests around the behaviour you need to keep, ideally by recording real inputs and outputs, and add monitoring so you can compare the old and new systems side by side. Running both in parallel for a period, and checking that they produce the same results, is the cheapest insurance a modernization project can buy.
