Mainframe Migration & Modernisation on Google Cloud

Cut mainframe migration scope by up to 70% with Google's Mainframe Assessment Tool (MAT), refactor COBOL, PL/I and RPG with Gemini and Claude, and verify every transaction with Google Cloud Dual Run.

IBM z/OS & IBM i (AS/400) Modernisation

Cut mainframe migration scope by up to 70% with Google's Mainframe Assessment Tool, then let AI do the heavy lifting

Most mainframe migrations fail because teams try to convert every file in a 40-year-old source library. We start with Google Cloud's Gemini-powered Mainframe Assessment Tool (MAT) and runtime SMF logs to strip out dead code, orphaned copybooks and redundant batch jobs, shrinking what needs to be migrated by up to 70%. Then our AI agents extract the real business rules, build clean cloud-native services, and prove 100% parity with Google Cloud Dual Run before you switch off a single MIPS.

Book a MAT mainframe assessment All App Modernisation services →

How Google’s Mainframe Assessment Tool (MAT) cuts scope by up to 70%

The biggest mistake in mainframe modernisation is paying engineers (or a mechanical transpiler) to migrate code that never runs. An enterprise IBM z/OS or IBM i estate that started in the 1980s contains millions of lines of cloned COBOL and PL/I programs, commented-out regulatory branches, unreachable paragraphs, orphaned copybooks, and overnight JCL jobs that write flat files no downstream system reads anymore.

Before writing a line of target code, we run Google Cloud’s Mainframe Assessment Tool (MAT) paired with your runtime SMF records and job scheduler logs. MAT uses Gemini models to parse your entire source repository and cross-reference static dependencies against what actually executes in production.

Up to 70%

Scope reduction via MAT & AI discovery

100%

Transaction parity proven in Dual Run

Lines of unmaintainable "JOBOL" code

That upfront AI discovery cuts the migration scope by up to 70% in four ways:

Dead code and orphan elimination: Programs, CICS transactions, BMS screens and copybooks that are unreferenced in active JCL proc libraries or SMF execution logs are archived and excluded from the build scope on day one.
Clone and duplicate consolidation: Mainframe teams frequently copied a 5,000-line batch program ten times for ten regional products, changing only twenty lines of rate logic in each copy. MAT detects near-identical AST structures so we replace ten cloned COBOL programs with a single parameterised service.
Unused batch and report retirement: Overnight JCL steps that burn MIPS generating QSAM spool files or DB2 extracts for decommissioned downstream systems are switched off immediately.
Automated specification generation: For the 30% to 50% of code that actually runs your business, MAT generates natural-language functional specifications, call graphs, data lineage maps and AGENTS.md context files that feed directly into our AI refactoring agents.

Why previous mainframe projects stalled

If your organisation has tried to leave the mainframe before and shelved the project two years later, you ran into one of two dead ends:

The manual clean-sheet rewrite: Business analysts spend 18 months interviewing staff to write requirements for a system that has been patched since 1988. They miss half the edge cases buried inside nested COBOL PERFORM blocks and copybooks. When the new system enters testing, it fails reconciliation against the general ledger and the programme runs out of budget.
The mechanical “JOBOL” transpiler: A system integrator runs an automated syntax converter over five million lines of COBOL (including all the dead code) and hands you five million lines of Java where every variable is a byte[] array offset and every paragraph is a method mutating global state. You are off the mainframe, your cloud compute bill triples because the code fights the JVM, and your Java engineers resign rather than maintain it.

How AI does the heavy lifting after MAT shrinks the scope

Our founder spent six and a half years at Google Cloud, including serving as Head of Application Modernisation for APAC Professional Services. Once Google’s Mainframe Assessment Tool has stripped away the dead weight, we use AI across every remaining stage of the engineering lifecycle inside your own Google Cloud tenant:

