HoorA Practical Roadmap for AS/400 to Cloud Migration
"Move the AS/400 to the cloud" means something different in almost every conversation we have. Sometimes it means running IBM i on cloud-hosted infrastructure. Sometimes it means moving specific workloads off the AS/400 entirely. Most of the time, it means something in between — and getting the sequencing right is what separates a successful migration from a stalled one.
The AS/400 doesn't need to move to the cloud all at once. It needs to move in an order that never breaks production.
Phase 1: Map before you move anything
Before any migration decision, we build a complete map of what's actually running: which programs are active, which are dead code nobody's cleaned up, what depends on what, and which integrations exist outside the documented ones. This phase alone frequently surfaces integrations nobody remembered existed — and moving without this map is how migrations break things nobody was watching.
Phase 2: Establish an API layer first
Before touching infrastructure, we expose core business logic through APIs (see our companion piece on wrapping RPG programs as REST endpoints). This decouples everything downstream from the AS/400's physical location. Once consumers talk to an API instead of the system directly, the underlying infrastructure can change without every integration needing to change with it.
Phase 3: Move the right workloads first
Not everything needs to move at once, and not everything needs to move to the same place. Reporting and analytics workloads are usually the easiest first candidates — they can run against a replicated or synced copy of the data in a cloud data warehouse with low migration risk. Core transactional processing generally moves last, once the surrounding systems have proven the new architecture under real load.
Phase 4: Decide on the AS/400's own future
Only after the above phases does the question of the AS/400 platform itself become concrete: staying on IBM i (potentially cloud-hosted), or migrating specific business logic off the platform entirely. This decision is easier to make well once you have real usage data from the API layer showing which parts of the system are actually load-bearing versus which are legacy paths nobody uses anymore.
Phase 5: Decommission deliberately, not accidentally
The final phase is retiring what's no longer needed — old batch jobs, redundant reports, integrations that were replaced by the API layer. This should be a deliberate, tracked process, not an assumption that old paths are safe to delete because nothing obviously depends on them anymore.
The common mistake
The migrations that struggle are almost always the ones that started with infrastructure — picking a cloud target and a migration tool — before doing the mapping and API-enablement work. Sequence matters more than the specific cloud platform you land on. See how Hoorbit's engagements are scoped for a migration roadmap that fits your system's actual dependencies, not a generic template.