Mainframe to Cloud Migration with AI-Powered Code Transformation

mercedes-benz · Automotive · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Legacy automotive ordering-system modernization

Mercedes-Benz needed to move its mission-critical Global Ordering system from mainframe infrastructure to cloud while preserving production continuity across every vehicle-ordering and production workflow.

Constraints:

• Global Ordering was the heartbeat of Mercedes-Benz sales and production, with every sold or produced car passing through the system landscape.
• The application had more than 20,000 interfaces and roughly 5 million lines of Java and COBOL plus a comparable amount in other languages.
• The system represented about 50% of Mercedes-Benz mainframe workload and supported 5.1 billion messages per year, 450 batches, and 8,000 users in 150 countries.
• A direct big-bang migration would have forced many consumers to change integrations and risked disruption to a global production system.

Architecture

Mercedes-Benz used a staged migration architecture: replatform stateless services onto Rocket Enterprise Server on AWS, keep mainframe and cloud backends running in parallel, route consumers through the Global Ordering Facade, synchronize data with Precisely, and use GenRevive's human-orchestrated multi-agent code-transformation system for selected high-value refactoring such as the 1.3-million-line pricing service.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Consumers["Global Ordering consumers"] --> Facade["Global Ordering Facade"]
  Facade --> Mainframe["Mainframe backend"]
  Facade --> Cloud["Cloud Java backend"]
  Mainframe --> Sync["Precisely data sync"]
  Sync --> Cloud
  Human["Human orchestrator"] --> Agents["GenRevive agent team"]
  Agents --> Tuning["Performance tuning team"]
  Tuning --> Cloud
  Facade --> QA["Quality comparison workflow"]
  Cloud --> QA

Components

Data flow

Consumer requests enter the Global Ordering Facade, which can route traffic to either the legacy mainframe backend or the new cloud backend. During QA, UAT, and rollout, the facade sends comparable calls to both worlds while Precisely keeps database records synchronized, allowing response comparison before cutover. For the pricing service, GenRevive transforms COBOL into Java through agent roles for engineering, review, testing, and DevOps, after humans provide cookbooks and candidates; tuned Java then runs on AWS against synchronized data and is switched into production through the facade.

Why this architecture

The team avoided full refactoring up front because the system was too large and central to migrate all at once. A facade allowed consumers to change only a URL, while staged parallel operation let Mercedes-Benz prove the cloud service matched legacy behavior before cutover. GenAI was reserved for components where refactoring created extra value, not used indiscriminately across the entire mainframe estate.

Models used: GenRevive · generative AI code-transformation agents · AI coding assistants

Scale

• Global Ordering had more than 20,000 interfaces across Mercedes-Benz.
  “we talk about an application that has more than 20,000 interfaces in all parts of our company.”transcript, stated
• The system included about 5 million lines of Java and COBOL plus a comparable amount in other languages.
  “in terms of lines of code, we talk about 5 million lines of code in Java and COBOL and more or less the same size in the other languages.”transcript, stated
• Global Ordering accounted for about 50% of Mercedes-Benz mainframe workload.
  “roundabout 50% of the mainframe workload is with Global Ordering.”transcript, stated
• The application supported more than 5.1 billion messages per year.
  “we support more than 5.1 billion messages per year, and we have 450 batches running on the mainframe application.”transcript, stated
• The system served more than 8,000 users in 150 countries.
  “By this, we support more than 8,000 users in 150 countries.”transcript, stated
• The pricing-service transformation covered 1.3 million lines of COBOL.
  “there is one service called Pricing Service consisting of 1.3 million lines of code, 1.3 million lines of COBOL code.”transcript, stated
• The parallel migration kept 500 megabytes of database records synchronized in real time.
  “It's also 500 megabytes of database records that are kept in sync in real-time.”transcript, stated

Alternatives considered (roads not taken)

Refactor the whole Global Ordering application immediately

