The 280,000-Hour Problem
Morgan Stanley had 280,000 developer hours sitting in a single legacy COBOL system before they started touching it with AI. That is not an estimate of effort. That is what it cost to keep the lights on for one year (Morgan Stanley, DevGen.AI rollout, 2024).
When the team rolled out their internal DevGen.AI tool to translate that COBOL into English specs and then into modern code, they cut migration work roughly in half within twelve months. Half a year of one bank's engineering capacity returned to the business. Not theoretical. Already shipped.
Your number is probably smaller. The shape of the problem is the same.
Most CTOs reading this are sitting on at least one system that nobody wants to touch. Not because it does not work. Because the cost of being wrong is too high, the original authors are gone, the test coverage is thin, and the regulatory exposure on any rewrite is now larger than the value of the rewrite itself.
Then somebody asks: "Can we just put AI on it?"
Real Estate Marketing Attribution
A single attribution mistake led to a 22% pipeline drop. Here’s how real estate teams fix it with full-funnel visibility.
That is the wrong question. The right question is what legacy risk actually costs you this quarter, where it is hiding, and which slice of it AI can actually move.
Coined Frame: The Three Tax Lines
Legacy risk shows up as three tax lines on your engineering P&L. Most teams only price the first one.
Tax Line 1: Velocity tax. Every change to a legacy system takes 3x to 5x longer than the equivalent change in a modern codebase. McKinsey's 2024 modernization study put the productivity hit at 40 percent for teams who spent more than half their time in legacy code (McKinsey, "Demystifying digital dark debt," 2024).
Tax Line 2: Risk tax. Outages, security incidents, compliance failures. EU AI Act enforcement starts biting in August 2026 with fines up to 7 percent of global revenue for systems that cannot demonstrate appropriate documentation and human oversight (European Commission, AI Act timeline). Legacy systems with no audit trail and no documented decision logic are the first to fail this test.
Tax Line 3: Hiring tax. You cannot hire COBOL engineers, mainframe assembly programmers, or Delphi specialists at the rate the market wants you to. The ones you have are within five years of retirement.
If your CFO has only seen Tax Line 1, you have already underpriced the problem.
What Actually Changed in 2025
Three things shifted the math on legacy modernization in the past eighteen months.
First, code translation got good enough to use. Not perfect. Not unsupervised. But good enough that a senior engineer can review a translated module faster than they can write it from scratch. Amazon's Q Developer team reported 4,500 production years of Java migration completed using AI translation in 2024 (Amazon, "How Amazon saved $260M with Q Developer," 2024).
Second, the specification problem cracked open. The hard part of legacy migration is not writing new code. It is reverse-engineering what the old code actually does, including the 17 undocumented edge cases that one specific batch job depends on. Tools like DevGen.AI and the open Tessl framework translate legacy code into structured specifications first, then into target code. The spec becomes a durable artifact that survives the migration.
Third, regulatory pressure flipped the ROI calculation. EU AI Act, the UK AI Safety Institute regime, DORA enforcement on financial services, and US state-level data laws all penalize systems that cannot explain themselves. Legacy systems lose this test almost by definition.
Together: the technical case got better and the cost of doing nothing got worse in the same year.
Where the Trap Sits
Most legacy modernization programs fail in the same place. They fail because somebody decided to rewrite the system rather than understand it first.
The rewrite trap looks like this. You pick a legacy system. You scope a 14-month rebuild. The vendor estimates $4M. You sign the SOW. Twenty months in, you have spent $7M, the new system covers 60 percent of the old one's behavior, and the business has shifted underneath the project. You either ship a degraded replacement or you write off the spend.
The reason this keeps happening is that the team underestimated the implicit specification embedded in the legacy system. Not the documented requirements. The undocumented ones. The validation rule that exists because of a 2014 audit finding. The default that one customer's billing depends on. The race condition that the operations team works around at 2 a.m. on the last business day of every quarter.
AI does not change the trap. AI changes whether the spec extraction is feasible at all.
The Honest Sequence
Here is the modernization sequence that actually ships in 2026.
Step 1 - Inventory and price. List every legacy system. For each one, capture: lines of code, monthly change requests, last security audit, regulatory exposure, headcount required to operate, hiring difficulty. Put a dollar number on each of the three tax lines for each system. Most teams skip this step. The teams that ship do not.
Step 2 - Specification extraction. Pick the highest-tax-line system. Run AI-assisted spec extraction across it. Output: a structured specification in plain English, with traceability back to the source code, reviewed and signed off by the people who currently operate the system. This artifact is durable. It survives the migration and becomes the system of record for what the system actually does.
Step 3 - Decision gate. With the spec in hand, you now have an honest choice: modernize in place (refactor the legacy code module by module against the spec), rebuild against the spec on a modern stack, or sunset the system entirely. The third option is more often the right answer than people admit.
Step 4 - Migrate or rebuild against the spec. Whichever path you pick, the spec governs. AI-assisted code generation, AI-assisted test generation, AI-assisted documentation. The spec is the contract.
Step 5 - Decommission with audit trail. When the old system is shut down, the spec, the migration plan, the test evidence, and the change log all become the regulatory artifact for AI Act and DORA-equivalent requirements.
Most legacy programs collapse between steps 1 and 2 because nobody priced the risk hard enough to fund the spec work.
What This Costs
Cost depends on system size and regulatory exposure. Rough envelopes for a mid-sized financial services or healthcare CTO planning a 2026 program:
A 200,000-line legacy system with moderate regulatory exposure typically lands in the $800K to $1.5M range for spec extraction and decision gate. Full modernization or rebuild scales from there based on path chosen. Sunset costs are usually under $300K including data archival and customer communication.
The number that matters more is the three-tax-line cost of doing nothing for another 18 months. That number is almost always larger than the cost of the spec phase. Once it is on paper, the conversation with the CFO is straightforward.
Real Estate Identity Resolution
Duplicate records are hiding your best leads. Identity resolution reveals true buyer intent and fixes your pipeline.
Call to Action
What Logiciel Does Here
Logiciel runs legacy specification extraction and modernization programs for CTOs whose code is core to revenue, not a side system. The work starts with the same three-tax-line audit described above and ends with a defensible decision gate. Not a rewrite-by-default.
If you want to size your own legacy risk before you commit to a program, the AI Velocity Blueprint covers how senior engineering teams are pricing modernization and migration capacity in 2026, including the spec-first sequence. The Evaluation Differentiator Framework is the working document we use with CTOs to assess implementation partners specifically for modernization work, where the test bar is higher because the cost of being wrong is higher.
For a direct working session on a single legacy system, our 30-minute CTO call is the fastest way to get an honest second opinion on whether to modernize, rebuild, or sunset.
Frequently Asked Questions
How do I know which legacy system to address first?
Run the three-tax-line audit on every legacy system in your portfolio. Sort by total annual cost. The top one is almost always obvious, and it is almost never the oldest one. It is the one with the highest combined velocity, risk, and hiring tax.
Is AI code translation good enough to trust?
For specification extraction, yes, with senior engineer review. For direct code-to-code translation, only with extensive test coverage on the target side. Amazon's $260M Q Developer result is real but they invested heavily in validation pipelines. Most teams do not have that yet.
What is the right team size for a legacy modernization program?
Smaller than you think. A senior tech lead, two engineers who know the legacy stack, two engineers who know the target stack, and one product person who can adjudicate edge cases. The AI tooling reduces headcount needs more than it increases them, but only if the seniority is high.
How does the EU AI Act change modernization priority?
It rebalances the ROI. Systems that produce automated decisions affecting customers, employees, or credit need to demonstrate documentation, oversight, and impact assessment by August 2026. Legacy systems that produce these decisions but cannot demonstrate the documentation are now a regulatory liability, not just a technical one. That moves them up the queue.
Should I sunset rather than modernize?
More often than teams admit. The sunset decision usually wins when: the system serves under 10 percent of revenue, the regulatory exposure is high, replacement SaaS exists, and customers will tolerate a transition. The spec extraction work in step 2 of the sequence often surfaces this answer.
