AI-Based Mainframe Migration on Google Cloud: How to Reduce Cutover Risk With Assessment and Dual Run

Quick Answer: the safest AI-based mainframe migration plan is assessment-first, dual-run-gated

Google Cloud’s AI-based approach to mainframe migration is most useful when we treat it as a risk-control system: use the Mainframe Assessment Tool to reverse-engineer dependencies and boundaries, choose either like-for-like modernization or a rewrite route per workload, and then gate cutover through Dual Run running old and new in parallel until transactions, messages, and data changes match.

• Use this approach when the estate is interdependent: If applications touch DB2, VSAM, or IMS structures and are tightly integrated with transaction processing, a dependency-first assessment is often the only practical way to understand migration blast radius.
• Insist on Dual Run when outputs must remain unchanged: If regulators, auditors, or downstream systems require identical behavior, parallel execution with output comparison is the practical antidote to guesswork.
• Split the program by workload intent: Stable back-office batch work can fit like-for-like modernization, while differentiating systems justify a rewrite or reimagination.
• Prefer incremental data moves when analytics value is urgent: The Mainframe Connector path that copies data into BigQuery, Spanner, Cloud SQL, or Cloud Storage can unlock usage before the core system is replaced.
• Avoid this as a shortcut for unclear scope: If we haven’t defined application boundaries across business functions, AI assistance won’t save a program that is still architecturally undefined.

The news signal: cloud competition is shifting from code conversion to provable equivalence

Google Cloud is positioning a mainframe migration portfolio that combines its Gemini models with existing mainframe-oriented products across assessment, application modernization, pre-production testing, and data migration. The strategic signal for engineering leadership is that the cloud vendor is betting less on one-time translation and more on the ability to interpret business logic and reduce failure risk in large, interdependent estates.

Assessment isn’t paperwork anymore—it’s reverse-engineering the real system you run

The Mainframe Assessment Tool is described as reverse-engineering legacy applications: mapping dependencies between applications and data stores, extracting business rules from older code, generating documentation, and identifying application boundaries across business functions. The critical engineering implication is that the assessment output becomes the authoritative model of the system, especially when relationships span DB2 databases, VSAM files, IMS structures, and tightly integrated transaction processing.

• Dependency maps that include data stores, not just code: A migration plan that ignores how programs touch DB2, VSAM, or IMS structures will undercount the work and overestimate modularity.
• Business-rule extraction that can be reviewed: When logic is embedded in older code paths, treating extracted rules as a reviewable artifact reduces the chance of reimplementing the wrong behavior.
• Application boundary identification across functions: Boundaries determine whether we can modernize like-for-like safely or whether we are implicitly rewriting interfaces.
• Documentation generation that feeds automated workflows: The value is not the PDF; it is the ability to drive planning and execution workflows from a consistent discovered model.
• Visibility into obscure relationships: In large estates, critical workflows often depend on non-obvious coupling that does not show up in a simple source-to-source conversion effort.

The fork in the road: rewrite for new value or modernize like-for-like for controlled risk

Google Cloud frames two broad patterns: one path to rewrite or reimagine when the business wants to change logic or redesign customer-facing systems, and another deterministic like-for-like modernization path intended to preserve behavior while changing underlying structure. At Plavno, we think this is the correct framing because it forces a decision about what is being optimized: new capabilities and product change, or reduced technical debt and operational constraints without changing outputs.

1. Start from workload intent, not language: Decide whether the workload is meant to change business logic or remain externally identical; this determines whether equivalence is the primary acceptance test.

2. Use assessment outputs to define boundaries: If the assessment shows cross-application coupling through DB2, VSAM, or IMS structures, we treat the boundary definition as a prerequisite to any modernization plan.

3. Select a route per workload, not per estate: Mixed strategies are normal; stable batch processing can go like-for-like while differentiators get rebuilt.

4. Design verification before design implementation: If Dual Run is required, we plan how parallel execution and comparison will be run long before the first new component ships.

5. Decide how data will move incrementally: If the business wants analytics or new services now, we plan connector-driven data copying into services like BigQuery or Spanner alongside application modernization.

Dual Run is the new cutover architecture, not just a testing feature

