Every few years the conversation restarts. Someone in leadership reads an article, attends a conference, or gets a call from a vendor, and the question arrives in the IT department: should we move off IBM i? Sometimes the question is sharper — we are moving to the cloud, what do we do with the AS/400?
These conversations have been happening since the mid-2000s. The shops that handled them well are still running IBM i in 2026, with modernised interfaces, cloud integrations, and lower operational costs than they had a decade ago. The shops that handled them poorly either went through expensive failed migrations or are running older applications than they were then, having paused investment while the debate continued.
This post is about what staying on IBM i actually means today — not the defensive case for keeping the platform, but the practical architecture of a modern IBM i shop in 2026.
What “the cloud” means for IBM i
Cloud is not one thing. For IBM i, there are three distinct cloud conversations that often get conflated:
Infrastructure as a Service (IaaS) — running IBM i on rented hardware rather than owned hardware. IBM offers IBM i on IBM Cloud. Skytap runs IBM i on Azure. Several managed service providers offer hosted IBM i. The operating system, your applications, and your data are exactly the same — only the hardware ownership changes.
Hybrid architecture — IBM i handles what it is good at (transactional processing, ERP, batch) while cloud services handle what they are good at (web front ends, mobile APIs, analytics, machine learning). The two talk to each other over APIs.
Migration away — moving applications off IBM i entirely, rewriting them in modern languages on commodity infrastructure. This is the hardest path, the most expensive, and the one most likely to go wrong.
Most successful modernisation strategies are option two — hybrid. They keep IBM i for its genuine strengths and stop asking it to do things it was not designed for.
What IBM i is genuinely good at in 2026
This is not nostalgia — it is an honest assessment of where IBM i has durable advantages:
Transactional throughput and reliability. IBM i systems routinely run for years without an unplanned outage. The integrated database, journaling, and commitment control model handles high-volume transactional workloads with a reliability that is genuinely difficult to replicate on commodity infrastructure.
Existing business logic. Decades of business rules encoded in RPG and CL programs represent an enormous amount of institutional knowledge. That logic is correct — it handles the edge cases, the exceptions, the regulatory requirements that accumulated over years. Rewriting it introduces risk without adding value.
Total cost at scale. For shops processing millions of transactions per day, the per-transaction cost of IBM i is often lower than cloud alternatives once you account for actual compute and storage costs at scale. Cloud is not automatically cheaper.
Security model. The object-level authority model and integrated security architecture are ahead of most platforms. IBM i systems have an excellent track record against ransomware and data breaches when properly configured.
What IBM i is not good at, and where cloud fills the gap
Equally honest — the areas where cloud services genuinely outperform IBM i:
Web and mobile front ends. Building modern browser-based or mobile interfaces on IBM i requires running a web server in PASE, using PHP or Node.js, and bridging to the RPG layer. It works, but it is more complex than building the same interface on a purpose-built cloud platform. Most shops are better served by a modern front-end framework talking to IBM i via APIs.
Analytics and reporting. IBM i’s DB2 is excellent for transactional queries. It is not optimised for large-scale analytical workloads — complex aggregations across billions of rows, machine learning against historical data, real-time dashboards fed from dozens of sources. Replicating IBM i data to a cloud data warehouse (Snowflake, BigQuery, Redshift) and running analytics there is a well-established pattern.
Developer tooling ecosystem. The ecosystem of open-source tools, frameworks, and talent for cloud-native development is vastly larger than for IBM i. If you are building greenfield applications, starting on IBM i is a harder hiring and tooling problem than starting on a modern platform.
Event-driven and serverless workloads. Sporadic, event-driven processing (webhooks, file arrival triggers, scheduled micro-tasks) is what serverless cloud functions are designed for. Running these workloads on IBM i is possible but awkward.
The hybrid architecture pattern that works
The architecture that most successful IBM i modernisation efforts land on:
┌─────────────────────────────────────────────────────────┐
│ CLOUD / INTERNET │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Web / Mobile│ │ Analytics │ │ Integration │ │
│ │ Front End │ │ Data Warehouse│ │ Platform │ │
│ │ (React/Next) │ │ (Snowflake) │ │ (MuleSoft / │ │
│ └──────┬───────┘ └──────┬───────┘ │ Azure iPaaS)│ │
│ │ │ └──────┬────────┘ │
└─────────┼──────────────────┼─────────────────┼──────────┘
│ REST APIs │ CDC/Replication │ Events
│ │ │
┌─────────┼──────────────────┼─────────────────┼──────────┐
│ ▼ IBM i ▼ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ RPG / CL Business Logic + DB2 for i │ │
│ │ (Orders, Inventory, Finance, HR, ERP core) │ │
│ └──────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────-┘IBM i owns the transactional core. Everything outward-facing is modern and cloud-native. The integration layer in the middle handles the data flows between them.
Exposing IBM i data via REST APIs
The most important technical enabler of the hybrid model is IBM i’s ability to serve REST APIs. As covered in the Modern Integrations post, the options are:
IBM i Access REST services — available from 7.3 onwards, allows direct HTTP access to DB2 for i queries without any custom code. Useful for read-only data access from internal tools.
RPG CGI / ILE Web — RPG programs that run as HTTP request handlers under the integrated Apache server. Functional but verbose.
Node.js or PHP in PASE — the most practical option for new API development. A Node.js Express application running in PASE handles HTTP routing, authentication, and JSON serialisation. It calls RPG programs as stored procedures or command calls. The RPG layer handles business logic and database access exactly as it always did.
IBM API Connect or MuleSoft — enterprise integration platforms that can wrap IBM i data access behind a managed API gateway, adding rate limiting, authentication, and versioning. Right for large organisations with complex integration needs.
Data replication for analytics
Getting IBM i data into a cloud analytics platform requires a replication pipeline. The standard approaches:
Change Data Capture (CDC) via journaling — IBM i’s journal records every change to every journaled file. Tools like IBM InfoSphere CDC, Precisely Connect, and HVR read the journal and replicate changes to a target database in near-real time. This is the lowest-latency option and does not impact IBM i performance.
Scheduled SQL extracts — a batch process runs on a schedule, queries DB2 for changes since the last run, and loads them to the target. Simpler to set up, introduces latency, and requires a reliable change-tracking mechanism (updated timestamp columns, sequence numbers).
IBM Db2 Mirror for i — IBM’s own active-active replication, primarily designed for high availability rather than analytics offload. Expensive and complex, but provides the lowest RPO/RTO for disaster recovery.
For most shops starting out, scheduled SQL extracts with a daily or hourly cadence cover the analytics use case adequately and can be built with standard tools.
IBM i on IBM Cloud — what it actually looks like
IBM offers IBM i as a managed service on IBM Cloud (formerly Softlayer). You provision a Power Virtual Server (PowerVS) instance, select an IBM i licence edition, choose storage, and get a running IBM i system within hours.
Practical considerations:
- Licensing — IBM i software licences transfer to the cloud instance. The hardware cost is consumption-based. Total cost varies significantly by workload size.
- Connectivity — Direct Link connects your IBM Cloud instance to your on-premises network or other cloud services with low latency. VPN is available for lighter needs.
- Storage — IBM Cloud storage is persistent but separate from compute. Snapshot and backup options are more flexible than traditional tape.
- Management — IBM handles the physical hardware and hypervisor layer. You manage the OS, libraries, and applications exactly as you would on-premises.
- Disaster recovery — Cloud instances make geographically separated DR environments practical. A production system in one region with a DR instance in another, replicated via Db2 Mirror or a CDC tool, provides enterprise-grade resilience at a fraction of the cost of a second physical data centre.
The modernisation conversation to actually have
When leadership asks about modernisation, the right conversation is not “should we leave IBM i” but “what do we want modernisation to achieve?”
Common legitimate goals and their IBM i-compatible answers:
“We want a modern user interface” — build a React or Angular front end that calls IBM i via REST APIs. The business logic stays in RPG. Users get a modern browser experience. This is achievable in months, not years.
“We want better reporting and analytics” — replicate IBM i data to a cloud data warehouse. Build dashboards in Power BI, Tableau, or Looker against the replicated data. IBM i is not touched.
“We want to reduce hardware costs” — evaluate IBM i on IBM Cloud (PowerVS). For many shops, moving to a consumption-based model reduces total cost of ownership, especially for dev and test environments.
“We want to attract developers” — adopt the VS Code + Code for IBM i + Git toolchain. Modern developers working on IBM i using familiar tools in a familiar workflow is a real thing in 2026, not a compromise.
“We want to migrate everything to the cloud” — this is the hardest goal to achieve successfully. The IBM i applications most likely to migrate cleanly are simple CRUD applications with limited business logic. The ones least likely to migrate cleanly are the ones with the most value — the complex, deeply integrated core systems that encode decades of business knowledge.
What staying on IBM i means in 2026
It means running a hybrid architecture. Your transactional core is IBM i. Your user interfaces are modern web applications. Your analytics run in the cloud. Your source code is in Git. Your developers use VS Code. Your APIs are REST. Your integration layer connects everything.
It does not mean running the same green-screen application you ran in 1998. It does not mean resisting change. It means choosing the right tool for each part of the problem — and recognising that for high-volume transactional processing against complex business logic, IBM i is still one of the best tools available.
The shops doing this well are not defending a legacy platform. They are running a modern architecture that happens to have IBM i at its reliable, battle-tested core.
Next post: Connecting IBM i to modern front ends — building REST APIs that your web and mobile applications can actually use.