IBM i Expertise That Keeps Your Core Running — And Opens It to the Modern World.

The replace-vs.-modernise decision is the most consequential technology investment decision most IBM i-dependent organisations face — and it is one that is routinely made based on incomplete analysis. The case for replacement is typically made by people who benefit financially from the replacement (modern ERP vendors and implementation partners) and is based on two arguments that are often overstated: that IBM i skills are becoming unavailable (true, but manageable with the right support partner), and that the IBM i cannot integrate with modern systems (false — a properly modernised IBM i with a REST API layer integrates as well as any other system). The case for modernisation is based on facts that are often underappreciated: the RPG programs running on the IBM i represent decades of accumulated business logic — manufacturing cost calculations, inventory valuation methods, pricing algorithms, financial posting logic — that is expensive and risky to recreate in a new system. In our experience across 150+ IBM i engagements, the organisations for whom replacement makes clear strategic sense are those where the business model has fundamentally changed (making the existing IBM i business logic obsolete rather than just aging), or where the IBM i application is a standard commodity ERP function (basic accounting, HR) rather than a proprietary competitive business process. For manufacturers, distributors, and financial services organisations where the IBM i implements complex, proprietary business logic that has been tuned and validated over decades, modernisation is almost always the lower-risk, lower-cost, and faster-to-value path. We will give you an honest independent assessment — including recommending replacement where the specific facts of your situation make it the right decision.

The retirement of long-serving IBM i developers is one of the most acute operational risks facing IBM i-dependent organisations — because those developers carry knowledge that is not written down anywhere: they know why the MRP program has the special exception logic for product category 47, they know that the cost rollup program must be run in a specific sequence after the material master update, and they know which programs write to the same DB2 physical file and must not run simultaneously. When those developers leave without a structured knowledge transfer, the organisation is left dependent on programs they cannot safely modify, cannot diagnose when they malfunction, and cannot enhance to meet new business requirements. Sourcemash addresses this risk through two parallel interventions: managed support engagement where our IBM i team becomes the day-to-day operational support resource while the existing developers are still available for knowledge transfer (overlapping their knowledge into our team before they depart), and a structured program documentation project that extracts the undocumented business logic from the RPG source code and produces human-readable documentation of what each program does, what the business rules are, and how the programs interact. This is slower and more expensive than it sounds — a complex RPG program that took 2 years to build and tune may take 3–4 weeks to fully document — but it is the only way to safely preserve the institutional knowledge that those programs represent.

Yes — a properly modernised IBM i with a REST API layer is as capable of bidirectional integration with Salesforce, SAP, Oracle, Dynamics 365, Shopify, or any other modern system as any other ERP platform. The IBM i's Integrated Web Services Server (IWS) allows RPG service program procedures and DB2 stored procedures to be exposed as REST web services that any external system can call via standard HTTPS — Salesforce querying IBM i inventory in real time, Shopify creating IBM i sales orders when a web order is placed, SAP posting goods receipt to IBM i inventory on purchase order confirmation. In the other direction, IBM i RPG programs can call external REST APIs using the IBM i HTTP API functions or through Java, Python, or Node.js running on the IBM i's open-source runtime. The historical reputation for IBM i integration difficulty comes from the pre-web-services era, when IBM i integration required flat-file exchange (CPYTOIMPF), IBM MQ, or proprietary IBM i access drivers — all of which still work but require more operational overhead than a well-designed REST API layer. The integration work is real engineering effort — but the technical capability is there, and the result is an IBM i that participates fully in the modern integration ecosystem.

IBM i OS version support follows a lifecycle that organisations running older versions need to understand — because running an out-of-support OS version means no new security PTFs (patches), which is a significant compliance and operational risk. As of 2025, the IBM i OS versions in active support from IBM are 7.3, 7.4, and 7.5 (current). Version 7.2 reached end of support in April 2023 — organisations still on 7.2 are not receiving security patches and should urgently plan an upgrade. Version 7.1 and earlier (V6R1, V5R4) are also out of support. The upgrade path from older versions requires assessing whether your current hardware can support the target OS version (IBM Power Systems hardware and IBM i OS version support have a defined compatibility matrix), whether your third-party software (particularly ISV applications and middleware) supports the target OS version, and whether any custom RPG programs use deprecated APIs that have been removed in newer OS versions. We have delivered OS upgrades from V5R4 and V6R1 to 7.5 and can conduct the compatibility assessment, plan the upgrade, and execute it in a maintenance window with a tested rollback plan if the upgrade encounters problems.

Green-screen modernisation — the transformation from the 5250 terminal emulation interface to a browser-accessible web UI — does not require rewriting the RPG programs that display the screens. The modernisation approach works by intercepting the 5250 data stream between the IBM i application and the user's browser and rendering it as an HTML/CSS web interface rather than a green-screen terminal — so the RPG programs that define the screen layouts (using DSPF display file descriptions), populate the fields (using EXFMT and WRITE operations), and respond to user input (using INFDS data structures or indicator logic) continue to operate exactly as they always have. Tools like Profound UI, Genie, and HTMX-based screen modernisation solutions provide different levels of transformation fidelity: Profound UI enables full UI redesign with drag-and-drop widget replacement, responsive layout, and custom styling, while Genie provides rapid automatic modernisation with less customisation capability but faster implementation timelines. The output in both cases is a web application that runs in any browser — including mobile — without requiring 5250 emulation software, without requiring changes to the RPG source code, and without risking the business logic that the RPG programs implement. We recommend Profound UI for organisations that want a genuinely modern UX design, and Genie for organisations where the primary requirement is browser accessibility rather than UX transformation and speed of implementation is the priority.