Why Modernization Fails Before a Single Line of Code Is Written
There's an interesting pattern in the recent wave of AI modernization announcements. AWS, Anthropic, IBM, Moderne. Everyone is building better ways to translate code from one language or framework to another. COBOL to Java. Java 8 to 17. .NET Framework to .NET 8.
Translation tooling is getting genuinely good. AWS Transform handles Java upgrades at scale. OpenRewrite has a recipe catalog for framework migrations. Moderne raised $50M on deterministic code transformations. These tools solve real problems.
But the modernization failure rate hasn't moved.
The Numbers
BCG's research puts the failure rate at 70%. 83% of projects exceed their budget or timeline. These numbers have been roughly stable for a decade, through every generation of tooling.
The consistent failure points to something upstream of the tools themselves. 47% of modernization delays come from unidentified dependencies. Not technical complexity. Not bad estimates. Dependencies that nobody mapped before the work started.
Most modernization efforts begin by writing code. Pick a framework, start migrating files, figure out the architecture as you go. Weeks in, the team discovers shared database tables that three domains quietly rely on. They hit a class that's grown to thousands of lines and touches everything. They find circular dependencies that make clean extraction impossible without rethinking the boundaries.
The pattern repeats because the sequencing is wrong. Teams start transforming code before they understand what the code does.
What "Understanding" Actually Means
For a small codebase, understanding lives in people's heads. The senior engineer who's been there for a decade can walk you through the domains, the integrations, the quirks.
For a codebase with 500,000 lines across a thousand files, that knowledge is fragmented, outdated, or gone. "Understanding" at that scale means systematically mapping every domain, every integration, every data entity, every external dependency, and every source file to its owning domain. It means identifying which code is actually dead (research consistently shows roughly 20% of enterprise code is unused, and 63% of Java developers say dead code hurts their productivity). It means surfacing tech debt with specific file locations, not vague categories.
That's weeks of manual work. Most teams skip it because the pressure is to start producing code, not documents. The irony is that skipping it is exactly what causes the delays later.
Translation vs. Transformation
Consider what happens when you upgrade a 500,000 line Java 8 monolith to Java 17. The upgrade is valuable. You get language features, security patches, performance improvements. But you still have a monolith. The same architectural issues are there. The same tightly coupled domains. The same tech debt.
Translation preserves structure. Modernization transforms it. And transformation requires understanding the structure first.
This is where the gap sits. The industry has made excellent progress on translation (language upgrades, framework migrations, deterministic refactoring). The understanding step, the one that determines whether the transformation succeeds, is still mostly manual.
Specification-First Modernization
We've been thinking about this sequencing problem at CodeSplit AI. The platform starts with automated codebase analysis and produces a rebuild specification before any code is touched.
Concretely: connect your repository, and the platform analyzes the entire codebase. It generates a structured specification document with every domain identified, capabilities listed, data entities and integrations mapped, source files organized by domain. Cross-cutting concerns cataloged. External dependencies inventoried. Tech debt surfaced. Dead code identified with exact line counts.
It's a behavioral specification. A document that describes what the system actually does, organized by domain, detailed enough to plan the full modernization from.
The specification then becomes the foundation for everything that follows. Dead code cleanup targets the removal groups the analysis identified. Service extraction follows the domain boundaries the spec mapped. Framework migration operates on a codebase that's already been cleaned and structurally understood. Each step compounds the one before it because they all reference the same source of truth.
Why This Matters Now
Forrester calls the current state of enterprise technical debt a "tsunami", with 75% of organizations at moderate to high severity. KPMG's 2026 Global Tech Report confirms that tech executives are doubling down on modernization to stay competitive, with legacy infrastructure remaining a persistent barrier to scaling AI and digital transformation. The modernization market is projected to hit $30.59 billion in 2026.
The tools for translating code are improving fast. That's great. But translation is one step in a larger process, and it's not the step where most projects fail.
The step where projects fail is the one that comes first: understanding what you have before you change it. The better that step is, the better everything downstream works.