AS/400 to modern architecture: what actually happens

Search “AS/400 migration” and every result on the first page is a company selling you a migration. That is not an accident. Modernizing an IBM i shop is a high-dollar engagement, and the people who write the content are the people who profit from the project. This article is the one they will not write: what actually happens when you move off the AS/400, including the parts that quietly wreck timelines and budgets.

PromptedDev is not selling you a migration. So here is the honest version.

The four things that can actually happen

When leadership says “we’re getting off the AS/400,” one of four outcomes follows. They are not equally likely to succeed.

Full rewrite. You rebuild the application in Java, C#, or a web stack from scratch. This is the outcome the slide deck promises and the one that fails most often. You are not porting code, you are reverse-engineering decades of business rules that nobody fully documented, then rebuilding them in a language with none of IBM i’s guarantees. Multi-year, seven figures, high abandonment rate.

Re-platform. You move the business logic to Linux or Windows and the data to a cloud database, keeping the application shape roughly intact. Less risky than a rewrite because you are translating rather than reinventing, but you still inherit every data and performance trap below.

Lift and shift. You rehost the IBM i workload as-is on cloud infrastructure or newer Power hardware. Fastest and least disruptive because almost nothing changes. The catch is that almost nothing changes. You have moved the box, not modernized the application, and the modernization pressure returns in a year.

Modernize in place. You stay on IBM i, move to current Power hardware and a supported OS release, and expose the existing logic through APIs, SQL, and a modern editor like VS Code. For most shops this is the sane default, and it is the one vendors mention last because it bills the least.

If you take one thing from this article: the path with the best odds is usually the one with the smallest sales commission attached.

Why IBM i does not migrate cleanly

The reason migrations underestimate themselves is architectural. On IBM i, the database and the operating system are one thing. This is the Single Level Store, and RPG was written assuming it. Your programs talk to the database with record-level operations because the platform made that cheap and fast for forty years.

That tight coupling is exactly what you have to tear apart. Decoupling the logic from the database is the single hardest technical task in any IBM i migration, and there is no tool that does it for you cleanly. The integration that made IBM i reliable is the thing fighting your exit.

It gets worse when you look at where the rules live. On IBM i, data integrity is frequently implicit. The schema does not enforce it, the program does. A field is valid because the RPG program that writes it refuses to write anything invalid, not because a constraint exists in the database. Move the data to a system that expects the schema to do that job and you discover, in production, which rules were never written down.

The data traps nobody puts in the deck

Code conversion gets the demos. Data is where projects actually die.

IBM i stores numbers as packed decimal and text as EBCDIC, and it defines files with DDS rather than standard SQL. None of that moves as-is. Extraction means decoding EBCDIC, mapping DDS file layouts to real schemas, and converting packed decimal to standard NUMERIC or DECIMAL types. That last step is not cosmetic. Precision can be lost in the conversion, and a financial system that silently rounds differently after migration is a reconciliation nightmare and an audit problem.

Then there is timing. A lot of “truth” in an IBM i shop is temporal and lives in batch jobs and operational calendars. The nightly job runs in a specific order, depends on another job finishing, and assumes a business calendar that exists in someone’s head. If those job flows and dependencies are undocumented, you can extract the data and still lose the why. You will know what the numbers are without knowing how they got that way, which is the part auditors care about.

And you cannot solve this by deleting the old data. Regulations like SOX, HIPAA, and GDPR require seven to ten or more years of retention. Compliant archival of the historical record is a legal prerequisite before you decommission anything, not an optional cleanup task for later.

The performance trap

Here is one that surprises teams mid-project. IBM i, through the Single Level Store, treats memory and disk as one address space. Your record-at-a-time RPG I/O is “chatty” by design and the platform absorbs it.

Move that same logic to x86, where RAM and disk are genuinely separate, and the chatty I/O that ran fine for years can fall over. I/O-heavy jobs slow to a crawl. The fix is to refactor record-level operations into set-based SQL before you migrate, which is real engineering work that the migration estimate rarely included. Teams find out about this when the re-platformed system is technically working and unusably slow.

The secret sauce problem

Most AS/400 applications run heavily customized business logic that is, genuinely, a competitive advantage. The industry’s own term for it is “secret sauce,” and the problem is that the people who could read all of it are retiring or already gone. If you have followed what happens when the last RPG developer leaves, you know this is not hypothetical.

