
What actually happens when an IBM i shop migrates off the AS/400 (the data part nobody demos)
Every "AS/400 migration" article I can find is written by a company that sells migrations, so I wrote up the version I wish existed when we started looking at this.
The thing that surprised me most: code conversion gets all the demos, but data is where projects actually die. On IBM i the database and the OS are effectively one thing, and a lot of integrity is enforced inside the RPG programs rather than by the schema. A field is valid because the program refuses to write anything invalid, not because a constraint exists. Move that data to a platform that expects the schema to enforce it and you find out in production which rules were never documented.
Then there's packed decimal and EBCDIC, which don't move as-is, and the precision loss converting packed decimal to standard NUMERIC is a real reconciliation and audit problem if you miss it. And record-at-a-time I/O that ran fine for decades on Single Level Store can fall over on x86 where RAM and disk are separate. You end up refactoring chatty I/O into set-based SQL before you can migrate, which nobody budgeted for.
My takeaway: for most shops, modernizing in place on current Power hardware beats a rewrite, and since IBM's roadmap runs to 2035 the platform isn't the deadline. AI (including IBM Bob now) is good at explaining old code and documenting logic first. It will not reconcile your data.
Curious what others here have seen go wrong on real migrations. Full writeup if it's useful: https://prompteddev.com/blog/as400-migration-what-actually-happens