Dual Run is presented as a way to run production workloads in parallel across the mainframe and Google Cloud, comparing whether transactions, messages, and data changes match until equivalence is achieved. For CTOs, this reframes the hard part of modernization: proving that a long-established system behaves the same way under real production conditions. The engineering trade-off is operational overhead and careful comparison logic, but the payoff is replacing a leap-of-faith cutover with a measurable gate.

Where Dual Run actually saves programs: transactions and state changes, not unit-level logic

In practice, modern systems fail equivalence not because a single function was mistranslated, but because transactional behavior and state transitions differ when messages, data changes, and side effects interact across boundaries. Dual Run’s value is that it compares those production-level outputs side-by-side. If we treat it as a first-class pipeline—fed by assessment-defined boundaries and driven by real workloads—we can keep the like-for-like promise honest instead of discovering mismatches after cutover.

Incremental data migration changes the timeline: analytics can move before the core does

The Mainframe Connector is described as copying data from mainframe systems into cloud services including BigQuery, Spanner, Cloud SQL, and Cloud Storage, handling codebase and data type conversion and integrating into existing ETL processes. The business shift is that we can move selected data incrementally rather than through a single transfer, which aligns with the industry push to use long-held operational data for analytics and digital services without waiting for full core replacement. This is exactly the kind of modernization we often automate through AI automation programs.

• Operational analytics without core replacement: Copy subsets of operational data into BigQuery or Cloud Storage so analytics teams can work without waiting for application cutover.
• Incremental migration as a risk hedge: When full replacement is risky, staged data copying into Cloud SQL or Spanner can validate conversion assumptions earlier.
• Hybrid modernization sequencing: Data can move and be validated while applications are still being assessed or while like-for-like modernization work proceeds.
• ETL integration as the control point: Because the connector integrates with existing ETL processes, the practical win is fitting migration into established data governance and operational workflows.
• Selective scope as a modernization lever: Moving only the data needed for new services can produce near-term outcomes while the rest of the estate remains stable.

Central claim: AI won’t de-risk migration by translating code; it de-risks it by making behavior provable

What is happening is that Google Cloud is pushing AI deeper into mainframe modernization via Gemini-assisted assessment, planning, and tooling like Dual Run and the Mainframe Connector. Why it breaks a common engineering practice is that teams have long treated migration as a conversion project—move code, then test—when the real risk is in unobserved dependencies and unproven behavior across transactional boundaries. The right response is to architect the program around discovery plus equivalence gates: assessment defines boundaries and dependencies, and Dual Run becomes the acceptance mechanism for any like-for-like claim.

Plavno’s perspective: treat Gemini as an analyst, but keep accountability in your architecture

At Plavno, we view Gemini-powered analysis and agents as accelerators for understanding legacy logic and generating documentation, specifications, and plans, but not as substitutes for architectural accountability. The assessment tool can extract business rules and map dependencies; that helps teams make fewer blind assumptions when estates are tied to proprietary databases, file formats, transaction monitors, and operational tools. The engineering choice is whether we turn those outputs into enforceable migration contracts and verification gates, which is where AI consulting creates the most leverage.

The artifact that matters most is the boundary you can test in parallel

If we can identify application boundaries across business functions from assessment, we can define what must remain stable for a like-for-like path and what is free to change in a rewrite path. This is also how we prevent teams from accidentally turning a deterministic modernization into a redesign by changing data semantics or message flows while believing they are preserving behavior.

• A dependency model that engineers can challenge: We need a map of relationships between applications and data stores that is reviewable, not just generated.
• A business-rule narrative aligned to outputs: Extracted rules are only useful if we can connect them to observable transactions, messages, and data changes.
• A modernization decision per boundary: For each boundary, we decide like-for-like versus rewrite and tie the decision to verification strategy.
• A Dual Run plan tied to operational realities: Parallel execution is not abstract; we define how long equivalence needs to be demonstrated to satisfy internal and external approval.
• A data migration slice strategy: If we use the connector, we define which datasets go to BigQuery, Spanner, Cloud SQL, or Cloud Storage first and why.

Business impact comes from avoiding the two failure modes: stalled rewrites and unprovable cutovers

