"Modernize First" Is Why Your AI Program Is Still a Pilot

Every stalled AI program has the same line on the slide: we have to finish the modernization first. It's usually half true and entirely expensive.

Half true, because some systems really do block an agent. Expensive, because "finish the modernization" is rarely scoped to the systems the agent actually needs. It's scoped to the whole estate instead. An estate-scoped program is a two-year program, so the first agent ships in year three, and by then the business case that funded it has been handed to someone else. That's the legacy modernization trap in miniature: estate-wide scope dressed up as a prerequisite.

Our position is narrow, and we'll defend it: sequence the migration around the first use case, not the inventory. Move the systems an agent must read from or write to. Reach the rest through a governed integration layer. Then expand.

The fresh numbers support the premise, not the conclusion

On November 9, 2026, Google Cloud published findings from a survey it ran with Hypothesis Group covering 1,250 enterprise IT and business decision-makers across the United States. Nearly half, 49%, said reliance on on-premises software has delayed, reduced in scope, paused, or canceled AI or other technology initiatives, per Google Cloud.

That's a real finding, and it's worth taking seriously. It's also worth reading precisely. It's a vendor-commissioned, US-only, self-reported study, and it defined legacy narrowly as software running locally on computers and servers rather than natively in the cloud, a definition that counts every on-prem workload as legacy whether or not it actually blocks an agent, per Google Cloud. So the survey measures how many leaders believe on-prem software delayed their AI work. It does not measure whether finishing a full legacy modernization first would have been faster.

The same study found 80% agree a provider's installed base should not determine which AI technology an organization uses, and 78% think the providers who led the last era may not be best placed to lead the AI era, per Google Cloud. Those are lock-in findings. They say nothing about what order to do the work in.

When programs die, legacy is usually not the cause of death

Look at where the failure research points, and the blame moves.

Gartner predicted in a June 2025 press release that over 40% of agentic AI projects will be canceled by the end of 2027. It attributed the failures to escalating costs, unclear business value, and inadequate risk controls, not to legacy infrastructure, per Gartner. That's a standing forecast from 2025, not a measured outcome, and should be read as such.

MIT's NANDA study found roughly 95% of enterprise GenAI pilots delivered no measurable P&L impact. Its lead author pointed to a learning gap and flawed enterprise integration, not model quality, per Fortune. The 95% headline has been widely contested, and we're citing secondary coverage here, so treat the direction as the signal rather than the decimal. A July 2026 Forbes analysis of Forrester's 2026 assessment reports roughly three-quarters of enterprises adopting agentic AI with only a sliver reaching real production. It also notes that 49% of security decision-makers in Forrester's 2026 security survey flagged agentic AI as a concern, per Forbes.

Every one of those causes sits upstream of the infrastructure: cost, unclear value, weak controls, integration. A modernize-first sequence doesn't fix any of them. It just postpones the moment you discover them. None of that argues against legacy modernization. It argues against doing it first.

Access is the real constraint

WSO2 makes the argument cleanly: what blocks enterprise AI is access, not models. Put a governed integration layer, including an MCP server, in front of the legacy system, and agents can reach it without the source system being modified, taken offline, or even aware anything changed. MCP is the standardized interface agents use to call a system's functions, per WSO2.

The common barriers each have a layer-level answer, per the same analysis:

• Batch cycles where the agent needs real time - Change Data Capture (streaming each row change out as it happens instead of waiting for the nightly batch).
• No modern API - an MCP wrapper over what exists.
• Fragmented identifiers across systems - a transformation layer.
• Perimeter-era security - zero-trust, agent identity, and audit at the integration boundary.

WSO2 frames that as the difference between a twelve-week integration project and an expensive modernization gamble. It cites McKinsey's 2023 figure that large ERP upgrades can run as high as $500 million across years, per WSO2. Frogslayer's June 2026 guide puts the same rule of thumb at roughly 80% of replacement's value for 20% of the cost and risk, a practitioner heuristic rather than a measured benchmark, and defines a system as legacy when the cost of its limitations exceeds the cost of changing it, regardless of age (Frogslayer).

