Requests to “overhaul our old core system” grow year by year, but a full replacement of a legacy system is known as a project with an especially high failure rate even among system development. This article explains the structural reasons it tends to fail, the staged-migration mindset for avoiding failure, and what the arrival of generative AI has changed about modernization.
The structural reasons a full replacement tends to fail
1. No one understands the specs anymore
A system that has run for years, through layers of modifications, sees its specification documents diverge from its implementation, and it’s not unusual for the original staff to have left. Then you reach a state where “the current code is the only specification,” and new development begins without anyone able to say accurately what must be built to perform the same operations. Missing requirements surface during acceptance testing or after production go-live, and rework swells. The black-boxing problem pointed out by METI’s so-called “2025 Digital Cliff” report is still ongoing at many companies.
2. “Match the current system” is the most expensive requirement
When the specs are unknown, requirements definition tends to drift toward “just as it is now.” But “matching the current system” is in fact the heaviest requirement, demanding the re-implementation of all functionality, including years of exceptional handling and unused features. Rebuilding without reviewing the operations results in costs swelling while the operations improve not at all.
3. A big-bang migration can’t be undone
A “big-bang migration”—switching all at once to a new system built over several years—concentrates every risk on the switchover day. If data-migration inconsistencies and unexpected operations occur simultaneously, it directly halts business, and rolling back is difficult too. The longer the project drags on, the more it carries the contradiction that operations and technology have changed by the time it’s done—“already old by the time it’s finished.”
The realistic answer of staged migration—the strangler pattern
The established countermeasure to this failure structure is the staged migration called the strangler pattern. Named after the way a fig tree gradually covers its host tree, it essentially means “don’t replace all at once; shift to the new system a little at a time from the periphery.”
- Find the boundaries — Decompose the current system into business units (ordering, billing, inventory, etc.) and identify areas that are easy to carve out.
- Place a facade at the entrance — Route access from users and integrated systems through a single gateway (a proxy) so you can control whether processing goes to the new or old side.
- Move one area at a time to the new system — Switch to the new implementation starting from high-impact, low-risk areas. If there’s a problem, you can revert just that area to the old system.
- Shrink the old system and shut it down last — The more the migration progresses, the smaller the old system’s scope of responsibility, until it can finally be shut down safely.
Because you proceed while always keeping a working system, investment decisions can be divided per area too. Even when you can’t get sign-off on a full overhaul, the great practical advantage is that you can start from the first single area.
What generative AI has changed about modernization
Generative AI now directly addresses “restoring the specs,” which was modernization’s biggest bottleneck.
- Analyzing code with no specs — Generative AI is good at reading code in COBOL, old VB, Java, and the like and generating explanations of the processing, draft specification documents, and process-flow diagrams. A first draft of work that experts used to take months to decipher can now be obtained in a far shorter period.
- Drafting migration code and assisting conversion — AI handles the draft of rewriting from an old language to a new language or framework, and humans can concentrate on review and verifying the business logic.
- “Guaranteeing the same behavior” through tests — You can also reduce the effort of preparing regression tests—generating a large number of test cases from the current inputs and outputs and comparing the old and new results—with AI. It’s become easier to build a safety device for staged migration.
That said, since AI’s analysis results can contain errors, finalizing them as specs as-is is dangerous. The premise is a division of labor where AI drafts and business staff and engineers verify, and it’s accurate to see this as the overhaul’s effort shifting from “deciphering” to “verification.” Even so, because the total cost and duration have shrunk greatly, overhauls at scales that previously didn’t pencil out have become realistic options.
What to sort out before you start
- The purpose of the overhaul — Cost reduction, business improvement, or resolving maintenance-staffing risk. The priority areas change with the purpose.
- Inventory of assets — Whether you can assemble the full source code, DB definitions, forms, and a list of integration partners. Identifying features that are in fact unused also happens here.
- A decision-maker for what to drop — Appoint a business-side owner who can decide “we’ll discard this feature,” so you don’t drift into matching the current system.
- The unit and order of migration — Which business area to move first, and the period of parallel running and the policy for data consistency.
- The scope of the first step — Rather than the main body from the start, beginning with code analysis and a trial of one area (a PoC) makes your estimate dramatically more accurate.
Especially important is the “decision-maker for what to drop.” Both staged migration and generative AI work better the smaller the target. How much the total cost changes hinges on whether you can exclude from the migration scope the unused features, the forms that run once a year, and the exceptional handling built for just one specific company. Finishing the business-side sorting of “what to keep, what to discard” before the technical study is the real starting line of an overhaul project.
Summary｜Before “we can’t read it, so let’s rebuild”
Legacy overhauls fail from the structure of “committing to a full replacement while the specs are unknown” more than from a lack of technical skill. Analyze the current code with generative AI to restore the specs, and move one area at a time with the strangler pattern—this combination is the realistic answer for modernization today. As a contract development company built around a generative-AI-first development style, SHANNON provides consistent support from analyzing existing code and restoring specs, to a small confirming PoC, to designing and implementing a staged migration. Feel free to reach out even from the stage of “we just want to know whether our system can be analyzed at all.”