How to modernize an AS/400 or legacy ERP without stopping operations

The system runs payroll, orders, inventory and invoicing. It has run them for twenty years. Nobody wants to touch it, and everybody knows it cannot stay as it is. The question is how to change it without a single missed shipment.

The short answer is that you do not replace it in one move. You build around it, peel off one workflow at a time, and keep the old system as the source of record until the new one has earned that role.

Why do big-bang ERP replacements fail?

A big-bang replacement asks the whole company to switch on one weekend. Every customer-specific pricing rule, every odd unit of measure, every report someone built in 2009 has to be right on day one. It almost never is.

The usual causes are predictable:

• The old system holds business rules nobody wrote down. They live in RPG or COBOL code, in green-screen habits, and in the heads of two or three people.
• The data is dirtier than anyone admitted. Duplicate customers, free-text fields that carry meaning, part numbers reused over the decades.
• The cutover date becomes a deadline that hides problems instead of exposing them.
• Operators are trained on screens they have not used under real load.

A big-bang project can still work in a small business with a simple process. For a plant, a yard or a distribution center with years of accumulated rules, staged is safer.

What does a staged modernization look like?

Think of it as strangling the old system slowly, one function at a time, rather than cutting it out. The sequence below is a pattern that holds up across AS/400, older Oracle or SQL Server ERPs, and Access-based systems.

1. Map what the system actually does. Inventory the screens, the batch jobs, the reports, the files it sends and receives, and the people who depend on each. This is the unglamorous step that decides everything else.
2. Get a safe read path first. Replicate or expose the data without changing the system. Read-only access lets you build dashboards and new screens with no risk to production.
3. Put an API layer in front of it. Wrap the functions you need (look up a customer, create an order, post a receipt) so new software calls the wrapper instead of touching tables directly.
4. Move one workflow. Pick something bounded and painful, such as receiving, scale tickets, quoting or dispatch. Build it new, run it alongside the old way, and compare.
5. Run in parallel, then cut that one piece over. Retire the old screen only when the numbers match for long enough that people trust it.
6. Repeat, then retire the core. When the last workflow has moved, the old system is a database nobody uses. Archive it.

Each step is reversible. That is the point.

Should we replace the ERP or build around it?

Both are valid. The honest answer depends on what is actually wrong.

Approach	Best when	Main risk
Wrap and extend the existing system	The core logic is sound; the problem is access, reporting or missing screens	The old platform stays a dependency, and skilled staff keep retiring
Replace with a packaged ERP	Your process is close to standard and you want vendor support	Heavy configuration, and your unusual rules get forced into the package
Replace with custom software, staged	Your process is the competitive advantage, or no package fits	Needs disciplined scoping, and you carry the build
Rehost or re-platform as-is	The hardware is the risk, not the software	Moves the problem without fixing it

Many companies end up with a mix: a packaged system for accounting and general ledger, custom software for the operational workflows that make them different, and an integration layer between the two.

Is the AS/400 itself the problem?

Usually not. IBM i is a reliable machine, and plenty of them run for years without a reboot. The real problems tend to sit around it:

• Only one or two people understand the code, and they are close to retirement.
• The interface is green-screen, so training new hires is slow and mobile access does not exist.
• Getting data out means a nightly flat file or a report someone prints and retypes.
• Every integration with a customer or carrier is a one-off.

These are solvable without removing the platform. A good first project is often not “replace the AS/400” but “make its data and functions reachable by modern tools.” That alone changes what is possible, and it buys time to decide what to retire.

How do you keep operations running during the change?

Downtime comes from surprises. Remove the surprises.

• Run parallel. For a defined period, staff enter or receive work in both systems, or the new system mirrors the old one, and someone reconciles the differences daily. Every mismatch is a bug found before it costs money.
• Cut over by site, line or customer group, not by company. A pilot at one yard or one product family limits the blast radius.
• Pick quiet windows deliberately. A cutover during month-end close or peak season is a self-inflicted wound.
• Write the rollback plan first. If the new receiving screen fails at 6 a.m., what do the operators do at 6:05? Paper forms and a clear path back to the old screen should be ready and rehearsed.
• Freeze scope on the old system, but keep fixing real defects. Otherwise the target moves while you build.

What should you do about the data?

Data migration is where schedules slip. Treat it as its own workstream, started early.

Profile the data before deciding anything. Find the duplicates, the orphaned records, the fields that mean different things in different years. Decide what comes across, what gets archived and what gets dropped. Many companies migrate ten years of history when two years of live data plus a searchable archive would serve better.

Migrate in repeatable scripts, not by hand. Run them many times against copies of production, and compare record counts and totals each time. The final migration should be the boring fortieth run, not the first.

Who needs to be involved?

The people who know the exceptions. A scale-house clerk knows what happens when a driver arrives with the wrong paperwork. A dispatcher knows which customers get special treatment. Put those people in the room early, show them working software every week, and let them break it.

Keep your in-house IT staff in the project, not outside it. They will run whatever gets built, and they hold the context an outside team cannot get from documentation.

What does a realistic first step cost in time?

You can learn a lot in a few weeks. A short assessment that maps systems, data, integrations and pain points, and ends in a written plan with a prioritized order of work, is the cheapest way to avoid a wrong turn. It tells you whether to wrap, replace or mix, which workflow to move first, and what the real risks are.

If a vendor or consultant proposes a full replacement before they have looked at your data and your exceptions, treat that as a warning sign.