#011 MIGRATE Mainframe Application to AWS CLOUD
1. Three Migration Approaches (AWS)
A) Rehost (Lift & Shift)
IBM i → Skytap on AWS (currently only GA on Azure, but AWS has partners like Infinite i or emulate via Power Systems hosting).
z/OS → Rehost via Micro Focus Enterprise Server or TmaxSoft OpenFrame on EC2.
Pros:
Quick exit from data center.
Minimal code changes (COBOL/RPG).
Ops consolidated under AWS (CloudWatch, IAM, Backup).
Cons:
Still carries legacy debt.
Licensing cost (Micro Focus, OpenFrame).
Not cloud-native (limited autoscale).
B) Replatform (Recommended)
Expose z/OS CICS via APIs (API Gateway + MQ connectors).
Expose IBM i RPG via API (Lambda + API Gateway, or via partner connectors).
Move Db2 → Amazon RDS (SQL Server/Postgres) or Amazon Aurora.
New services → ECS/EKS (containers) or Lambda.
Pros:
Uses managed DB (Aurora/RDS) = lower ops cost.
API Gateway + Step Functions modernize workflows.
Easier DevOps, CI/CD with CodePipeline.
Cons:
Data migration complexity (Db2 → Aurora).
Legacy wrappers still needed (CICS/IBM i APIs).
Moderate cost & timeline.
C) Refactor (Rebuild Cloud-native)
Rewrite COBOL/RPG logic in Java/.NET/Python microservices.
Run on EKS/ECS Fargate or Lambda.
Use Aurora/Postgres or DynamoDB.
Pros:
Fully cloud-native, autoscale, modern DevOps.
Event-driven design with EventBridge/Kinesis.
Long-term TCO lowest.
Cons:
Highest cost/time upfront.
Regression risk (rewriting proven logic).
Needs strong test automation.
2. Selected Approach → Replatform (balanced risk/benefit)
3. 12-Month Migration Plan (AWS Replatform)
M1 — Discovery & Strategy
Inventory apps, DB schemas, batch jobs.
Define AWS landing zone (Control Tower, Org accounts).
Pick target DB (Aurora vs RDS).
M2 — Landing Zone & Connectivity
Setup Control Tower, GuardDuty, IAM roles.
Direct Connect (or VPN fallback).
CloudWatch/CloudTrail enabled.
M3 — Data Assessment
Run AWS Schema Conversion Tool (SCT) on Db2.
Identify gaps for Aurora.
Estimate storage/compute sizing.
M4 — API Wrappers for Legacy
Expose CICS via z/OS Connect + API Gateway.
Expose RPG via IBM i APIs or MQ bridge.
Secure with IAM + WAF.
M5 — Bulk Data Migration (Pilot)
Use AWS DMS to migrate PRODUCT, CUSTOMER.
Validate with Athena queries + Glue catalog.
M6 — CDC Setup
Enable continuous replication Db2 → Aurora using DMS ongoing replication.
Run dual sync.
M7 — First AWS Service
Build Inventory microservice on ECS Fargate.
Read from Aurora (read-only at first).
M8 — Flip First Write Path
Orders written to Aurora.
Mirror back to Db2 during validation.
M9 — Messaging Bridge
Connect IBM MQ with Amazon MQ (ActiveMQ/RabbitMQ).
Migrate non-critical queues.
M10 — Expand AWS Services
Add Pricing & Customer Update microservices on EKS or Lambda.
Route both read/write to Aurora.
M11 — Consolidate Ownership
Aurora promoted to system of record.
Db2 becomes consumer only.
M12 — Optimize & Decommission
Performance tuning (Aurora Serverless v2 autoscaling).
Cost optimization (Savings Plans, S3 for cold data).
Decommission legacy workloads or rehost residuals.
4. Team Skills per Month
AWS Solution Architect (whole year).
Db2 DBA + Aurora DBA (M3–M11).
Mainframe/IBM i SMEs (M1–M6 for APIs & migration).
Developers (Java/.NET, RPG/COBOL API wrappers) (M4–M10).
DevOps/SRE (CI/CD, observability).
FinOps (M9–M12, optimize cost).
5. Cost Curve
M1–M3: Low–medium (planning, Direct Connect).
M4–M6: Medium (APIs, bulk load, DMS).
M7–M10: High (dual-writes, ECS/EKS services, MQ bridge).
M11–M12: Declining (retiring legacy, optimize Aurora/S3).
✅ By end of Month 12:
Orders, Products, and Customers live in Aurora.
Core microservices in ECS/EKS/Lambda.
Legacy runs in read-only or shut down.
Observability & DR ready in AWS.