Every company with a seven-year-old system eventually hears the pitch: "this is unmaintainable — we should rewrite it." The rewrite is occasionally right and usually a two-year trap. Here is the honest framework, and the migration pattern that works when modernization is genuinely due.
Why rewrites fail so reliably
The old system is a decade of encoded edge cases nobody remembers deciding — the rewrite team rediscovers them one production incident at a time. Meanwhile: the business needs features during the rewrite (so the old system evolves while the new one chases it), motivation dies in month eight of rebuilding what exists, and the switchover is a big-bang bet on software with none of the old system's scar tissue. The industry's rewrite graveyard is full of projects that were 80% done for two years.
The decision framework, honestly
Stabilize first, always: before any big decision, tests around critical paths, monitoring, backups, and dependency updates — often this alone converts "unmaintainable" into "annoying but workable," because the debt, not the architecture, was the pain.
Modernize incrementally when: the business logic is sound but the shell is old (UI refresh on existing APIs), one component genuinely blocks (extract that), or the platform is EOL (targeted migration).
Rewrite only when: the stack is truly dead (unhirable skills, unpatchable runtime), the business model changed so much the domain model fights you daily, and you can afford dual-running — honestly priced, not optimistically.
The strangler-fig pattern (how increments actually work)
New capabilities get built as clean modules beside the old system, a routing layer sends traffic feature-by-feature to new code, and the legacy system shrinks until what remains is small enough to retire quietly. Each step ships value, each step is reversible, and the business never bets everything on a switchover Sunday. This is extraction discipline pointed at history instead of scale.
Costs (India, 2026)
Stabilization pass: ₹1–4L. Incremental modernization: ₹3–15L spread across quarters, shipping value throughout. True rewrite: full product-build economics plus dual-running overhead — which is the honest number vendors pitching rewrites rarely lead with.
Inherited a system everyone fears touching? We audit before we advise — and our most common recommendation is the cheapest one: stabilize, then strangle slowly.
Frequently asked questions
Should I rewrite my legacy software?
Rarely. Rewrite only when the stack is truly dead (unhirable, unpatchable), the domain model fights daily business reality, AND you can afford dual-running honestly priced. Otherwise stabilize first, then modernize incrementally — the rewrite graveyard is full of two-year 80%-done projects.
What is the strangler-fig pattern?
Building new capabilities as clean modules beside the legacy system, routing traffic feature-by-feature to new code, and shrinking the old system until it retires quietly. Every step ships value and stays reversible — no big-bang switchover bet.
Why do software rewrites fail?
The old system encodes a decade of forgotten edge cases the rewrite rediscovers as production incidents; the business needs features during the rewrite so the target moves; and month-eight motivation dies rebuilding what already exists.
What does legacy modernization cost?
Stabilization (tests, monitoring, dependency updates) runs ₹1–4 lakh and often converts 'unmaintainable' to 'workable.' Incremental strangler-fig modernization costs ₹3–15 lakh across quarters while shipping value. True rewrites cost full rebuild economics plus dual-running overhead.