For large organisations with complex legacy estates, the real cost is not just mainframe licensing or scarce staff; it is the opportunity cost of systems that are hard to change because the estate’s relationships are obscure and brittle. An AI-assisted assessment that maps dependencies and extracts rules can shorten the time to a credible plan, but the measurable business impact arrives when Dual Run turns the cutover into a provable equivalence exercise rather than an argument. That is how we see cloud modernization initiatives succeed under digital transformation constraints.

The trade-off is that parallel execution and comparison is operationally heavy, and incremental data copying introduces a period where cloud analytics and legacy operations coexist. But for regulated or mission-critical environments, that coexistence is often the only acceptable path because it lowers the chance that the first true end-to-end test happens after the old system is gone.

Regulatory equivalence is a product requirement, not a QA preference

Google Cloud notes that some global enterprises are already using Dual Run to meet regulatory approval requirements in tightly controlled sectors. The implication is that equivalence evidence becomes a deliverable: we plan for it like we plan for uptime, because it is what enables approval when the new environment must be demonstrably identical in behavior.

How we evaluate this in practice: design the verification system before the target system

When we evaluate AI-based mainframe migration approaches like Google Cloud’s, we start by asking whether the program can produce a stable discovered model of the estate and whether it can run equivalence checks under production workloads. If assessment yields boundaries and dependency maps, we can structure workstreams around them; if it does not, teams will revert to migrating what they can see and discovering what they missed at the worst time. Dual Run then becomes the gate that controls when any boundary is eligible for cutover.

Real-world application patterns: hybrid modernization is the default in complex estates

Google Cloud’s own example of financial services is the most realistic framing: we rarely see a single strategy win across an entire mainframe estate. Stable workloads that exist to run reliably and predictably are strong candidates for like-for-like modernization, where Dual Run provides equivalence confidence. Systems that are competitive differentiators are better treated as product work, where assessment-derived business rules inform new designs and implementation plans, accepting that behavior will change by intent.

Risks and limitations: AI interpretation can mislead if you don’t control scope and truth sources

Google Cloud is clear that mainframe projects go beyond simple code conversion because older applications are tied to proprietary databases, file formats, transaction monitors, and operational tools. That reality is also the limit of any AI-led interpretation: if the tool infers business rules from older code, engineers still need an agreed truth source for what the system must do, especially when obscure relationships drive production behavior. Dual Run reduces this risk for like-for-like paths by grounding acceptance in matching transactions, messages, and data changes, but it cannot decide which differences are acceptable when the business actually wants change.

• Boundary confusion disguised as progress: If assessment outputs are not turned into agreed boundaries, teams can modernize pieces that look independent while remaining coupled through DB2/VSAM/IMS structures.
• Equivalence criteria that don’t reflect business truth: Dual Run compares outputs, but we still must define what matching means for transactions, messages, and data changes in operational terms.
• Incremental data copy creating dual sources of truth: Copying data into BigQuery, Spanner, Cloud SQL, or Cloud Storage can accelerate analytics, but it introduces a coexistence period that must be governed.
• Like-for-like claims drifting into redesign: Small changes to data types or message flow can change behavior while teams believe the external interface is unchanged.
• Overreliance on AI-generated documentation: Generated artifacts are valuable, but they must be reviewable and reconciled with how production workflows actually operate.

The closing insight: your modernization program is a verification program with a migration output

The most market-relevant change in Google Cloud’s approach is the emphasis on making legacy behavior legible and then provable: assessment to understand what the system is, Dual Run to prove equivalence under real workloads, and connector-based data copying to unlock selective value early. For estates where a single transaction scenario can involve millions of lines of code, this is not academic; it is a practical way to avoid the two extremes of freezing the mainframe forever or betting everything on a single cutover.

At Plavno, we recommend treating equivalence evidence and boundary definitions as the deliverables that govern scope, staffing, and timeline. If you need to scale the engineering capacity around those deliverables without losing operational context, we often combine a core architecture team with outstaffing to execute boundary-by-boundary modernization while keeping verification ownership centralized.

Author: Plavno team

Last updated: August 2026

Summarize this blog post with AI

Chat GPT Perplexity Claude Gemini