Google Cloud Rejects the Mainframe Big Bang for an AI-Guided Migration Path

Google Cloud has outlined a four-stage alternative to risky mainframe migrations, using AI analysis, code generation, data conversion, and parallel validation before cutover.

The proposal challenges a familiar choice. Enterprises can keep maintaining aging systems, or attempt a large migration whose dependencies become visible only after work begins. Google argues that neither option addresses the hardest problem: understanding what the existing system actually does.

Its answer connects the Mainframe Assessment Tool, Gemini CLI, Mainframe Connector, and Dual Run into one continuous process. Teams first recover business rules and dependencies. They then build cloud applications around reviewed requirements, move the relevant data, and compare both environments under real workloads.

That sequence makes this more than another code-conversion announcement. The primary contest is iterative modernization versus the big-bang migration, not cloud infrastructure versus mainframe hardware.

Google also faces established alternatives. IBM is applying AI while preserving a central role for IBM Z. AWS is promoting an agentic service that traces generated requirements and code back to mainframe sources. Each vendor recognizes that code generation alone cannot settle whether a replacement system is correct.

The critical question is therefore not whether Gemini can translate COBOL. It is whether Google’s connected workflow can preserve decades of hidden business behavior while letting enterprises modernize in manageable pieces.

Google Cloud Turns Four Tools Into One Migration Path

The important change is the connection between assessment, generation, data movement, and production validation.

Google’s modernization framework begins with reverse engineering. The Mainframe Assessment Tool examines source code, database structures, transaction monitors, scheduler configurations, and relationships between assets.

It supports COBOL programs, copybooks, JCL jobs, procedures, includes, and related artifacts. The tool uses Gemini to generate summaries, technical specifications, and proposed business rules from that material.

Business rules are the policies encoded inside an application, such as eligibility conditions, interest calculations, or transaction-routing decisions. They matter because an old program’s observable behavior often exceeds its surviving documentation.

Google says teams can review, filter, and validate extracted rules before exporting them. That human checkpoint separates the proposal from a simple instruction to translate every line into Java or another modern language.

The assessment can also divide an estate into business domains and smaller migratable units. A migratable unit is a bounded collection of programs, data, and dependencies that can move together without breaking adjacent services.

This partitioning creates the basis for an iterative program. A bank might isolate one reporting flow before touching payment authorization. An insurer might move a document-processing service while leaving claims settlement on the mainframe.

After assessment, Gemini CLI supports forward engineering. That means teams use validated requirements to plan a target architecture and generate new code, instead of treating the old codebase as the target design.

The workflow can propose data models and services across Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB, and Cloud SQL. Those proposals still require architectural review because a generated recommendation is not an operational decision.

Mainframe Connector handles another frequently underestimated problem. It copies and converts mainframe data, including EBCDIC-encoded records, into formats that Google services can use.

EBCDIC is a character encoding associated with IBM mainframe environments. Converting it correctly requires more than changing text representation because records can contain packed decimals, copybook layouts, and application-specific conventions.

Dual Run completes the proposed loop. It executes workloads in the existing mainframe environment and the cloud environment, then compares their results before production cutover.

The connected process changes where teams place their confidence. Instead of trusting a one-time conversion, they accumulate evidence across discovery, rule review, implementation, data testing, and parallel execution.

That is the event’s central claim. Google is presenting modernization as a controlled system of evidence, not a single transformation project.

Why Mainframe Modernization Is Not a Code Translation Job

A syntactically correct conversion can still reproduce the wrong business system.

Large mainframe estates rarely behave like tidy collections of independent applications. A nightly batch job can update data consumed by an online transaction the next morning. A shared copybook can shape records used across several business units.

Some dependencies live in code. Others sit in schedulers, database conventions, operational runbooks, or the knowledge of employees who have maintained a workload for decades.

That makes direct code translation an incomplete model. A language model can produce plausible Java from a COBOL routine, yet miss why that routine runs after another job. It can also preserve logic that the business no longer wants.