AI rule extraction and domain decomposition: Gemini and Claude agents ingest the MAT dependency graph across COBOL, PL/I, RPGLE, HLASM Assembler, Natural, Easytrieve, CICS and DB2 stored procedures. They extract every business rule, interest calculation, validation branch and data contract into human-readable specifications that your domain experts can review and sign off.
AI-generated cloud-native code and unit tests: Using the extracted specifications and MAT context files, our engineers work with coding agents to generate clean, idiomatic Java (Spring Boot), Go or Python microservices, along with boundary test suites covering every branch condition in the original legacy module.
Automated data schema and EBCDIC conversion: AI conversion workspaces translate hierarchical IMS DB segments, Adabas files, and multi-record VSAM REDEFINES copybooks into normalised AlloyDB for PostgreSQL or Cloud Spanner schemas, generating the EBCDIC-to-UTF-8 and COMP-3 packed-decimal conversion pipelines automatically.
Google Cloud Dual Run parallel verification: We never rely on human sign-off alone to prove a refactored service matches a 30-year-old program. Using Google Cloud Dual Run, we replay real production online (CICS/IMS) and batch (JCL) traffic through both your mainframe and your new Google Cloud environment simultaneously. The automated reconciliation engine diffs every database row, file record and API response down to the cent. You only cut over when discrepancies hit zero.

Three modernisation pathways (and how to self-fund the move)

Not every mainframe workload deserves the same engineering treatment. Based on the MAT output and your IBM contract renewal dates, we assign every application domain to one of three pathways:

Shrink & offload (Self-funding MIPS reduction)

IBM Monthly License Charge (MLC) and Tailored Fit Pricing bills are driven by peak Rolling 4-Hour Average (R4HA) MIPS. We retire dead batch jobs identified by MAT, archive cold historical data to Cloud Storage and BigQuery, and stream live DB2 and VSAM data into AlloyDB or Spanner via CDC. Serving read-heavy web, mobile and reporting queries from Google Cloud drops your peak MIPS bill early, freeing up OpEx budget to self-fund subsequent refactoring waves.

Decouple & strangle via APIs

We place Apigee and Cloud Pub/Sub in front of CICS Transaction Gateway (CTG), IMS Connect and IBM MQ. External digital channels talk to clean REST, GraphQL or gRPC contracts on Google Cloud rather than calling brittle 3270 or 5250 screen-scrapers. That decoupling lets us extract and replace individual business domains behind the API gateway with zero disruption to upstream apps.

AI refactor & decommission

For core business logic that remains in scope after the MAT reduction, our AI-assisted engineering pods refactor the procedural COBOL, PL/I, RPGLE or Natural modules into stateless microservices on Cloud Run or GKE Autopilot, convert JCL chains into Cloud Workflows and Dataflow pipelines, prove equivalence in Dual Run, and switch off the LPAR.

Three technical traps that catch mainframe migrations out

TRAP 01 / ENCODING & MATHS

EBCDIC sort order and COMP-3 packed decimals

In IBM EBCDIC encoding, lowercase letters sort before uppercase letters, and letters sort before numbers (A comes before 1). In UTF-8 and ASCII on Linux, numbers sort before uppercase letters (1 comes before A). Any batch merge job or SQL ORDER BY that relies on EBCDIC collation breaks on cloud databases unless explicitly handled. Fixed-point COMP-3 packed decimals and COBOL truncation rules must also map to exact decimal arithmetic in Java or Go so financial rounding never drifts by a cent.

TRAP 02 / BATCH WINDOWS

Chatty JCL loops that miss the 6:00am cut-off

On z/OS, a COBOL batch job and DB2 or VSAM live in the same memory space on the same sysplex. A loop that executes ten million sequential record reads finishes in minutes because each call takes microseconds. If you lift that exact loop into a cloud microservice making ten million network round-trips to a database, a two-hour overnight batch takes 19 hours. We refactor record-at-a-time JCL chains into set-based SQL, Dataflow pipelines or partitioned Cloud Run Jobs.

TRAP 03 / SHARED DATA

200 programs writing to the same VSAM file or DB2 table

