Loading...
Loading...
Migration of mainframe applications (IBM z/OS, AS/400, Unisys) to AWS: managed services, containers, events, and relational databases. Existing-system capture, characterization tests, pattern-by-pattern migration, parity audit, discrepancy registry. AWS-targeted approach with the 5R patterns (Rehost, Replatform, Refactor, Rebuild, Replace).
IBM mainframes (z/OS, former System/360, AS/400, later IBM i, and Unisys systems) remain the backbone of entire IT swaths in banking, insurance, public sector, and tax administration. They still execute critical 24/7 transactions today with reliability levels hard to match on more modern architectures. But the gap is widening on several fronts: scarce COBOL and CICS expertise in the labor market, IBM license costs hard to justify against cloud targets, delivery velocity slowed by the historical mainframe toolchain, and limited integration with modern API ecosystems. For organizations engaged in a global cloud strategy, the question is no longer whether to modernize but how and at what pace.
AWS emerges as a mainframe modernization target for three reasons. First, AWS Mainframe Modernization is a dedicated offering integrating Blu Age (automatic COBOL to Java refactoring) and Micro Focus (native COBOL replatforming on AWS), covering the full spectrum of 5R patterns. Second, the AWS ecosystem offers the necessary managed building blocks: RDS / Aurora for databases, EKS / ECS for containers, Step Functions to orchestrate batch, EventBridge for events, Lambda for occasional functions. Third, AWS meets sovereignty and compliance requirements in several critical regions (sovereign regions, FedRAMP, ISO 27001, HIPAA compliance per sector). Our Legacy to Cloud expertise handles these migrations, framed by the ATLAS methodology.
A mainframe migration is not handled with a single pattern. The ATLAS methodology imposes arbitration per subsystem between the 5R patterns. Rehost (lift and shift via emulation) is rarely satisfactory because it moves debt without resolving it. Replatform via AWS Mainframe Modernization (Micro Focus) keeps the COBOL code but runs it on AWS — useful for stable critical programs where rewriting would be risky. Refactor via Blu Age automatically converts COBOL to modern Java — suited to mature programs with clear business logic. Rebuild (manual rewrite) is reserved for strategic components where business must be rethought. Replace applies to commoditizable functions (reference data, reporting, standard batch) that can be replaced by SaaS or managed AWS services.
Stable COBOL program with clear business logic, no heavy dependency on non-portable mainframe constructs. Automatic conversion to modern Java, maintainable code, Java teams available or trainable. Preferred pattern for the majority of transactional programs.
Critical 24/7 COBOL program where rewriting would be risky. The COBOL code is kept as-is and executed on AWS containers via Micro Focus Enterprise Server. Faster migration, technical debt unresolved but mainframe freed.
Strategic components where business must be rethought, or cases where automatic tools produce poorly maintainable code. Longer and more expensive but superior final quality. Our [ATLAS methodology](/methodologie-atlas) specifically covers this arbitration.
Commoditizable components: customer reference data (SaaS CRM), reporting (Power BI, Tableau, QuickSight), standard batch (Step Functions, EventBridge). Relevant to free the mainframe from non-differentiating functions.
A mainframe to AWS migration program is generally structured over **eighteen to sixty months** depending on estate size and chosen 5R strategy. For an estate of **fifteen to thirty** transactional programs with their JCL and DB2 databases, plan **eighteen to thirty months** with a cell of seven to ten people: a mainframe-AWS architect, an AWS tech lead, two to four COBOL/Java or COBOL/Python developers, two AWS cloud engineers, a parity-test QA engineer, a project manager. For very large estates (fifty programs and more, several critical subsystems), a multi-year program structured in functional waves is necessary with a team that may reach fifteen people during peaks.
Underestimating the initial discovery. A mature mainframe estate often contains inactive programs, orphan copybooks, and batch chains no one can explain. Migrating identically reproduces debt.
Systematic discovery with automatic estate extraction (AWS Mainframe Modernization Discovery, IBM ADDI, or dedicated tools), classification of each program by execution frequency, criticality, and dependencies. Dormant programs are archived or deleted, reducing the migration scope by 20 to 40%. See the ATLAS methodology.
Reproducing specific mainframe constructs without adapting them. COBOL decimal arithmetic (PIC S9(n)V9(n)), VSAM files, hierarchical COPY, REDEFINES have no direct equivalents in Java or Python.
Documented translation patterns: PIC S9(n)V9(n) → BigDecimal, VSAM → RDS tables with adapted indexing, COPY → classes or modules, REDEFINES → discriminator pattern. Each translation is validated by characterization tests before industrialization. The discrepancy registry classifies each adaptation as CRITICAL, ADAPTATION, or COSMETIC.
Neglecting batch windows and transactional consistency management. The mainframe guarantees strong invariants (ACID transactions, strict batch ordering) that AWS reproduces differently.
Explicit consistency design: Step Functions for batch orchestration with error and retry management, distributed transactions via Saga pattern when necessary, non-regression test sets on critical invariants (accounting balance, event sequence, idempotence). No production deployment without business validation of invariants.
Ignoring AWS cost at scale. The POC runs for a few hundred euros per month; at full load, a poorly architected transactional estate can reach tens of thousands of euros monthly.
FinOps strategy from design: instance choice, autoscaling, reserved instances or savings plans, Lambda optimization, S3 tiering, Glacier archiving for cold data. Monthly estimate revised at each milestone with budget validation. AWS Cost Explorer dashboards + tags per subsystem for traceability.
Letting mainframe and AWS coexist without an exit plan. Undated coexistence transforms the migration into permanent dual-run, which consumes more than the initial migration.
Dated cutover plan per subsystem. Each subsystem follows a short cycle: migration in three to six months, dual run of four to eight weeks with automatic comparison, mainframe decommissioning within three months after validation. Coexistence of the complete estate must not exceed twenty-four to thirty-six months, milestones and exit criteria validated in program governance.
It depends mainly on the number of programs, criticality, and chosen 5R pattern. For an estate of fifteen to thirty transactional programs with JCL and DB2 databases, plan eighteen to thirty months with a cell of seven to ten people in nearshore co-delivery. For very large estates (fifty programs and more, several critical 24/7 subsystems), a multi-year program structured in waves is necessary, with a team reaching up to fifteen people during peak phases. Most programs are migrated in two to three years for a medium-sized estate.
Both tools meet distinct needs. Blu Age performs automatic COBOL refactoring to modern Java, eliminating technical debt but requiring a Java team capable of maintaining the generated code. Relevant for stable programs with clear business logic, where long-term Java maintenance is the goal. Micro Focus replatforming keeps the COBOL code and executes it on AWS containers via Enterprise Server. Faster migration, the mainframe is freed, but COBOL technical debt persists. Relevant for critical 24/7 programs where rewriting would be risky. Many programs mix both depending on subsystems.
DB2 z/OS naturally translates to RDS PostgreSQL or Aurora PostgreSQL, with schema mapping and data migration via AWS DMS. SQL syntax is largely compatible but DB2 SQL/PL stored procedures require rewriting in PL/pgSQL or in Java application-side. VSAM files are more complex: they have no direct cloud equivalent. Depending on use, they are migrated to RDS tables with adapted indexing, to DynamoDB for very fast key-value access, or to object storage (S3) for rarely accessed historical files. The choice is made case by case.
CICS transactions are rebuilt as REST microservices deployed on EKS or ECS, or as Lambda functions for occasional low-volume transactions. CICS transactional invariants (local ACID, isolation, idempotence) are reproduced explicitly with distributed transactions (Saga pattern) when several services are involved. The discovery phase maps each CICS transaction, classifies its criticality and volume, and chooses the adapted target pattern. Characterization tests validate parity before each production deployment.
Three patterns depending on the case. For databases read-only from AWS during the transition, AWS DMS continuously replicates DB2 to RDS with sub-second latency. For databases written on both sides (rare), an event bus (Kafka or EventBridge) synchronizes modifications with business conflict management. For functions migrated progressively, the strangler fig pattern coexists mainframe and AWS behind an API facade that routes per the already-migrated perimeter. Coexistence is planned not to exceed two to three years.
Five typical gains observed on mainframe-to-cloud programs we accompany (whether the target is AWS, Azure, or other). First, freeing of mainframe license and hardware maintenance costs, measured in millions of euros annually on large estates. Second, load elasticity: capacity adapts to volume without oversizing. Third, native observability (CloudWatch, X-Ray) that reduces incident analysis time. Fourth, delivery velocity unlocked by the AWS CI/CD chain and managed services. Finally, extension capability: data lake, machine learning, modern API integration become accessible without mainframe constraint.
We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.
Start this path →