The Statistic Nobody Wants to Talk About
McKinsey estimates that 70% of large-scale IT transformation programs fail to meet their stated objectives. Gartner puts the figure at roughly the same level for legacy modernization specifically. The Standish Group's CHAOS Report has tracked enterprise software project failure rates above 60% for three decades running.
The industry has spent years analyzing why those projects fail. The conclusions usually cluster around familiar culprits: unclear requirements, poor communication, inadequate testing, talent gaps. All true. All downstream of the real problem.
The real problem is that most enterprises walk into a migration without actually understanding the system they are migrating. They treat it as a construction project — gather materials, hire builders, start assembling — when it is fundamentally a knowledge problem. You cannot redesign what you do not comprehend. And for legacy systems that have been accumulating business logic for 20 to 40 years, comprehension is not a given. It is earned.
The decision to migrate is made in a boardroom. The consequences of that decision are discovered in a codebase. Most organizations have no systematic process for bridging those two realities before the project clock starts ticking.
What follows is a direct account of the five failure modes that appear, with striking consistency, across failed enterprise migration programs. The examples are drawn from real engagements — anonymized, but otherwise unembellished. The patterns are not exceptions. They are the rule.
Failure Mode 1: Source System Blindness
A North American insurance carrier decided to migrate their policy administration system off COBOL mainframe after 31 years. The system processed roughly $4 billion in annual premiums. The migration budget was set at $45 million over three years.
In the first six months, the project team — 80 developers, six systems integrators, two consulting firms — discovered that nobody actually knew how many programs were in the system. Initial estimates said 1,200. The actual count, after a manual audit, was 4,700. More than half had no documentation. Roughly 400 contained business rules that were not represented anywhere outside the source code itself.
The project was restructured. Timeline extended by two years. Budget increased by $30 million. It eventually delivered — five years late and nearly double the original cost.
This is source system blindness: the inability to produce an accurate, complete, structured picture of what you are migrating before you begin migrating it.
The inventory was assembled from version control exports and developer memory. COPY statements were not traced to their COPYBOOK definitions. JCL job chains were not mapped to the programs they orchestrated. DB2 stored procedures were counted separately from the programs that called them. The dependency graph — the actual structural map of the system — simply did not exist at project start.
The absence of a dependency graph is not a minor planning oversight. It is a structural deficiency that guarantees estimation failure. You cannot know how long a migration will take if you do not know how many components are involved. You cannot assess risk if you do not know which components depend on which others. You cannot sequence work if you do not understand the call graph.
Every team that has ever underestimated a legacy migration has done so for the same reason: they counted files and called it an inventory. A true inventory maps every call relationship, every data dependency, every integration point, and every business rule encoded in the source. That level of analysis requires systematic, automated parsing — not spreadsheets, not developer interviews, not code reviews conducted in conference rooms.
The measurement problem
Legacy systems are routinely measured in lines of code. This is almost entirely useless as a planning metric. A 50-line COBOL paragraph that handles premium calculation with 12 business rule branches is architecturally more complex than a 500-line data formatting routine. Lines of code measures volume. It says nothing about structure, dependency depth, business criticality, or transformation difficulty.
The metrics that actually predict migration effort are: number of unique call paths, depth of COPYBOOK nesting, number of cross-program data dependencies, CICS transaction boundary count, and the ratio of business logic code to infrastructure code. None of these can be obtained without automated structural analysis.
Failure Mode 2: Architectural Assessment Skipped
A European telecommunications company launched a migration of their billing platform from a proprietary legacy stack to a modern microservices architecture. They spent six months in requirements gathering, produced a 200-page target architecture document, and began development.
Eighteen months in, the lead architect made a discovery that the planning phase had missed entirely: the legacy billing system's transaction processing logic was deeply interleaved with its data storage logic. Separating them — a prerequisite for a proper microservices decomposition — would require restructuring more than 60% of the migrated code that had already been written. The project was suspended.
The cause was a skipped architectural assessment. Not a superficial one — the project had produced extensive documentation about the target architecture. What it had not done was produce a rigorous analysis of the source architecture: how the legacy system was actually structured, which layers were properly separated and which were tangled, and where the boundaries between functional domains could realistically be drawn.
A target architecture document describes where you want to go. An architectural assessment of the source system tells you whether the road you have planned actually reaches that destination. Skipping the latter is navigation without a map.
Architectural assessment means answering specific structural questions about the source system. Where is business logic co-located with presentation logic? Where are data access concerns embedded in service routines? Which components have been designated as shared utilities but have quietly accumulated domain-specific business rules? Where are the hidden integration points — the implicit dependencies that are not reflected in any call graph but exist in shared file formats, shared database tables, or assumed data ordering?
Modern architectural patterns assume clean layer separation: presentation, service, domain, persistence. Legacy systems were not built with these layers in mind. A COBOL program might contain file I/O, business calculation, screen formatting, and inter-program communication in the same division. The architectural assessment must identify where these concerns are tangled, and that identification must happen before the target decomposition is designed — not after the code is written.
The failure mode is consistent: organizations assess the target in detail and assess the source superficially, if at all. Then they discover structural incompatibilities after significant development investment has been made. At that point, the options are all bad: restructure completed work, compromise the target architecture, or restart.
Failure Mode 3: Scope Creep Baked Into the Foundation
A US federal agency initiated a migration of a grants management system that had been in production since 1991. The original scope was defined as "migrate the core grants processing workflows to a modern Java platform." The business stakeholders, recognizing that a modernization was underway, added requirements incrementally: new reporting capabilities, a new applicant portal, integration with external data providers, real-time compliance checking.
None of these additions were unreasonable individually. Collectively, they transformed a migration project into a platform rebuild. The project, originally scoped at $12 million, was terminated at $34 million with approximately 40% of the originally committed functionality delivered.
This is scope creep — but not the variety usually attributed to stakeholder mismanagement. The more dangerous form is structural scope creep: where the scope expands not because of explicit requests, but because the initial assessment was so incomplete that the true scope was never understood. Every discovery of an undocumented integration, every surfaced business rule, every unmapped dependency adds work that was always real but was never visible in the plan.
The discovery tax
Every migration program pays a discovery tax — time and budget spent learning things about the source system that should have been known before the project began. In well-planned programs, the discovery tax is paid upfront, in the assessment phase, before development begins and before budgets are committed. In poorly planned programs, it is paid continuously, throughout the execution phase, as surprises compound against a fixed timeline and a committed budget.
The discovery tax is not optional. It exists because legacy systems contain information that is only accessible through systematic analysis. The question is whether you pay it cheaply, before commitments are made, or expensively, after they are.
Scope creep prevention requires a complete source inventory before scope is defined. You cannot accurately bound a migration if you do not know what you are migrating. Defining scope from an incomplete inventory is not planning — it is guessing with professional formatting.
Failure Mode 4: Vendor Lock-In Assumptions
A mid-size financial services firm selected a cloud migration vendor whose platform promised automated COBOL-to-Java conversion. The vendor's demo was compelling: upload source code, receive Java output. The firm signed a three-year contract at $8 million annually.
The vendor's tool worked well on the components that matched its training data: standard COBOL structures, common DB2 patterns, straightforward CICS transactions. It performed poorly on the firm's custom COPYBOOK hierarchies, its in-house MQ messaging conventions, and the undocumented inter-program contracts that had evolved over 25 years. Those components — which represented roughly 35% of the codebase but contained roughly 80% of the business-critical logic — required manual intervention that the vendor had not scoped for.
The contractual lock-in meant the firm had no leverage. The vendor had no financial incentive to expand the tool's coverage. The project ran three years over schedule and consumed two additional years of manual remediation work that the firm's internal team performed after the vendor contract ended.
No automated migration tool handles 100% of a real enterprise codebase without exceptions. The critical question to ask before signing any vendor contract is not "what percentage does your tool automate?" — vendors will always answer "most of it." The question is "what happens to the components your tool cannot handle, and who bears the cost of resolving them?" If the answer is unclear, the contract is structured to benefit the vendor, not the buyer.
Vendor lock-in in migration programs takes several forms. Tool lock-in, as described above, where the vendor's coverage gaps become the buyer's problem. Platform lock-in, where the migration target is a proprietary cloud service that recreates vendor dependency in the modern stack. Process lock-in, where the vendor's methodology creates knowledge dependencies that make it difficult to bring work in-house or switch providers.
The evaluation question that most procurement processes skip: does this vendor's approach produce outputs that your team can maintain, extend, and audit independently of the vendor? Migration is a means to an end. The end is a system your organization owns and controls. Any vendor relationship that creates a new form of dependency has not solved the original problem.
The "AI converts everything" promise
The current wave of AI-powered migration tools has introduced a specific variant of vendor lock-in assumption: the belief that a sufficiently capable language model will handle all the hard cases. It will not.
Language models are trained on code that exists in training corpora. Legacy enterprise code — 30-year-old COBOL with proprietary CICS extensions, custom Adabas database schemas, in-house JCL conventions — is substantially underrepresented in those corpora. The model's confidence does not correlate with its accuracy on these edge cases. It will generate plausible-looking output that contains business logic errors, because it does not have a structural understanding of the source system's semantics — only a statistical approximation derived from patterns in training data.
Structural analysis is not a feature that language models can replicate. It requires deterministic, language-aware parsing built from deep expertise in each legacy ecosystem. AI is most effective in migration pipelines when it operates on top of that structural foundation — not as a replacement for it.
Failure Mode 5: The Big Bang Fallacy
A retail bank with operations across 14 countries decided to replace its core banking platform. The system, built on a proprietary mid-range platform in the 1980s, handled current accounts, savings products, lending, and international payments. The migration was planned as a complete replacement: new platform in parallel, data migration, cutover on a defined date.
The cutover date was reached. The new platform went live. Within 72 hours, the bank had identified over 3,000 defects in production. Some were cosmetic. Many were functional. Eleven were critical — involving incorrect balance calculations, failed payment processing, and errors in interest accrual logic. The bank reverted to the legacy system at 4 AM on day three. The total cost of the attempted cutover and rollback, including regulatory notifications, customer remediation, and staff overtime, was estimated at over $150 million.
This is the big bang fallacy: the belief that a complete, simultaneous replacement of a complex operational system is a viable migration strategy. It is not — and the evidence against it has been accumulating for 40 years.
The big bang is not a deployment strategy. It is a risk concentration strategy. Every unknown, every untested edge case, every undocumented business rule that was not discovered during the migration becomes a production defect, all at once, on the day you can least afford it.
Why organizations choose big bang anyway
The big bang approach persists despite its failure record for structural reasons. Running two systems in parallel is expensive. Maintaining data consistency across a legacy system and a modern one during a phased migration is genuinely difficult. The business case for migration often assumes clean before/after accounting — and a phased approach complicates that accounting. Executives prefer a defined cutover date because it provides a clear milestone to communicate to boards and regulators.
These are real pressures. None of them justify a strategy that concentrates all migration risk into a single, irreversible moment.
The strangler fig pattern — incrementally replacing legacy functionality with modern equivalents, routing traffic gradually, retiring legacy components as replacements are validated — has a substantially better track record than big bang migration. It is harder to plan, harder to govern, and harder to communicate to non-technical stakeholders. It is also dramatically more likely to succeed. The difficulty of the approach is not a reason to avoid it. It is a reason to invest in the planning infrastructure required to execute it correctly.
The strangler fig requires something that big bang does not: a precise, ongoing understanding of which components have been migrated, which remain in legacy, and exactly how the routing between them works. That understanding must be maintained in real time. It cannot be managed with spreadsheets. It requires a platform that maintains a live model of both the source and target systems throughout the migration lifecycle.
The Common Thread
Every failure mode described above has a common root: insufficient understanding of the source system before consequential decisions are made.
The insurance carrier that underestimated its program count did so because it had no systematic way to inventory its source system. The telecom that discovered its architectural incompatibilities after 18 months of development did so because it had no tool for structural analysis of its legacy codebase. The federal agency that experienced compounding scope creep did so because its initial scope was defined against an incomplete picture of what it was migrating. The financial services firm that ended up with a vendor coverage gap did so because no independent assessment of that gap was performed before the contract was signed. The retail bank that catastrophically failed its cutover did so because it had no systematic way to verify that every business rule in the legacy system had been correctly represented in the replacement.
These are not independent problems requiring independent solutions. They are expressions of the same underlying deficiency: the absence of deep, structured, automated source system understanding as a prerequisite to migration planning.
What Good Looks Like
The migrations that succeed — and they do exist, though they are rarer than the industry acknowledges — share a consistent set of characteristics.
They begin with a complete, automated structural analysis of the source system before scope, timeline, or budget are committed. They produce a dependency graph that accounts for every call relationship, every data dependency, and every integration point. They classify source components by architectural layer to identify tangling that will affect target design. They establish measurable business rule coverage as a definition of done, not a post-launch aspiration.
They select a target architecture that is grounded in the source system's actual structure — not in what the target architecture would ideally look like on a greenfield project. They plan for phased delivery with independently validatable milestones. They instrument both legacy and target systems during the transition to maintain visibility into what has been migrated, what remains, and whether the migrated components behave correctly.
And they treat the pre-migration analysis phase as a first-class deliverable — not a cost to minimize before the "real work" begins. The real work is understanding. The code transformation follows from that.
The question every CIO should ask
Before committing to a migration program, one question cuts through vendor presentations, consulting proposals, and internal advocacy: "Show me the complete structural map of the system we are migrating — every component, every dependency, every business rule — and show me how this plan accounts for all of it."
If that question cannot be answered, the project is not ready to begin. The money that would be spent on the first six months of development would be better spent on the assessment that makes the remaining 54 months reliable.
The failure rate is not an industry secret. The remediation is not a mystery. The gap between knowing and doing is where the $1 trillion annually in failed IT investment disappears.
Platforms like CogniDev are emerging to address this exact gap — building deep source understanding before any code transformation begins. The migration conversation is finally shifting from "which AI can rewrite my code" to "which system actually understands it first."