AS/400 to Cloud Migration

Part 6 covered the interface, and the previous parts covered the logic and the data. This part steps back to the platform itself: when a workload is moving off the AS/400, where does it go? “To the cloud” is the usual answer, but it hides a spectrum of very different destinations with very different costs, risks, and outcomes. Choosing among them well, and crucially getting off the platform incrementally rather than in one lift, is what separates a smooth program from a stalled one.

“The cloud” is several destinations

The most important correction to make early is that AS/400-to-cloud is not one move. It runs from “same application, someone else’s hardware” to “new application, new architecture”, and conflating them produces both wasted money and dashed expectations.

1. Cloud-hosted IBM i on Power (rehost)

IBM i runs on IBM Power, and cloud-hosted Power infrastructure lets you run your IBM i environment largely unchanged without owning or refreshing the hardware. Your RPG, DB2 for i, CL, and applications come across essentially as they are. The benefits are real and immediate:

• You exit the data center and the hardware-refresh cycle.
• You can improve disaster recovery and resilience with cloud-grade infrastructure.
• You convert a capital-and-facilities burden into an operational one.

The honest limit is equally clear: this is a rehost. The application is still RPG on IBM i. The skills shortage from Part 2 is unchanged, and the agility constraints are unchanged. Rehosting solves the hardware and facilities problem completely and the platform problem not at all. That is fine when hardware and facilities are genuinely the pain, but treating a rehost as the finish line when the real problem is the platform is a costly mistake.

2. Re-platform around the edges

A middle path keeps the IBM i core but moves surrounding workloads, such as reporting, analytics, integration, and new front ends, into modern cloud services that connect to the core through the APIs from Part 6. The system of record stays on IBM i, possibly cloud-hosted, while the system of engagement moves to the cloud. This is a pragmatic way to gain modern capabilities without committing to a full transformation, and it is frequently the highest-return move for a shop that intends to keep IBM i for the core.

3. Re-architect off the platform (transform)

The deepest option rebuilds the workload as modern services on a public cloud, the RPG-to-Java and DB2-for-i migrations from earlier parts, landing on cloud-native infrastructure. This is the option that actually resolves the skills and agility constraints, because the workload is no longer RPG on IBM i at all. It is also the largest, most expensive, and most carefully staged of the three, and it is only warranted where the specific reasons to leave the platform genuinely apply.

The pattern mirrors the mainframe’s cloud paths closely, the same spectrum of rehost to transform on a different underlying stack.

The cloud targets, side by side

The four options, including the one people forget (leaving it where it is), read most clearly next to each other. The columns that matter are what actually moves and, just as important, what the move does not fix.

Target	What moves	What it fixes	What it does not fix	Choose it when
Stay on-prem for now	Nothing	Avoids spend and disruption	Everything, eventually	The workload is stable and under no real pressure
Rehost to cloud-hosted Power	The environment, application unchanged	Data-center burden, hardware refresh, resilience	Skills, agility, RPG dependence	Hardware and facilities are the pain and the app is fine
Re-platform the edges	Surrounding workloads only	Modern capability around a stable core	The core is still RPG on IBM i	You intend to keep IBM i as the system of record
Re-architect off the platform	The workload itself, into cloud-native services	Skills, agility, and platform dependence	Nothing, but it is the largest, costliest move	The platform itself is the constraint and leaving it is justified

Where you can actually run IBM i in the cloud

A rehost raises a practical question the marketing rarely answers: where does IBM i actually run once it leaves your data center? IBM i needs IBM Power hardware, so a cloud host has to offer Power. That rules out running it as an ordinary virtual machine on a general-purpose cloud. Three categories cover the real options.

• IBM’s own Power cloud. IBM offers Power Virtual Server, letting you run IBM i on IBM-managed Power infrastructure. It is the most direct route and keeps you inside the IBM ecosystem.
• Hyperscaler-adjacent Power hosting. Partner offerings place Power capacity next to a major public cloud, so IBM i can sit close to workloads running on that cloud with low-latency connectivity. This is useful when the rest of your estate already lives on one hyperscaler.
• Specialist IBM i cloud providers. Managed service providers run IBM i on Power as a hosted or fully managed service, often bundling operations, backup, and disaster recovery.

The differences that matter are less about the badge and more about who operates the environment, how disaster recovery is handled, how the licensing carries across, and how cleanly the hosted Power connects to whatever modern services you build around it. A rehost that isolates IBM i on an island far from everything else you run trades one constraint for another.

