Mainframe ↔ AWS architect
Bridge between z/OS, AS/400, or Unisys and the AWS ecosystem, 5R choice per subsystem, strangler fig coexistence design
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).
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Automatic estate extraction via AWS Mainframe Modernization Discovery, IBM ADDI, or dedicated tools. Classify each program by execution frequency, criticality, and dependencies. Archive or delete dormant programs (20-40% perimeter reduction). Full mapping: COBOL, PL/I, CICS, JCL, copybooks, DB2/VSAM, exchange files.
Per-subsystem 5R arbitration: Replatform via Micro Focus for critical 24/7 without rewrite, Refactor via Blu Age for stable programs migratable to modern Java, manual Rebuild for strategic, Replace by SaaS/managed for commoditizable. AWS target architecture: EKS/ECS, RDS/Aurora, Step Functions, EventBridge, Lambda. FinOps strategy (instance choice, reserved/savings, Cost Explorer tagging).
Characterization tests written upstream on mainframe: frozen batch exports, transactional snapshots, certified datasets. Pattern-by-pattern migration: COPY → Java classes, PERFORM → methods, PIC S9(n)V9(n) → BigDecimal, JCL → Step Functions, CICS → REST microservices. AWS infrastructure build via Terraform/CDK. CodePipeline CI/CD.
Parallel runs mainframe / AWS for 4 to 8 weeks with automatic output comparison. Per-subsystem parity audit, internal classified discrepancy registry CRITICAL / ADAPTATION / COSMETIC per internal grid. Per-subsystem coexistence with strangler fig pattern behind API facade. AWS DMS for continuous DB2 → RDS replication.
Per-subsystem transactional cutover, mainframe decommissioning planned within 3 months after parity validation. Coexistence bounded by a dated exit plan. Continuous FinOps monitoring (Cost Explorer, tags), post-prod optimization (autoscaling, savings plans). Ops handover to client team with documentation and runbooks.
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
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.
IBM z/OS, AS/400, Unisys, OpenVMS mainframes — COBOL, PL/I, CICS, JCL, batch applications
AWS — EKS / ECS, RDS PostgreSQL or Aurora, EventBridge, Step Functions, S3, Lambda, AWS Mainframe Modernization (Blu Age, Micro Focus)
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 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 structured as a sequence of functional waves, with the cadence set at scoping based on estate size and chosen 5R strategy. The typical cell combines a mainframe-AWS architect, an AWS tech lead, COBOL/Java or COBOL/Python developers, AWS cloud engineers, a parity-test QA engineer, a project manager. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured; very large estates are structured in several waves spread over time.
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, dual run of four to eight weeks with automatic comparison, then mainframe decommissioning after validation. Coexistence of the complete estate is bounded by a dated exit plan — milestones and exit criteria validated in program governance — to prevent it from dragging into permanent dual-run.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between z/OS, AS/400, or Unisys and the AWS ecosystem, 5R choice per subsystem, strangler fig coexistence design
AWS Mainframe Modernization (Blu Age + Micro Focus), EKS/ECS, RDS/Aurora, Step Functions, EventBridge, Lambda
Translation patterns PIC/COMP-3 → BigDecimal, CICS → REST, JCL → Step Functions, ideally with COBOL background
Infrastructure as Code (Terraform, CDK), CI/CD CodePipeline, CloudWatch + X-Ray observability, IAM security, VPC networking
Migration via AWS DMS, DB2 schema mapping, SQL/PL → PL/pgSQL translation, data parity audit
Characterization test bench, automated parallel runs, discrepancy registry classified CRITICAL/ADAPTATION/COSMETIC
Monthly per-subsystem estimate, Cost Explorer tags, savings plans / reserved instances, S3 / Glacier tiering, Lambda optimization
Functional waves leadership, program governance, dated mainframe decommissioning plan
It depends mainly on the number of programs, criticality, and chosen 5R pattern. ATLAS delivers in successive functional waves rather than on a monolithic plan: each wave is defined with you at scoping, delivered with validated parity, then the next one starts. Non-critical subsystems are migrated first, critical 24/7 subsystems last. A POC on the client's actual code measures real productivity and prices the full program reliably.
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.
Three concrete ways to start — from an AWS Mainframe Modernization POC to a full multi-year program. Our approach covers all 5 5R patterns with explicit per-subsystem arbitration, internal classified discrepancy registry, and mainframe-AWS coexistence capped at 24-36 months.