Key takeaways
- A big-bang rewrite of a working system often runs late, over budget and misses features nobody wrote down.
- The strangler fig pattern builds new functionality around the old system and moves traffic over one piece at a time.
- Start with a clear map of what the system does, then pick a small, valuable first slice.
- Put a routing layer in front, so you can switch each piece between old and new, and roll back instantly.
- Retire the old parts only when the new ones are proven. Keep the business running throughout.
Why big rewrites fail
Old systems encode years of business rules, many of them undocumented. A full rewrite has to rediscover all of them while the old system keeps changing, and the business gets no benefit until the very end. That is a long time to carry risk with no payoff, which is why many rewrites stall or are abandoned.
The strangler fig idea
The name comes from a plant that grows around a tree and gradually replaces it. In software, you leave the legacy system running and build new components alongside it. A routing layer sends each request to either old or new code. Over time, more and more traffic goes to the new parts until the legacy system can be switched off. Every step delivers value and can be reversed.
Step by step
- Map the system. List its features, data, integrations and who depends on each one. Talk to the people who use it.
- Choose a first slice. Pick something valuable but self-contained, such as a customer portal or a reporting module, not the most tangled core.
- Add a facade or routing layer in front of the old system, so you can redirect individual functions.
- Build the new component with modern tools and automated tests.
- Handle the data. Decide whether the new piece reads from the old database, syncs with it or takes over the data, and test it carefully.
- Run both in parallel where possible, comparing results, then switch a small share of traffic.
- Expand and repeat. Move more traffic, then the next slice.
- Retire the old part once the new one has proven itself, and remove the dead code and infrastructure.
What to watch for
- Data consistency. Two systems holding the same data need clear rules about which one is the source of truth.
- Hidden dependencies. Reports, batch jobs and spreadsheets often rely on old database tables.
- Temporary complexity. You run two systems for a while, so keep the transition short and focused.
- Scope creep. Resist adding new features that blur whether the new piece matches the old behaviour.
- Team knowledge. Keep people who know the old system involved.
When another route is better
| Situation | Better option |
|---|---|
| The system is small and well understood | A direct rewrite may be quicker |
| A good product already does the job | Replace it, see build vs. buy |
| The system works and is rarely changed | Leave it, and wrap it with an API if needed |
| The platform is unsupported and risky | Prioritise a first migration of the riskiest parts |
Get a realistic plan
The budget for modernisation depends on size, documentation and risk, as discussed in our cost guide. Reducing the underlying technical debt alongside the migration keeps it from coming back. Our legacy modernization team can assess your system and propose a staged plan with clear milestones.
Qodexify is a remote-first team of senior engineers building web apps, AI agents, workflow automation and websites. Learn more about our legacy modernization service or talk to an engineer.
