AS400 to Cloud: A Practical Migration Playbook

The IBM AS400 (now IBM iSeries / IBM i) remains one of the most resilient enterprise platforms ever built. Decades after their initial deployment, many organizations in retail, construction, distribution, and manufacturing still rely on AS400 systems for their most mission-critical operations — inventory management, order processing, financial ledgers.

But resilience comes at a cost. AS400 expertise is increasingly scarce. Integration with modern analytics tools is painful. And the on-premise infrastructure burden is becoming harder to justify. The question isn't *if* to migrate — it's *how* to do it without disrupting 24/7 operations.

The Challenge: Why AS400 Migrations Fail

Most failed AS400 migrations share the same root causes: treating it as a pure technical exercise, underestimating business logic embedded in RPG/COBOL programs, and attempting a "big bang" cutover instead of an incremental approach.

• Business logic spread across thousands of RPG, COBOL, and CL programs with no documentation
• Tightly coupled batch jobs with implicit dependencies that only surface under load
• Data schemas designed for DB2/400 that don't translate cleanly to relational cloud databases
• Real-time integrations with EDI partners, external APIs, and legacy ERP systems

Our Approach: Strangler Fig, Not Big Bang

We advocate for the Strangler Fig pattern: incrementally replace AS400 functions with cloud-native equivalents while keeping the AS400 running in parallel. New functionality goes to the cloud; existing workflows continue on AS400 until they're fully replaced and validated.

Step 1: Deep Discovery

Invest 4-6 weeks in discovery before writing a single line of migration code. Interview business users — not just IT — to understand what the system actually does vs. what the documentation says it does. Map all data flows, batch schedules, and external integrations. This discovery phase is where migrations are won or lost.

Step 2: Extract Data First

Before migrating applications, establish a reliable data replication pipeline from AS400 to your target cloud platform (AWS RDS, Azure SQL, GCP Cloud SQL, or a data warehouse like Snowflake). Tools like IBM CDC, Debezium, or Airbyte can capture DB2/400 changes in near-real-time. This gives you a live cloud replica to develop against — and a safety net.

Step 3: Migrate by Domain

Identify bounded domains (inventory, orders, finance, HR) and migrate one domain at a time. Start with the domain that has the least complex external dependencies and the clearest business value from modernization. Each domain migration follows the same pattern: parallel running, data parity validation, cutover, monitoring.

Technology Choices That Work

• Data replication: Airbyte or IBM CDC for AS400 → cloud streaming
• Target database: PostgreSQL on AWS RDS or Azure SQL for OLTP workloads
• Data warehouse: Snowflake for analytics and reporting
• Application layer: containerized microservices (Docker + Kubernetes) replacing RPG programs
• ETL/ELT: Informatica IDMC or Talend for data transformation pipelines
• Monitoring: Grafana + Prometheus for pipeline observability

Measuring Success

Define success criteria before you start, not after. Track: infrastructure cost per transaction, batch job execution time, data freshness (time from source event to analytics availability), and mean time to deploy new features. These metrics tell the story of the modernization's business value — and justify the investment to stakeholders.

AS400 migrations are complex, long-running engagements that require both deep technical expertise and strong change management. The organizations that succeed treat it as a business transformation, not just an IT project.