Why Most Legacy Modernization Projects Never Reach Production

Key takeaways

• Most programs stall on sequencing, not technology. Discovery and the first migration wave use up the money that cutover and legacy retirement were supposed to get.
• Gartner expects more than 70% of mainframe exit projects started in 2026 to miss their intended benefits. It blames an overestimation of what generative AI tooling can do.
• AI plans stall at the same point. The logistics company's invoice audit agent sat idle because the rates it needed were still locked in Oracle.
• In regulated industries, audit evidence sets the cutover date. Auditors want lineage, reconciliation reports and rollback results, and those are cheap to capture during the work and expensive to rebuild afterward.
• The commercial model decides who pays for a slip. On a fixed-date, fixed-fee contract with overage protection, delays inside the delivery firm's control are the firm's cost, not yours.
• Programs that ship plan backward from a signed date. Legacy system retirement goes into the statement of work as a deliverable, with its own date.

We've been building on AWS since 2008, much of it modernizing secure, compliance-heavy systems, including AI systems that had to clear HIPAA, PCI DSS and internal audit on their first review. The way programs fail hasn't changed much in that time. A program gets scoped and staffed, produces a stack of architecture diagrams and then stalls at the handoff between strategy and implementation. Some limp into a pilot. Others go live a year late at several times the budget. Either way, the board paid for a modernized platform and got a status report.

Gartner sees the same pattern from the outside. In June 2026 it predicted that more than 70% of mainframe exit projects initiated in 2026 will fail to produce their intended benefits, and it put the cause down to "an overestimation of generative AI (GenAI) tooling capabilities." When we audit a stalled program, though, the tooling is rarely the main problem. What we usually find is a plan that spent its first two quarters on discovery, scoped the migration but not the retirement, and started a parallel run with no end date.

This guide is for CIOs, CTOs, CFOs and data leaders with a legacy modernization program in flight on AWS, or about to sign one. To keep it concrete, we'll follow one made-up but typical company through it: a US third-party logistics provider that bills shippers and settles with carriers out of a 2009-era Java application on Oracle. A nightly batch copies billing data into an on-premises SQL Server warehouse. The company is publicly traded, so SOX covers its billing controls, and its Rotterdam warehouse puts European customer data under GDPR. Eighteen months ago it signed a time-and-materials modernization program with a large systems integrator, planned at 12 months and about $4 million.

What are the most common stall points in a legacy modernization program?

Six of them, and the logistics company ran into every one.

Each of these can be designed out before the statement of work is signed. Finding them in month five, with the board asking for a date, costs a great deal more.

Where exactly do modernization programs stall?

At the handoffs, mostly. At the logistics company, nobody owned the step from discovery to build, or the one from the parallel run to the cutover decision, and those were where the months went. The map lines up each stage of a program with the way it tends to stall and the control we'd put in front of it.

Is discovery eating your modernization budget?

It ate the logistics company's. The integrator's team spent the first two quarters interviewing billing staff, cataloging about 1,400 stored procedures and drawing dependency maps, all billed by the hour, and by the end of month six about 40% of the budget was gone. When someone finally asked for a test harness and a cutover rehearsal, there wasn't money left for either.

We've seen the same thing in payments. A branded-payments company came to us after two earlier modernization attempts had stalled, and its case study puts the pattern in one line: "Discovery eats the budget; cutover gets de-funded; the program stalls or ships at a quality the regulator does not approve." The third attempt went differently because agents did the code analysis, dependency mapping, test generation and parallel-run instrumentation, which kept the cutover budget whole. The PCI DSS-aligned platform went live without an audit incident during cutover.

Did the migration become the finish line?

It did at the logistics company, and the rehost itself wasn't the mistake. Moving app servers to Amazon EC2 is a reasonable first step, especially with a data center lease about to run out. The mistake was that the plan paid for the move and nothing after it. The Oracle schema and the billing logic in its stored procedures stayed exactly as they were, and the program reported month nine's move as a milestone. Its CFO still had the same Oracle renewal on the calendar, now with an AWS invoice next to it.

Why do parallel runs never end?

