The Challenge
Moving a mainframe to AWS is the ultimate “Lift and Shift” vs. “Refactor” debate. AWS offers specific tools (AWS Mainframe Modernization service) that support both patterns, but the architectural implications are vastly different.
Technical Deep Dive
1. The “Replatform” Pattern (Emulation)
This involves running your existing COBOL/PL1 code on x86 instances (EC2) using a runtime emulator (like Micro Focus or Blu Age).
- Pros: Fastest path to cloud; preserves business logic exactly.
- Cons: You still have COBOL code; you don’t get full cloud-native benefits (serverless, microservices).
- AWS Service: AWS Mainframe Modernization (Replatform with Micro Focus).
2. The “Refactor” Pattern (Automated Conversion)
Converting legacy code to Java/Spring Boot to run on containers (EKS) or Lambda.
- Pros: Eliminates technical debt; opens talent pool; enables true agility.
- Cons: Higher initial risk; requires rigorous testing.
- AWS Service: AWS Mainframe Modernization (Refactor with Blu Age).
3. Data Strategy: VSAM to DynamoDB
Mapping flat-file VSAM structures to a NoSQL store like DynamoDB can unlock massive performance gains for read-heavy workloads.
Pattern: Use Change Data Capture (CDC) tools (like AWS DMS or Qlik Replicate) to sync mainframe data to AWS in real-time during the transition period. This allows you to build new “Read Models” on AWS while the “Write Model” stays on the mainframe until cutover.
How to Choose a Mainframe to AWS Migration Partner
If you have massive data volumes (50TB+): TCS. Their MasterCraft suite is proven for handling petabyte-scale data migrations for Global 2000 firms.
If you want a “Lift & Shift” (Replatform) first: Heirloom Computing. Their PaaS solution allows you to run existing COBOL code on AWS Elastic Beanstalk with minimal changes.
If you need risk-averse, steady hands: DXC Technology or Infosys. They have deep heritage in mainframe operations and won’t break your core banking system.
If you want to refactor to microservices: SoftServe. They specialize in cloud-native development and can help break the monolith into AWS Lambda/Fargate services.
If you need business process modernization: Cognizant. They focus on optimizing the business workflows, not just the code.
Red flags:
- Vendors who ignore “Data Egress Costs” in their TCO model
- No experience with “Hybrid State” latency management (Mainframe ↔ AWS calls)
- Suggesting a “Big Bang” cutover for a system with >1M daily transactions
- Lack of specific expertise with AWS Mainframe Modernization service
When to Hire Mainframe to AWS Migration Services
1. Hardware Refresh Cycle ($5M+ CapEx)
Your IBM z14/z15 lease is expiring. Upgrading to z16 will cost $10M+ in capital expenditure. The CFO wants to move to OpEx (Pay-as-you-go).
Trigger: Lease renewal notice arrives; CFO mandates “No new data centers.”
2. COBOL Talent Crisis
Your average mainframe developer is 58 years old. You have zero junior developers learning JCL or CICS. The risk of knowledge loss is existential.
Trigger: Key architect retires; inability to fix a critical bug because “nobody knows how that module works.”
3. Agility & Time-to-Market
Competitors deploy features daily. Your mainframe release cycle is quarterly. You cannot integrate with modern mobile apps or 3rd party APIs easily.
Trigger: Business loses a major deal because the product couldn’t support a modern API integration in time.
4. Cost of MIPS (Software Licensing)
IBM MLC (Monthly License Charges) and ISV software (BMC, CA/Broadcom) costs are increasing annually. You are paying millions just to keep the lights on.
Trigger: Software licensing costs exceed 50% of the total IT budget.
5. Data Analytics Needs
Your data is locked in VSAM files. You want to run Machine Learning or Real-time Analytics, but you can’t get the data out fast enough without impacting transaction performance.
Trigger: Data Science team complains they can’t access core customer data; need for real-time fraud detection.
Total Cost of Ownership: Mainframe vs AWS
| Line Item | % of Total Budget | Example ($5M Project) |
|---|---|---|
| Automated Code Conversion (Blu Age/Micro Focus) | 20-30% | $1M-$1.5M |
| Data Migration & Sync (CDC setup) | 25-35% | $1.25M-$1.75M |
| Testing (Automated Regression) | 30-40% | $1.5M-$2M |
| Infrastructure Setup (AWS Landing Zone) | 10-15% | $500K-$750K |
| Training & Ops Transformation | 5-10% | $250K-$500K |
Hidden Costs NOT Included:
- Parallel Run Costs: You must pay for Mainframe AND AWS for 6-12 months during the transition.
- Data Egress Fees: Syncing data back to on-premise for hybrid apps can cost thousands/month.
- Emulator Licensing: If Replatforming, you pay ongoing license fees for the COBOL runtime on AWS.
Break-Even Analysis:
- Median Investment: $5.4M
- Annual Savings: $2M-$3M (Eliminating MIPS + Hardware lease)
- ROI: 200-300% over 5 years
- Break-Even: 24-30 months
Mainframe to AWS Migration Roadmap
Phase 1: Assessment & Disposition (Months 1-3)
Activities:
- Catalog inventory (LPARs, CICS regions, DB2 tables)
- Map dependencies (application vs batch jobs)
- Select “6R” strategy per application (Retain, Rehost, Replatform, Refactor)
- Calculate TCO and ROI model
Deliverables:
- Application Portfolio Assessment
- Migration Strategy Document
- Business Case (TCO)
Phase 2: Pilot Migration (Months 4-6)
Activities:
- Select a low-risk, non-critical application (e.g., HR reporting)
- Set up AWS Landing Zone (Direct Connect, VPC, Security)
- Test automated conversion tools (Blu Age/Micro Focus)
- Validate performance benchmarks
Deliverables:
- Pilot application running on AWS
- Validated conversion toolchain
- Performance baseline report
Phase 3: Mass Migration & Data Sync (Months 7-18)
Activities:
- Set up CDC (Change Data Capture) for real-time data sync
- Migrate applications in waves (grouped by business domain)
- Implement “Hybrid” architecture (AWS apps calling Mainframe DBs)
- Massive automated testing (compare Mainframe vs AWS outputs)
Risks:
- Data consistency between VSAM and DynamoDB/RDS
- Latency in hybrid calls (keep chatty apps near data)
Deliverables:
- 80% of applications migrated
- Hybrid operations runbooks
Phase 4: Cutover & Decommission (Months 19-24)
Activities:
- Final data cutover (make AWS the “System of Record”)
- Reverse sync (AWS → Mainframe) turned off
- Shut down Mainframe LPARs
- Archive tape data to AWS Glacier
Deliverables:
- Mainframe powered off
- Cost savings realized
- Modern DevOps pipeline active
Post-Migration: Best Practices
Months 1-3: Hypercare
- Performance Tuning: Tune IOPS on EBS volumes and RDS instances. Mainframe I/O is incredibly fast; AWS needs right-sizing.
- Cost Monitoring: Watch out for unexpected Data Transfer costs.
Months 4-6: Modernization
- Strangler Fig: Start breaking the monolithic Java/COBOL code on AWS into microservices.
- API Enablement: Expose core business logic via API Gateway to internal developers.
Expanded FAQs
What is the AWS Mainframe Modernization service?
Answer: It’s a managed service that provides tools and infrastructure for two patterns: (1) Replatforming (using Micro Focus Enterprise Server) to run COBOL on EC2 with minimal changes. (2) Refactoring (using AWS Blu Age) to automatically convert COBOL to Java. It simplifies licensing and infrastructure setup.
Can we just “Lift and Shift” to EC2?
Answer: Not directly. You can’t run z/OS on an x86 EC2 instance. You must use an emulator (like Micro Focus or Heirloom) that provides a mainframe-compatible runtime environment on Linux/Windows. This is “Replatforming,” not simple “Rehosting.”
How do we handle VSAM files?
Answer: VSAM (indexed files) don’t exist in the cloud. Option 1 (Replatform): Use an emulator’s file system that mimics VSAM on EBS. Option 2 (Refactor): Convert VSAM data to a relational database (RDS PostgreSQL) or NoSQL (DynamoDB). The latter requires changing application code to use SQL/API calls instead of file I/O.
What about JCL (Job Control Language)?
Answer: JCL scripts orchestrate batch jobs. In AWS, these are typically converted to: (1) Shell scripts running on the emulator, or (2) Modern orchestration workflows using AWS Step Functions or Airflow. Step Functions is the cloud-native preference for visibility and error handling.
Is it better to Refactor or Replatform?
Answer: Replatform if you need speed (exit data center in <12 months) or have low risk tolerance. Refactor if you want long-term agility, talent attraction, and cost reduction (eliminating emulator license fees). Many companies Replatform first to get off the hardware, then Refactor slowly in the cloud.