That's the definition we'd ask a planning committee to adopt. Migrate a system when it blocks the use case; its age is beside the point. Legacy modernization done right is targeted, not total.

Where modernize-first is genuinely right

Wrapping doesn't always win. These are the conditions where legacy modernization is the right call, not a default starting point.

Frogslayer names the hard conditions: data siloed in proprietary non-API formats, business rules baked into application code (which it says cannot be exposed to agents without a rewrite), batch-only flows where agents need event-driven updates, and inconsistent historical data (Frogslayer). Mactores adds that a finished cloud migration can still leave an estate with no semantic layer (no shared definition of what "active customer" means), no query-time permissions, no row-level lineage, no visible freshness, and no governed write path; on its seven-question readiness test, a bottom-band score means the data platform is the critical path, and funding more pilots just burns budget without reaching production (Mactores).

Wrapping carries consequences too. A December 2025 Wezom analysis is blunt: technical debt doesn't disappear, performance is capped by the slowest legacy link, security weaknesses in the core are only partly mitigated, and database scalability bottlenecks remain (Wezom).

So run the test one system at a time. Mactores describes the useful middle: at six or seven of seven readiness checks, agents can go to production read-only now while modernization effort goes into the write path (Mactores).

The sequence we actually run

This is legacy modernization scoped to the use case, not the estate.

1. Pick the first workflow by value, not by data availability. Frogslayer's portfolio advice is to start with the system that blocks the AI deployment you want to make: identify the highest-value workflows, trace back to the systems producing their inputs, modernize those (Frogslayer).
2. Triage those systems only. Four questions per system: is the data fresh enough, can access be scoped to the agent's identity, can you trace a row back to its source, and is there a safe path for the agent to write back? Weeks of assessment, not quarters.
3. Migrate the failures. Wrap the passes. Two or three systems typically move. The rest get a governed connector.
4. Ship read-only first. Write access follows the governed write path, not the other way round.
5. Measure, then expand. Frogslayer calls scope expansion, the Big Bang, a top failure mode, and prescribes scoping the first modernization to a single system, measuring it, then growing (Frogslayer).

The governance objection has a platform answer now

What does your security team actually ask for before an agent touches the order system? Usually scoped access, an audit trail, and protection against a prompt that tries to steal data. That used to mean a bespoke build. Less so today. At Google Cloud Next '26, Google announced more than 50 Google-managed MCP servers generally available or in preview, with Cloud IAM deny policies for fine-grained access control, Model Armor protecting in-line against indirect prompt injection and data exfiltration, OTel tracing and Cloud Audit Logs, and interoperability with clients including Claude (Google Cloud). Check the GA-versus-preview status of any individual server in Google's docs before you plan around it. Separately, Google Cloud API Gateway can act as a native MCP server through OpenAPI 3 annotations, exposing existing REST APIs to agents (Google Developers Blog).

The Gemini Enterprise Agent Platform, launched April 22, 2026 as the evolution of Vertex AI, supports third-party models including Anthropic's Claude families (Google Cloud). Model names move fast, and Google's Claude availability page was last updated 2026-11-09, so confirm versions at build time rather than at planning time.

Spend control deserves its own line, because Gartner put escalating costs near the top of the cancellation list. Cloud Companion exists to give finance and engineering a shared view of agent spend before a pilot quietly becomes a line item nobody owns.

The honest limit

We could not find a named, independent case study quantifying time-to-value for an agent shipped against an unmigrated system versus after a full modernization. The strongest form of our claim remains an argued position. What the published evidence does establish is where programs die: cost, value, controls, integration, and none of those get safer by waiting two years.

If your modernization plan can't name the three systems the first agent needs, it isn't a sequencing decision. It's a deferral. A scoped Discovery & Assessment settles that argument in weeks.