Rehost then transform: a common, sound sequence

These options are not mutually exclusive, and one of the most effective programs uses them in sequence. A shop under immediate hardware or data-center pressure can rehost to cloud-hosted Power first, removing the facilities burden and the hardware-refresh deadline quickly and at low risk, and then modernize the application incrementally from that cloud-hosted position, re-architecting workload by workload over time. This decouples the urgent infrastructure decision from the larger application decision, so neither one forces the other’s timeline. The mistake to avoid is the reverse: letting an infrastructure deadline stampede you into a rushed application rewrite, or letting an application ambition delay an infrastructure move that would have relieved real pressure now.

Why the lift must be incremental

Whichever target you choose, how you get there matters as much as where you land. The instinct, especially under a hardware deadline, is to plan one big lift: move the whole platform, all workloads, on a date. This concentrates every risk into a single irreversible event. If something behaves differently in the new environment, whether a timing difference, a data-access subtlety, or an integration that does not reconnect cleanly, you discover it with everything already moved and no easy way back. It is the big-bang failure mode the whole field warns against, and Boston Consulting Group’s finding that up to 70% of transformations fail (BCG, 2023) is built from exactly these bets.

The incremental alternative applies cleanly to the cloud move:

• Slice by workload. Move one coherent business capability at a time, not the whole platform at once.
• Prove each slice at parity. Before a migrated workload carries live load in its new home, its behavior is compared against the AS/400’s through parity validation, covering the timing, the outputs, and the integrations.
• Keep the AS/400 running. The platform operates throughout, handling everything not yet migrated, with a rollback path available at every step.
• Cut over behind a facade. Traffic shifts to the new environment gradually, never in one switch.

This converts the single large bet into a series of small, reversible, proven steps, and it means value arrives after the first slice rather than after a distant, all-or-nothing cutover.

The AS/400 pieces a cloud move must account for

An AS/400 workload is more than its RPG programs and DB2 for i tables. The platform bundles capabilities that modern clouds provide differently, or not at all, and each one is a line item a cloud plan has to name rather than discover late.

• Job scheduling and subsystems. The AS/400’s work-management model, with its job queues, subsystems, and scheduler, has no direct cloud equivalent. Batch orchestration has to be rebuilt on modern scheduling, and getting the timing and dependencies right is real work.
• Spooled files and printing. Report generation and printing through spooled files and output queues run through most AS/400 shops. None of it moves automatically, and users notice the day a report stops arriving.
• Data queues and messaging. Data queues are a common way programs pass work to each other. They map to modern queues or messaging services, but the mapping is deliberate, not automatic.
• The integrated file system. The IFS often holds documents, interfaces, and files other systems depend on. Migrating or bridging it is easy to miss until an integration breaks.
• Integrations and EDI. AS/400 systems frequently anchor EDI and partner integrations that assume the platform is there. Each connection has to be re-pointed and re-proven.
• Security and authority model. IBM i’s object-level authority and user profiles do not translate one-to-one to cloud identity and access management. The access model has to be reconstructed, usually more explicitly than it was before.

Missing any of these in scoping is how a cloud migration that looked done stalls on “small” things that were never small. AI-accelerated discovery earns its place here by reading the environment end to end and surfacing these dependencies before they surface themselves, under senior-engineer review.

When the cloud isn’t the answer

Cloud migration is not automatically the right answer, and the cloud is not automatically cheaper. A stable workload running predictably on IBM i, under no facilities pressure and not blocking anything new, may be cheapest left exactly where it is, possibly with a cloud-hosted Power rehost when the next hardware refresh comes due, and nothing more. The cloud earns its cost when it relieves a real pressure: data-center exit, disaster-recovery weakness, the need for elastic capacity, or the new capabilities a re-architecture opens up. Where those pressures are absent, “move to the cloud” can be a solution looking for a problem. Which pressures actually apply to your estate is exactly the keep-or-migrate question, and it deserves its own part.

Where this leads

Across seven parts this series has assumed, workload by workload, that some modernization is warranted, while repeatedly flagging that for some workloads the right answer is to do little or nothing. It is time to make that decision explicit. Part 8, Should You Keep or Migrate AS/400?, lays out the framework for deciding, workload by workload and on the actual pressures rather than the platform’s age, when to modernize, when to rehost, and when leaving a system exactly where it is is the right and honest call.