Mainframe estates rarely have clean domain boundaries. Online CICS transactions, overnight JCL jobs, and partner feeds read and write the exact same DB2 tables or VSAM KSDS datasets with REDEFINES copybooks where a column changes meaning depending on a status flag. MAT maps data affinity across the entire portfolio first so we carve out decoupled domains with bidirectional CDC sync rather than cutting a cable that 40 other jobs depend on.

Mainframe to Google Cloud architecture mapping

Mainframe component (IBM z/OS or IBM i)	Google Cloud target	How MAT + AI migrate it
COBOL, PL/I, HLASM Assembler, Natural, Easytrieve & RPGLE	Cloud Run or GKE Autopilot (Java Spring Boot, Go or Python)	MAT strips out dead code (up to 70% scope reduction) and extracts business rules; Gemini and Claude generate idiomatic, stateless services with zero proprietary runtime fees.
CICS, IMS TM & 3270 / 5250 green-screen terminals	Apigee, Cloud Run & Flutter / React Web UIs	Exposes legacy transaction logic as versioned REST/gRPC APIs behind Apigee and replaces green-screen workflows with modern web and mobile interfaces.
JCL, PROC, SORT/DFSORT, REXX, Control-M & CA-7 batch	Cloud Workflows, Dataflow & Cloud Run Jobs	Consolidates duplicate batch steps and replaces sequential flat-file passes with parallel stream/batch pipelines and step-level retry.
DB2 for z/OS & DB2 for i (AS/400)	AlloyDB for PostgreSQL or Cloud Spanner	Converts schemas, stored procedures and EBCDIC collations; AlloyDB handles high-throughput relational OLTP while Spanner provides multi-region 99.999% availability for core ledgers.
VSAM (KSDS, ESDS, RRDS), QSAM & IMS DB / Adabas	AlloyDB, Firestore or Cloud Storage + BigQuery	Unpacks `COMP-3` fields and normalises multi-record `REDEFINES` copybooks and hierarchical segments into typed relational tables or analytical lakehouses.
RACF, ACF2, Top Secret & SMF audit records	Cloud IAM, Secret Manager & Google SecOps	Maps mainframe dataset and transaction permissions into least-privilege IAM policies and immutable audit logs aligned with APRA CPS 234 and CPS 230.

How our 4-stage mainframe migration runs

Google Mainframe Assessment Tool (MAT) & SMF scan (Weeks 1 to 3)

We ingest your source libraries (Endevor, Changeman, PDS libraries or IBM i source physical files) together with SMF workload records and scheduler logs into Google's Mainframe Assessment Tool inside your GCP project. MAT builds the complete call and data dependency graph, flags dead and duplicate code to reduce migration scope by up to 70%, and ranks every domain wave by Rolling 4-Hour Average (R4HA) MIPS savings and coupling complexity.

Dead-job retirement, data offload & Apigee facade

We switch off the unused JCL jobs and reports uncovered by MAT, place Apigee in front of your mainframe interfaces, and establish continuous Change Data Capture from DB2 and VSAM into AlloyDB, Spanner or BigQuery. Offloading read-heavy digital queries and analytics onto Google Cloud drops your peak MIPS consumption early so the savings help fund the build.

AI-driven code refactoring & Dual Run parallel proof

Using the specifications and context generated by MAT, our engineers and AI agents refactor the remaining active COBOL, PL/I, RPG or Assembler modules into clean Java, Go or Python services on Cloud Run or GKE. We then run each wave in shadow mode via Google Cloud Dual Run. Every day's production batch and online traffic runs through both platforms, and our reconciliation engine verifies every output until parity hits 100%.

Domain-by-domain cutover & LPAR decommissioning

Once Dual Run proves zero discrepancies across multiple business cycles (including month-end and quarter-end batch runs), Apigee shifts live traffic from CICS or IMS to Google Cloud. Reverse replication keeps the mainframe database updated during the burn-in window so rollback is a routing toggle, not a weekend data restore.