You cannot migrate logic you cannot read. Validating the extraction rules and the edge cases requires RPG and CL expertise, which is the exact skill that is scarce. This is why migrations that look feasible on paper stall in practice. The estimate assumed the business rules were knowable. Half of them are buried in a program last touched in 2004 by someone who left in 2011.

Where AI actually helps in 2026, and where it doesn’t

AI changes the math here, but not the way the marketing implies. The useful move is to document the logic before you touch it. Tools that explain what an undocumented RPG program does, in plain language, turn a six-week archaeology project into a few days. That is real, and it is the highest-value thing AI does in this space right now.

The freshest example is IBM’s own. IBM shipped Bob 1.0 to general availability on March 24, 2026, an IBM-branded assistant delivered as a VS Code plug-in. It uses a mix of models, including IBM’s Granite and Anthropic’s Claude, and it can explain, refactor, generate, transform, and test code across RPG, CL, SQL, COBOL, Java, and Python. It understands Db2 for i performance characteristics and IBM i security. IBM followed up with a Bob Premium Pack on June 1, 2026. The reception has been mixed for a practical reason: early versions require downloading all of your code to the PC for Bob to work, which not every shop will accept.

The point is the direction, not the specific tool. AI is excellent at reading legacy code and drafting conversions. It is not going to reconcile your data, infer the batch dependency that exists only in a scheduler, or test an edge case it has never seen. Treat it as a fast junior developer who needs everything checked, and it earns its place. Treat it as an autopilot and it will confidently hand you a Java method that does the wrong thing in February.

If you want a structured way to use AI on IBM i code without learning it all by trial and error, the IBM i AI Field Guide collects the prompts and workflows that actually work for RPG and CL. And if you have not decided your path yet, our take on where to start with IBM i modernization covers the in-place option in more depth.

How to decide, if you haven’t committed

A sane sequence for a shop that has been told to modernize but has not signed anything:

First, document before you decide. Use AI to explain the critical programs and capture the business rules while the people who know them are still around. You need this map regardless of which path you choose, and it is cheap insurance.

Second, be honest about the actual driver. “The AS/400 is old” is not a technical requirement. A specific integration the platform cannot support, a corporate mandate, or a real cost case is. If you cannot name the concrete reason a rehost or in-place modernization will not meet, you do not yet have a rewrite justification.

Third, default to the smaller move. Modernizing in place on current Power hardware, with APIs and a modern editor, buys you most of the integration benefits at a fraction of the risk, and IBM’s roadmap to 2035 means you are not racing a platform deadline. You can always escalate to a rewrite later with a real map in hand. You cannot un-spend two years and seven figures on a rewrite that stalled.

Bottom line

Migrating off the AS/400 is not the clean lift the first page of Google suggests, because the people writing that page are selling the lift. The platform does not separate cleanly from its data, the integrity rules live in code rather than the schema, the numbers and timing do not port for free, and the logic that makes your business money is the logic nobody can fully read anymore.

None of that means stay frozen. It means decide with eyes open. Document the logic first, name the real reason you are moving, and default to the smallest change that solves the actual problem. For most IBM i shops in 2026, that is modernizing in place, not a rewrite. The vendors will tell you that last. Now you heard it first.

Frequently asked questions

How long does an AS/400 migration actually take?

A full rewrite of a mature IBM i application is usually a multi-year project, not a multi-month one. Vendors who quote a fixed timeline are pricing the code conversion, not the data reconciliation, edge-case testing, and parallel running that consume most of the schedule. Plan in years if you are replacing the platform, and in weeks if you are modernizing in place.

Is it better to migrate off IBM i or modernize in place?

For most shops, modernizing in place is the lower-risk option. IBM publishes a roadmap for IBM i that extends to 2035, so the platform is not the deadline. Moving to x86 or the cloud only pays off when you have a concrete reason the current platform cannot meet, such as a corporate mandate or an integration the system genuinely cannot support.

Can AI convert RPG to Java automatically in 2026?

AI can translate RPG syntax to Java and explain what undocumented code does, which saves real time. It cannot reconcile your data, infer business rules that live only in batch jobs, or test edge cases it has never seen. Treat AI as a fast junior developer, not an autopilot, and verify everything it produces.

What is the biggest risk in an AS/400 migration?

Data, not code. IBM i enforces integrity inside program logic rather than the schema, stores numbers as packed decimal, and encodes timing in batch jobs. Extracting that cleanly is where projects blow up budgets, lose precision, and create audit gaps. Reconciliation is the part nobody demos.