The opposite risk is equally serious. A generated replacement might simplify behavior that looks redundant but handles an obscure regulatory exception. That failure might appear only during a rare transaction or quarter-end process.

Google’s assessment-first design attempts to make those relationships inspectable. Its documentation says the tool produces call trees, dependency reports, business-rule summaries, and proposed migratable units.

The assessment system also supports an MCP server, which lets AI agents query assessment data through the Model Context Protocol. MCP is a standard interface for connecting models with external tools and structured context.

That architecture gives Gemini more than a folder of source files. It can work with discovered relationships, reviewed specifications, and business rules tied to a particular application domain.

However, richer context does not guarantee accurate interpretation. Generated specifications can omit edge cases, and static analysis cannot observe every dependency created through runtime configuration or external operations.

Human review therefore remains part of the mechanism. Subject-matter experts must decide whether a proposed business rule is valid, obsolete, incomplete, or misunderstood.

This creates a practical constraint for enterprises facing staff attrition. The workflow needs experienced operators most when their knowledge is hardest to replace. AI can organize their review, but it cannot retroactively supply missing institutional memory.

The Google approach also changes the purpose of legacy code. Rather than treating each statement as something to preserve, teams can treat the estate as evidence about intended business behavior.

That distinction supports cloud-native redesign. A transaction monitor does not need a literal counterpart if a managed service can satisfy the same reviewed requirement. A batch process might become an event-driven service when timing and consistency constraints permit it.

Yet redesign expands the validation burden. The farther the target architecture moves from the original implementation, the less useful line-by-line comparison becomes.

Teams must compare outcomes, side effects, timing, data integrity, and failure recovery. That is why Dual Run is central rather than optional in Google’s story.

The promise is not perfect translation. It is a traceable chain from legacy evidence to reviewed rules, generated implementation, and measured equivalence.

The Real Contest Is Iterative Modernization Versus the Big Bang

Google’s strongest argument is organizational: smaller migration units limit the consequences of uncertainty.

A big-bang migration concentrates many assumptions into one cutover. Teams must understand dependencies, transform code, move data, test interfaces, train operators, and prepare rollback procedures across a broad scope.

One mistaken dependency can delay the whole program. Worse, a defect can reach production only after the original environment has become difficult to restore.

Iterative modernization reduces that blast radius. Teams can choose a bounded domain, document its relationships, build a target implementation, and validate it while neighboring workloads remain unchanged.

This does not make modernization simple. It changes how failure behaves.

A problem discovered during one migration unit can improve the assessment rules for the next unit. Test mismatches can reveal undocumented behavior before the enterprise commits to a broader cutover.

Dual Run provides the operational bridge. Google’s earlier parallel testing model keeps the mainframe as the primary system while a cloud copy executes the same workload as a secondary system.

The cloud output can then be compared with the established result. Repeated differences expose defects in transformed logic, data conversion, or environmental assumptions.

This is particularly relevant for transaction-heavy systems. A unit test can verify a known calculation, but it cannot reproduce every interaction among live input patterns, scheduling conditions, and downstream integrations.

Parallel execution supplies broader evidence without immediately giving the new system production authority. Teams can set acceptance thresholds, investigate differences, and repeat testing before switching responsibility.

The tradeoff is prolonged coexistence. Running two environments requires synchronization, monitoring, duplicate processing controls, and a clear decision about which system owns each output.

Costs can also overlap during the transition. Google does not eliminate that operational burden. It argues that the burden buys a safer path away from an all-or-nothing event.

The incremental model introduces governance questions as well. Teams need rules for choosing migration units and deciding when an application has demonstrated sufficient equivalence.

They must track which business rules were accepted, who approved them, which test evidence supports them, and what changed after validation. Without that record, iterative work can create a fragmented hybrid estate.

Architecture discipline matters here. A sequence of isolated cloud projects can reproduce mainframe complexity through new services, queues, databases, and undocumented interfaces.

Google’s tools can map and generate artifacts, but an enterprise still needs a coherent target architecture. It also needs a retirement plan for every mainframe component replaced by the cloud.

