Answer
In practice, this usually starts with wrapping or replacing the presentation layer, moving users off raw 5250 screens onto a modern interface that still calls the same underlying RPG or COBOL programs, so the business logic and Db2 for i data model stay untouched. From there, teams often move to workflow automation, such as routing approvals or exceptions automatically instead of relying on manual green-screen steps, and then to exposing specific transactions as APIs so mobile apps, partner systems, or e-commerce platforms can interact with the core without a human retyping data.
The code layer is usually the last stop, not the first, because it carries the most risk and the least visible payoff on its own. When code work does happen, it tends to be targeted, refactoring the specific programs that block an API or a workflow change rather than a wholesale rewrite. Buyers should ask any vendor proposing this kind of phased plan how they will test that each phase preserves data integrity in Db2 for i, since a phased approach only lowers risk if the transaction engine really is left alone until it needs to change.