Because nobody wrote down what done looks like. A parallel run is the right control for a regulated workload like the company's billing, which feeds SOX-relevant revenue figures. It turns into a trap when it starts without exit criteria, and that's what happened in month 11. Seven months later, both systems were still producing invoices, a few hundred a cycle still didn't match, and nobody owned the difference.

We'd have written three things into the contract before the run began: the reconciliation threshold, the number of clean cycles required (two consecutive month-end closes is a common bar in financial reporting), and the date the legacy system goes read-only. Kaja Hussain, a senior forward-deployed engineer in our database and application modernization practice, makes the same point in a guide to application modernization: "Systems kept running for safety tend to keep running forever, and the savings case never arrives."

Has anyone rehearsed the rollback?

Every cutover plan has a rollback section. Far fewer have a rollback that's been run against production-scale data with the clock going. The logistics company's runbook had four pages on it, and nobody had ever tried them, so each go/no-go meeting ended with someone suggesting one more quarter. Kaja's line on this is short: "An untested rollback plan functions as a control only on paper." We'd rehearse it at least twice before cutover, timed, with data integrity checks on the way back.

Who owns the savings after cutover?

Usually nobody, which is the problem. The company's business case counted about $1.1 million a year from Oracle support and the data center exit, but neither saving was tied to a named budget line or a date, so when finance asked in month 15 where the money was, the program had no answer. We'd give every promised saving an owner before the build starts and pin it to something real, such as the next database license renewal or the end of a colocation lease.

Why are AI initiatives stalling at the same point?

Because they're built on the same data and systems, and those were never modernized enough to support anything in production. McKinsey's 2026 State of AI survey puts a number on the gap. Nearly nine in ten respondents reported using AI regularly in at least one business function, yet only 37% of respondents "attribute at least some EBIT impact to AI use," about the same as the year before. That's a lot of pilots and not much that moves the P&L.

The logistics company had its own version. Finance wanted an agent to audit carrier invoices against contracted rates and accessorial charges, a job three analysts did by sampling. The rates still lived in Oracle stored procedures that only two people understood, and the warehouse the agent would read from was a day behind, so the pilot never had anything trustworthy to check against. When a modernization program stalls, the AI roadmap behind it stalls too.

Gautham B, a forward-deployed engineer in our data engineering practice, makes the same argument in an analysis of enterprise AI agents in production: "What's missing is rarely the model." Before an agent touches production records, we'd want four things settled, and for the invoice audit agent we'd have written them down like this:

Waiting has a security price as well, because two half-migrated environments give attackers two ways in. IBM's 2026 Cost of a Data Breach research found the average breach now costs a record $4.99 million worldwide, with AI-driven attacks adding an average of $1 million per breach.

What does data pipeline modernization on AWS have to do with reaching production?

More than most plans assume. Pipelines are where a program can stall while everyone thinks it's finished, because the dashboards keep refreshing. At the logistics company, the integrator copied the nightly SQL Server batch to AWS Glue job by job, and three months later a finance analyst noticed that late carrier adjustments never showed up on the AWS side. Nothing had been reconciled against the legacy source, there was no lineage to trace the gap, and no schema rules to catch it.

The AWS services themselves are well understood. What separates a shipped pipeline from a stalled one is the validation work around them: parallel-run instrumentation, row-level reconciliation, and lineage captured as an output in its own right. That's the work our data warehouse migration engagements concentrate on, because it's also the work that used to eat the most senior engineering hours.

Synaptics is a good example from outside regulated work. Its chip designers were waiting on a bottlenecked electronic design automation cluster, with job queues backing up. In the Synaptics engagement, discovery took days rather than the quarters of analyst hours a traditional integrator would have proposed, and our engineers spent the money that saved on a smart-queue architecture and the cutover. Throughput on one of its largest EDA clusters rose by up to 40%, queue wait times dropped 75%, and the operational data lake on AWS is now what the next initiative builds on.

How do compliance requirements change the path to production?