AIX to Google Cloud Migration: Move IBM Power AIX LPARs, C/C++ binaries, KornShell scripts and DB2/Oracle databases to Linux on Google Cloud or IP4G.
Enterprise Application Modernisation: Decompose Java and .NET monoliths using the Strangler Fig pattern, Cloud Run and GKE Autopilot.
Apigee & API Management: Build the API routing layer that lets you strangle legacy mainframe and Unix backends without breaking upstream consumers.
Agentic Engineering: Deploy production Gemini and Claude agent workflows inside your Google Cloud environment.
App Modernisation and Development: View our full application modernisation and engineering practice.

Want to see how much of your mainframe estate is dead code before you budget a migration?

Book a 20-minute architecture call. We will walk through how Google's Mainframe Assessment Tool (MAT) and Dual Run work, review your z/OS or IBM i footprint, and show you how to run a bounded MAT discovery scan inside your own Google Cloud project.

Book a 20-minute mainframe assessment call

FAQ

Questions we get asked

How does Google's Mainframe Assessment Tool (MAT) cut migration scope by up to 70%?

Thirty-year-old mainframe repositories are full of dead code: orphaned copybooks, cloned batch programs, retired regulatory reports, and subroutines that have not executed in years. We run Google Cloud's Gemini-powered Mainframe Assessment Tool (MAT) alongside your SMF execution logs and job scheduler history (Control-M, CA-7, TWS) to map every live call graph. Identifying and retiring dead code, duplicate batch steps and unused datasets reduces the volume of code that actually needs to be migrated by up to 70% before engineering starts.

What is the difference between automated COBOL-to-Java transpilers and your AI refactoring?

Mechanical line-by-line transpilers produce 'JOBOL': Java files that still use global working-storage byte arrays, GOTO-style control flow and single-letter variable names that no Java or Go engineer wants to maintain. Instead of translating syntax line for line, we use Google's Mainframe Assessment Tool (MAT), Gemini and Claude inside your Google Cloud project to extract the business rules, data contracts and edge cases, then generate idiomatic Java (Spring Boot), Go or Python services.

What mainframe languages, transaction monitors and databases do you support?

Using Google's Mainframe Assessment Tool and our AI engineering workflows, we assess and migrate COBOL (programs and copybooks), PL/I, RPG and RPGLE, HLASM (Assembler), JCL, Natural, Easytrieve and REXX across both IBM z/OS and IBM i (AS/400). On the data and transaction side, we migrate CICS, IMS TM, IMS DB, DB2 for z/OS, DB2 for i, VSAM (KSDS, ESDS, RRDS), QSAM flat files and Adabas.

How do you prove the new cloud service matches a 30-year-old mainframe program?

We do not rely on manually written unit tests alone. Using Google Cloud Dual Run and traffic shadowing, we replay real production online (CICS/IMS) and batch (JCL) payloads against both the mainframe and the new Google Cloud service in parallel. An automated reconciliation engine compares every database write, file record and API response down to the cent before any production cutover happens.

How can we self-fund the migration by lowering our monthly IBM MIPS bill early?

IBM Monthly License Charge (MLC) and Tailored Fit Pricing bills are driven by peak Rolling 4-Hour Average (R4HA) MIPS consumption. Up to 40% of those peaks come from read-only mobile/web API lookups, batch extracts and reporting queries hitting DB2 or VSAM. By retiring dead batch jobs found during the MAT assessment and streaming mainframe data into AlloyDB, Cloud Spanner or BigQuery to serve read traffic from Google Cloud, we drop peak MIPS early so the run-rate savings help fund later refactoring waves.

Do you migrate IBM i (AS/400) RPG and DB2/400 workloads as well as IBM z/OS?

Yes. In Australia, New Zealand and Singapore, IBM i (AS/400) running RPG III, RPGLE, CL and DB2 for i is just as common in retail, logistics, insurance and manufacturing as z/OS is in banking. We migrate both z/OS and IBM i estates onto Google Cloud.

Talk to an architect who has done this before.

Bring your current setup and the outcome you need. You will get a view on the approach, the risks and roughly what it costs.

Book a 20-min architecture call

Straight to a senior GCP architect. No SDR, no slide deck.

Not ready to talk? See how we migrated Hapana off AWS →

Or call +61 2 8359 9507 · Hello@aviato.consulting