The approach succeeds when iteration produces cumulative simplification. It fails when every migrated unit adds another permanent bridge back to the legacy estate.

This is why the contest is not speed versus caution. A rushed big bang can fail dramatically, while an endless incremental program can fail quietly.

The meaningful measure is completed business capability. Each migration unit should reach validated production operation and remove corresponding legacy responsibility.

Google Cloud Faces IBM and AWS on Different Terms

All three vendors now use AI, but they differ on where the modernized workload should live and how equivalence is established.

IBM’s position begins from the continued value of the mainframe. Its watsonx Code Assistant for Z supports discovery, explanation, refactoring, code generation, optimization, and transformation while retaining IBM Z as an important runtime.

IBM says its assistant can explain COBOL, PL/I, REXX, Assembler, and JCL. It can also refactor selected programs into modular services or transform COBOL into object-oriented Java.

The company’s AI modernization tools include automated unit testing for semantic equivalence. That term means the new code should produce the same intended behavior as the original, even when its structure changes.

This route can suit enterprises that want better development practices without committing every workload to a hyperscale cloud. It also lets teams modernize around a mainframe rather than treating the platform as a deadline.

AWS takes a position closer to Google’s cloud destination, but its current message emphasizes agentic execution and traceability. AWS Transform for mainframe covers assessment, business-rule extraction, requirements, code generation, testing, and deployment.

AWS says each generated output can trace through requirements to the original source. Its agentic workflow also integrates with coding agents such as Kiro and existing development environments through open protocols.

That traceability targets the same trust gap as Google’s Dual Run. It gives reviewers an audit path showing where a requirement or generated component originated.

Google’s differentiation lies in combining contextual assessment with data conversion and workload-level parallel validation. Gemini assists with understanding and generation, while Dual Run tests behavior against the operating system of record.

These are not cleanly separated product categories. IBM also offers discovery and testing. AWS also claims automated functional-equivalence validation. Each vendor is expanding across the full lifecycle.

The competitive pressure will therefore shift toward implementation evidence. Buyers need to know which languages, schedulers, databases, transaction systems, and data formats each workflow handles in their estate.

They also need to distinguish product capability from service delivery. Mainframe programs often involve systems integrators, internal experts, vendor specialists, and years of application history.

No model operates independently of that delivery structure. AI can reduce manual analysis, draft specifications, and generate code, but integration decisions remain specific to each environment.

Vendor lock-in presents another consideration. A generated architecture can favor one provider’s databases, compute platforms, monitoring systems, and AI services.

That alignment can simplify deployment. It can also raise switching costs when a company later changes its cloud strategy or retains workloads across several environments.

Enterprises should therefore evaluate artifacts, not only demonstrations. Exportable rules, readable specifications, portable tests, and traceable approvals matter beyond the initial transformation.

The market is converging on AI-assisted modernization. The unresolved competition concerns where humans verify the work, how vendors measure equivalence, and which platform owns the result.

What Google Cloud’s AI Workflow Still Cannot Guarantee

The workflow reduces specific migration risks, but it does not establish that generated business rules or target code are correct.

The first uncertainty appears during discovery. Static analysis can identify source relationships and declared calls, but dynamic behavior might depend on runtime values, operator choices, or external systems.

An AI-generated summary can also sound more certain than its evidence permits. Reviewers may approve a clear explanation because it is readable, even when it omits an infrequent branch.

That creates automation bias, which occurs when people place excessive trust in a system’s recommendation. A polished specification can increase this risk because it hides the ambiguity present in the underlying estate.

Google’s own workflow preserves a review step for extracted rules. Enterprises should treat that step as a control, not an administrative checkpoint.

Review needs named owners, linked evidence, and explicit dispositions. A rule should be marked accepted, rejected, revised, or unresolved before it guides generated code.

Security adds another layer. Google says the Mainframe Assessment Tool keeps collected assessment data within its deployed virtual machine. Its documentation also says source code is uploaded to the Gemini Enterprise Agent Platform.

