Should You Keep or Migrate AS/400?

Seven parts have, workload by workload, shown how to modernize an AS/400 — while flagging at every turn that for some workloads the right answer is to do little or nothing. This part makes that judgment explicit and gives you a framework for it. The keyword people search is “AS/400 vs cloud”, but the framing is a trap: it implies a single, platform-wide verdict. The right question is never “keep or migrate the AS/400?” It is “keep, rehost, or migrate this workload?” — asked of each capability, and answered on the pressures that actually apply to it.

Start by rejecting the age argument

The most common bad reason to migrate is the platform’s age, and the most common bad reason to stay is that it works. Both miss the point.

As Part 1 established, IBM i is not end-of-life. IBM actively supports it, version 7.5 shipped in 2022, it runs on current Power hardware, and the published roadmap extends well into the 2030s (IBM, 2022). So “we have to get off it because it’s dying” is false, and any vendor leading with platform-death urgency is selling fear. Equally, “it still works, leave it” ignores costs that uptime conceals. The decision has to be made on the real pressures, not on the calendar or on a reflex in either direction.

The forces that argue for migrating

Migrate a workload when one or more of these is real and compounding — because each gets worse, not better, with time:

• Skills risk you actually depend on. If a workload’s continued operation depends on one or two people who can read its RPG, and they are near retirement, the skills cliff from Part 2 is not abstract for that workload — it is a live, dated risk. The more business-critical and the more change-prone the workload, the sharper the risk.
• Logic blocking new capability. When the business wants a customer portal, a mobile app, a partner integration, or an analytics capability and cannot build it because the logic is locked on the platform, the AS/400 is imposing an opportunity cost that often dwarfs its run cost. This is frequently the single largest driver of real value.
• Rising compliance or integration pressure. New regulatory requirements, audit findings, security expectations, or integration demands that the closed platform makes expensive or slow to satisfy. Where dependencies or surrounding software are themselves aging out of support, a quick check with the Software EOL Checker can surface deadlines you are carrying without realizing it.
• Change frequency. A workload that has to change often — new products, new rules, frequent fixes — pays the skills-and-agility tax repeatedly. The more you have to touch it, the more its constraints cost you.

The throughline: migration is justified by pressure and change, not by age. A workload under several of these forces is a strong migration candidate; the cost of waiting on it compounds quarter over quarter.

The forces that argue for keeping (or just rehosting)

Keep a workload on IBM i — or rehost it to cloud-hosted Power without re-architecting — when the picture is the opposite:

• Stable and rarely changed. A workload nobody is asking to change is not paying the agility tax, no matter how old the code is.
• Cheap to run and not blocking anything. If it runs predictably and nothing the business wants is stuck behind it, the case for spending a migration budget is weak.
• Self-contained. A workload with few integrations and no external pressure carries little of the risk that justifies migration.

For these, “keep” is not surrender — it is correct portfolio discipline, the same retain decision the mainframe series defends. The error is keeping by default — never asking the question — rather than keeping by decision.

But keeping responsibly means more than leaving it alone. Even a workload you decide to keep should have its undocumented rules captured as living specs so you are not exposed to key-person risk, and its OS and dependencies kept on supported versions. Responsible “keep” removes the cheap-to-remove risks now and defers only the larger migration cost — it is not the same as ignoring the system.

A practical way to decide

The decision becomes tractable when you stop arguing about the platform and start scoring the workloads. A workable approach:

1. Inventory the workloads, not the system. Break the estate into coherent business capabilities — order entry, pricing, billing, inventory, a specific reporting function. The platform is not one thing; it is a portfolio.
2. Score each on pressure. For each workload, assess the four migration forces (skills dependency, blocked capability, compliance/integration pressure, change frequency) and the keep factors (stability, run cost, isolation). This produces a ranking, not a binary.
3. Assign an approach per workload. High-pressure workloads get migrated, and the highest-pressure ones go first. Medium ones may get API enablement or refacing. Low-pressure ones get kept — responsibly — or rehosted. Most estates end up with a mix, which is the correct outcome, not a failure to decide.
4. Ground it in evidence with discovery. Opinions about which workloads are entangled, which hold the riskiest knowledge, and which are truly blocking the business are usually wrong in detail. A fixed-scope discovery phase replaces opinion with evidence — what each workload actually does, how coupled it is, where the real pressures sit — and turns the ranking into something you can fund with confidence.

This per-workload, evidence-based approach is itself a de-risking move: it prevents both over-investing in stable workloads and under-investing in the ones quietly costing the business the most.

The advice that cuts against us

We would rather tell you a workload should stay than sell you a migration it does not need. The strongest version of this advice cuts against our own engagement: if your AS/400 estate is overwhelmingly stable, cheap, and not blocking anything, the right program may be small — capture the knowledge to kill the key-person risk, keep the platform supported, and revisit when a real pressure appears. The cost-of-delay argument is powerful precisely where pressures are real and compounding; it does not apply to a system no one is pushing on. The first question is not “how do we migrate the AS/400?” but “which workloads are actually costing us something — and what, specifically?”

Where this leads

Once you have decided which workloads to migrate and in what order, the conversation turns to the question every economic buyer asks: what will it cost, and is it worth it? Part 9, AS/400 Modernization Cost, gives you the framework for the economics — the cost drivers specific to RPG, DB2 for i and 5250, the total cost of ownership the platform bill hides, the cost of delay the skills cliff makes literal, and how to make the investment predictable rather than open-ended.