Zero-Downtime AS/400 Modernization: Is It Really Possible?

Order entry doesn't stop for a migration weekend. Neither does inventory management, invoicing, or shipping. For most enterprises still running critical operations on an AS/400 core, the honest question isn't "can we modernize" — it's "can we modernize without ever taking the system down." The answer is yes, but it requires a specific approach: the strangler pattern.

You don't switch systems overnight. You gradually redirect traffic until the old path is empty.

What the strangler pattern actually means

Named for the way a strangler fig gradually grows around a host tree, the strangler pattern modernizes a system by building a new capability alongside the old one, then incrementally routing traffic to the new path — function by function — until the legacy path handles nothing at all. At no point is there a single cutover event where everything switches at once. There's also no point where the old and new systems both need to be "fully correct" simultaneously across the entire scope, because the scope of what's live on each side shrinks and grows gradually.

Step one: build a routing layer

The first piece of infrastructure is a thin layer that sits in front of a given business function — say, order submission — and can route each request to either the legacy AS/400 program or a new implementation, based on configuration. Initially, 100% of traffic goes to the legacy path. Nothing about production behavior changes yet.

Step two: build and validate in parallel

The new implementation is built and tested against real production traffic patterns, often by running it in "shadow mode" — processing a copy of live requests without their results affecting anything — so its behavior can be directly compared against the legacy system's actual output before it's ever trusted with real transactions.

Step three: shift traffic gradually

Once shadow testing shows the new path produces correct, matching results, traffic is shifted gradually: 1%, then 10%, then 50%, monitoring closely at each step. If anything looks wrong, traffic reverts to the legacy path instantly — a config change, not an emergency rollback of code.

Step four: retire what's no longer used

Only once a function has run at 100% on the new path for a sustained period, with no incidents, does the legacy implementation get decommissioned. This is usually the safest and calmest step in the entire process, because by this point the new implementation has already proven itself under real load.

Why this takes longer, and why that's the point

Strangler-pattern modernization is slower than a big-bang rewrite, by design. The tradeoff is that at no single point in the process is the business exposed to the risk of everything breaking at once. For systems where downtime has a real, immediate cost — which describes most AS/400 environments still in production — that tradeoff is almost always the right one. Talk to Hoorbit about scoping a zero-downtime modernization plan for your environment.