The same documentation states that the model is not enriched with information extracted from that code. Organizations still need to verify regional controls, access policies, retention behavior, and contractual requirements for their workloads.

Testing also has limits. Dual Run can detect differences between observed outputs, but equivalence depends on coverage and comparison quality.

If both environments receive only common transactions, rare cases remain untested. If comparison logic ignores timing, ordering, or downstream side effects, two outputs can appear equal while the systems behave differently.

Parallel testing can also reproduce bad legacy behavior. Matching the mainframe is useful during migration, but it does not prove that every inherited rule is desirable or compliant with current policy.

Teams must separate two questions. Does the cloud implementation behave like the original, and should the original behavior survive?

The second question requires business, legal, security, and operational judgment. Code analysis alone cannot answer it.

Performance claims require production-like evidence too. A generated service might pass functional tests while creating unacceptable latency, infrastructure consumption, or database contention at peak volume.

Operational recovery deserves the same attention. Teams should test retries, partial failures, delayed messages, duplicate transactions, and rollback procedures before transferring authority.

Finally, the workflow cannot guarantee program completion. An enterprise can produce excellent assessments and prototypes without retiring a single mainframe workload.

Success needs exit criteria for each migration unit. Those criteria should cover functional evidence, operational readiness, data reconciliation, security approval, cost expectations, and actual legacy decommissioning.

Google’s strategy is safer because it makes uncertainty visible earlier. It is not safe merely because AI participates.

What to Watch as Google Cloud Moves From Method to Evidence

The next test is whether the staged method produces repeatable production cutovers, not more convincing generated code.

The first signal is customer evidence tied to completed migration units. Buyers should look for named production workloads that passed parallel testing and transferred system-of-record responsibility.

A useful case study would explain scope, supported artifacts, discovered dependencies, validation duration, mismatch handling, and the mainframe components ultimately retired. General statements about faster analysis reveal less.

Repeated cutovers would strengthen Google’s argument that the workflow scales beyond a carefully selected application. Assessments without production retirement would weaken it.

The second signal is deeper traceability across the toolchain. Google’s release history shows continuing work on business-rule extraction, MCP access, language coverage, and large-estate analysis.

The important advance would connect each approved rule to source evidence, generated components, tests, comparison results, and human approvals. That chain would make review easier during audits and later maintenance.

It would also help teams identify where an error entered the process. A mismatch could point back to faulty extraction, an altered requirement, generated code, converted data, or the validation harness.

Clear traceability would strengthen the iterative model because knowledge would accumulate across migration units. Fragmented artifacts would make each unit feel like a separate project.

The third signal is how IBM and AWS respond with comparable validation evidence. Feature lists already overlap, so vendors will need to show how their methods handle real dependencies and difficult cutovers.

IBM can argue that modernization does not require abandoning IBM Z. AWS can emphasize source-to-output traceability and automated testing. Google must prove that contextual assessment plus Dual Run provides a better risk boundary.

That competition should benefit enterprise buyers. It moves the discussion away from raw code-generation demonstrations and toward evidence, governance, portability, and completed outcomes.

For technology leaders, the immediate action is not to approve an estate-wide migration. It is to select one meaningful domain and test the full chain.

The domain should contain real dependencies and business consequences without becoming an irreversible first move. Its assessment should include code, data, schedules, interfaces, and operational knowledge.

Teams should record how many extracted rules require correction, how often parallel results diverge, and how long each mismatch takes to resolve. Those measures reveal more than generated-code volume.

They should also decide what ends after a successful cutover. A migration unit is incomplete if the original workload, license burden, operational process, and support responsibility all remain.

Google Cloud is offering enterprises a route between indefinite maintenance and a dangerous big bang. The route is credible because it treats modernization as discovery, reconstruction, and proof.

Its value will depend on whether customers can repeat that cycle across complex estates without creating a permanent hybrid maze. The next production cutovers will matter more than the next AI-generated demo.