In regulated industries, they decide when cutover can happen. If compliance is the last box on the plan, the go/no-go meeting is where you find out the evidence your auditors need was never captured during the parallel run. For the logistics company, SOX meant the billing and revenue controls had to hold all the way through the parallel run, and GDPR meant the Rotterdam customer data had to stay in an EU Region with its lawful basis intact. The frameworks in the figure are the ones we see shape modernization plans most often for US and European buyers.

Europe gave itself more time this year. The AI Act's rules for the high-risk systems in Annex III, which would cover something like an AI tool allocating shifts at the logistics company's Rotterdam warehouse, were due in August 2026. The Digital Omnibus on AI, published in the Official Journal on July 24, 2026, moved them to December 2, 2027. More runway doesn't change what an auditor asks for when an AI component touches regulated data, so we'd still capture the evidence now.

What will auditors ask for at cutover?

At the logistics company, we'd expect five requests, and we'd produce each one during the work rather than after it:

• Lineage from every target table back to its Oracle or SQL Server source
• Reconciliation reports from the parallel run, with the thresholds and who signed them off
• Proof the rollback was rehearsed, with timings and data integrity results
• IAM policies and access logs mapped to the SOX controls in scope
• A traceable record of every decision the invoice audit agent made

We build validation harnesses that produce these artifacts by design, because retrofitting audit evidence after cutover is slow and expensive. KlearTrust's agentic claims platform is the healthcare version of the same idea: the production system we shipped in 12 weeks replaced a six-month manual review cycle and passed HIPAA and internal audit on its first review. In the case study's words, "The auditor signed off on the architecture, not on a separate test."

What does a stalled modernization project really cost?

Far more than its invoice. The extra costs come from places the budget never listed, like a second environment billing every month, a license exit date that slides past, and AI work parked until the data is ready. We'd put the overrun at two to three times the budget and one and a half to three times the schedule for a typical stalled program; those ranges, also in the figure, come from our own delivery experience rather than an industry survey.

The logistics company was at about 1.75 times its budget when it called us, and the meter was still running. Its Oracle renewal was due in March, the renewal quote assumed another full term, and the AWS environment it had built for the parallel run was billing every month whether or not billing moved.

There's a CFO-friendly side to this. Most of the budget an AI program needs is already inside IT spend, tied up in the legacy database license, the warehouse nobody runs new workloads on, and the integration tier that bills hours to keep itself alive. Our series on funding AI from your existing budget puts it in one line: "The AI budget is trapped, not missing." Retiring the legacy stack on a fixed date is how that money comes back into the plan.

Fixed fee or time and materials: which commercial model gets you to production?

The one that makes the delivery firm pay for its own delays. The logistics company's integrator billed by the hour, so every month the parallel run dragged on was another month of revenue for it, and nothing in the contract said otherwise. A fixed-date, fixed-fee contract with overage protection pays for a shipped system and a retired legacy stack instead.

Our delivery commitment spells out how that works on our side. When a delay past the committed date sits inside Mactores' control, we carry the cost of the extra work, and delays caused on the customer's side convert to time and materials "at the rate disclosed upfront in the same document," so both sides can see the commercial effect before signing.

Fixed fees only hold up when the delivery firm can absorb most of the engagement hours without a pyramid of analysts, which is why agent-native delivery matters to a buyer. On our engagements, Aedeon, the agent platform we deliver with, absorbs 60 to 70% of the work, mostly the repetitive discovery, mapping, validation and test generation. That's what lets a firm commit to a date and still protect its margin.

What does a production-first modernization plan look like?

It starts at cutover and works backward. For the logistics company, we'd have fixed the date the Oracle billing system goes read-only first, then sized the parallel run, the build and the design to fit in front of it. The how we work page lays the method out as five phases, and each one has "an entry condition, a named output, and a gate that only your signature opens." The figure splits the parallel run out as its own step, since it's the phase most likely to lose its end date.

The gates are there to bring bad news forward. The same page says, "If a plan is going to break, it should break in week three on a proof rather than in month five on a deadline." The structure holds whether you're moving Oracle or SQL Server to Amazon Aurora, rebuilding a data warehouse, or putting AI agents on a modernized platform, and our application and database modernization programs write the retirement date into the scope on day one.