When a critical system becomes hard to change, the instinct is often to rewrite it. That instinct is understandable, and it is also where many modernization efforts go wrong. A safer path is to modernize in small, reversible steps while the existing system keeps running. This article explains the idea and how to apply it.
Why full rewrites are risky
Martin Fowler, in his write-up of the strangler fig approach, summarizes why replacement projects often fail. They take a long time while users wait for new features, the details of existing behavior are hard to figure out, and much of that behavior may not be wanted in the new version. In our view, a rewrite bets everything on one cutover, and the value arrives only at the end.
The strangler fig idea
The name comes from a vine that grows around a host tree and gradually replaces it. In software, you build new functionality alongside the legacy system and move behavior over piece by piece until the old system is no longer needed. Fowler describes four activities, drawn from work by Cartwright, Horn, and Lewis: understand the outcomes you want, decide how to break the problem into parts, deliver those parts successfully, and change the organization so this can continue.
A practical sequence
- Align on the outcome. Decide what modernization must achieve: faster delivery, lower operating risk, a cloud move, an integration, or the end of a vendor dependency. Without a clear outcome, every option looks equally good.
- Understand what you have. Map the architecture, dependencies, data flows, tests, and the business rules hidden in the code. Document uncertainty instead of hiding it.
- Find the seams. Look for places where you can separate one capability from the rest, such as an API boundary, a module with few dependencies, or a workflow with a clear input and output.
- Pick the smallest safe first step. Choose a piece that is valuable, bounded, and easy to verify.
- Replace and verify. Build the new piece, run it alongside the old one when possible, compare results, and switch over only when you are confident. Keep a way back.
- Repeat, and change how you work. Update tests, documentation, and release practices so the new system does not accumulate the same problems.
Where AI helps, and where it does not
AI agents can speed up the analysis: reading a large codebase, summarizing modules, mapping dependencies, drafting documentation, proposing tests, and implementing well-defined changes. They do not remove the need for business context, architecture judgment, security review, or production controls. People decide what to keep, what to change, and what reaches production.
Signs it is time to modernize
- Delivery slows because modules, integrations, and ownership boundaries are unclear.
- A migration or cloud move is being considered.
- Technical debt competes with roadmap work.
- Critical knowledge lives with a few people.
Questions to ask a modernization partner
- How will you decide what to keep, change, or replace? Look for an evidence-based assessment before any migration path.
- What is the smallest first step? A bounded first piece shows how the team works.
- How do you protect production? Ask about tests, parallel runs, review points, and rollback.
- What will we have at the end of each step? Documentation, tests, and a working improvement.
- How is the scope defined? Start with one system, one decision, and written acceptance criteria.
If you are weighing a modernization, see how we approach legacy software modernization. To understand the delivery model we use, read what an AI Pod is.