Rejected because: Mercedes-Benz chose staged replatforming first because the system was critical, huge, and needed parallel verification.

Increase mainframe infrastructure to handle pricing-service call growth

Rejected because: The team chose to try GenAI transformation instead of simply making the mainframe larger.

Expose migration changes directly to all consuming systems

Rejected because: The facade let consumers call a new URL without absorbing backend migration details.

Trust transformed code without target-environment performance tuning

Rejected because: Database-access patterns that were fast on the mainframe needed manual adjustment for AWS.

Patterns

multi-agent-orchestration (agent_architecture)

GenRevive split code transformation across role-specialized agents for software engineering, review, testing, and DevOps under human orchestration.

human-in-the-loop-gate (control)

Humans chose candidates, supplied cookbooks, orchestrated agents, and performed manual performance tuning before production rollout.

eval-driven-development (quality)

The team used facade-routed parallel execution to compare mainframe and cloud responses against synchronized data during QA and UAT before cutover.

incremental-rollout (deployment)

The facade allowed controlled cutover, rollback, and staged movement from mainframe to cloud rather than a single high-risk switch.

context-engineering (prompting)

Human-created cookbooks supplied transformation examples and quality expectations so the AI could apply domain-specific COBOL-to-Java patterns.

Tradeoffs

Use staged replatforming plus selective refactoring

Chose Replatform the broad Global Ordering system first and refactor selected components with GenAI over Immediate full-application refactoring.

Rationale: The system's scale and business criticality made staged parallel operation safer, while selected refactoring still captured GenAI benefits where the payoff was clear.

Route through a facade

Chose Use a gateway that can direct traffic to mainframe or cloud over Directly switching consumers to a new backend.

Rationale: The facade enabled testing, rollback, controlled cutover, and minimal consumer change.

Try GenAI for pricing-service modernization

Chose Transform the 1.3-million-line COBOL pricing service to Java over Scale up the mainframe to handle increasing calls.

Rationale: GenAI offered a path to refactoring speed and cloud performance that mainframe expansion would not provide.

Gotchas (what bit them)

Code transformation was not enough without target-platform performance engineering.

Root cause: Mainframe database-access patterns assumed in-memory speed, while AWS had different database latency characteristics.

Resolution: The team manually reviewed and tuned database accesses in the generated Java service.

Mission-critical migration needed consumer isolation as much as code conversion.

Root cause: More than 20,000 interfaces depended on Global Ordering, so forcing broad integration changes would multiply coordination risk.

Resolution: The Global Ordering Facade let consumers change only the called URL while backend migration remained hidden.

AI-generated code quality still needed maintainability scrutiny.

Root cause: A 1.3-million-line transformation could be functionally successful but still unacceptable if the result could not be maintained.

Resolution: The team inspected the generated code and found it indistinguishable from human-written code.

Evaluation

Mercedes-Benz evaluated the migration by running mainframe and cloud systems in parallel through the facade, comparing expected identical results against synchronized data, checking latency/throughput/SLA NFRs, inspecting generated code maintainability, and monitoring production go-live incidents and performance.

Metrics: 1.3 million lines of COBOL transformed into Java · first commit in March after a February decision to try GenAI · first deployable version in May · 500 megabytes of database records kept synchronized in real time · zero incidents at go-live · cloud Java pricing service faster than the mainframe version

Outcomes

• The pricing service went live successfully on AWS with no incidents.
• The transformed Java service ran faster than the previous mainframe COBOL service.
• The team transformed 1.3 million lines of COBOL into a Java application in a few months.
• Generated code was considered maintainable and not distinguishable from human-written code.
• The project established a repeatable pattern for evaluating additional components for GenAI-assisted refactoring.

The migration touched a Global Ordering estate with more than 20,000 interfaces, 5.1 billion annual messages, 450 batches, more than 8,000 users across 150 countries, and a pricing-service transformation of 1.3 million lines of COBOL plus 500 MB of synchronized records.