AS/400 to Cloud Migration Services

Section 02

AS/400 Cloud Target Options: IaaS Hosting, Rehost, Refactor, or Replace

"AS/400 to cloud" gets asked as if it's one migration. It's actually four different targets, and searches for "AS/400 cloud hosting," "AS/400 IaaS," or "AS/400 in cloud" usually mean something narrower than the automated-conversion projects covered later in this guide.

1. IBM i as cloud IaaS — keep RPG, keep Db2 for i, exit the data center only. IBM's own Power Virtual Server runs actual IBM i workloads on IBM Cloud as infrastructure-as-a-service: no code changes, no data conversion, same RPG, same green screens, same Db2 for i. Skytap on Azure does the equivalent on Microsoft's cloud, running native IBM Power hardware (IBM i, AIX, and Linux on Power) alongside x86 workloads. Both are lift-and-shift of the platform, not the application — you exit a physical data center and move to pay-as-you-go infrastructure in weeks, but the RPG talent dependency and the Single Level Store architecture travel with you unchanged.

2. Emulation-based rehost off Power hardware entirely (LzLabs, Infinite i — see the FAQ below). You exit IBM Power hardware and its licensing model, but the compiled RPG objects and the talent requirement come along for the ride.

3. Refactor to Java or C# (see Technical Deep Dive and the roadmap below). This is the only option that actually retires the RPG dependency, at a cost of 2-4 years and materially higher spend.

4. Replace with a packaged product (SAP, Oracle Cloud — see Phase 1 below) for generic, uncustomized ERP functions.

Choosing between them: if the trigger is a data-center exit or a lease expiration and RPG staffing is stable, option 1 is the fastest, lowest-risk path and doesn't touch a line of code. If the trigger is Power hardware cost specifically but you still need RPG flexibility, option 2 gets you off the hardware without a rewrite. If the trigger is the RPG talent shortage itself, only options 3 or 4 actually solve it — options 1 and 2 buy time, they don't remove the dependency.

Section 03

Technical Deep Dive

1. The "Single Level Store" Problem

IBM i treats all storage (RAM and Disk) as one flat address space. RPG programs rely on this for performance.

• Migration Impact: Moving to x86 (where RAM and Disk are separate) often kills performance for I/O heavy jobs.
• Solution: You must refactor "chatty" I/O logic into set-based SQL operations before migrating.

2. RPG Free Format vs. Legacy Columnar

If your code is still in fixed-column RPG III or IV, it's unreadable to modern devs.

• Step 1: Convert to Fully Free RPG. This looks like Java/C# and allows younger devs to understand the logic.
• Step 2: Extract business rules into services.

3. The UI Layer: 5250 to Web

Don't just screen-scrape.

• Bad: HTML rendering of the green screen (function keys and all).
• Good: Identify "Workflows" (e.g., "Create Order") and build new React/Angular UIs that call the backend logic via REST APIs. Tools like Profound Logic or Fresche can help bridge this gap. Expect 60-80% automation, with 20-40% manual cleanup.

4. What Breaks in the Db2 for i to Cloud Data Move

Db2 for i is not "just a database." Most AS/400 shops enforce referential integrity and validation inside RPG program logic rather than as database constraints, so the schema alone won't reveal the real business rules. Two more issues surface repeatedly once teams start moving the data itself:

• Journaling dependencies. Change-data-capture tools rely on Db2 for i's remote journal feature to stream changes off-box in real time. If journal receivers aren't sized and rolled over correctly, replication gaps appear silently — validate the CDC pipeline against journal receiver management, not just connectivity.
• Collation and encoding drift. Db2 for i is EBCDIC-based; converting to an ASCII/UTF-8 target changes sort order and case-comparison behavior for any field the application relies on for ordering or matching, even after the byte-level EBCDIC-to-ASCII conversion itself is technically correct.

Both are separate from — and in addition to — the packed-decimal precision and multi-member file issues covered in the migration roadmap and FAQ below.

Section 04

The Real Cost

The biggest cost isn't the migration itself - it's the business disruption. AS/400 systems often run mission-critical operations (manufacturing, distribution). Downtime is not an option.

The RPG Talent Math

Frame the decision as a cost comparison, not a technology debate. Status quo costs $200K-$600K/year in IBM Power hardware and maintenance, with hardware renewals averaging $400K every five years — and it only gets more expensive as the installed base shrinks. Against that: a median migration investment of $1.5M paying back in 24-42 months (see the payback analysis below). The math changes entirely once staffing, not hardware, is the actual constraint: a 6-12 month hiring timeline for a departing RPG developer turns "we'll modernize eventually" into "we have no one who can touch this system in six months." At that point the relevant comparison isn't migration cost versus hardware cost — it's migration cost versus the cost of the system becoming unmaintainable.

---

How to Choose an AS/400 Migration Partner

If you want to modernize ON the platform: Fresche. They specialize in transforming green screens to web UIs and converting RPG to free-format while staying on IBM i.

If you need a managed exit to Azure/AWS: Kyndryl. As a spin-off from IBM, they have deep infrastructure expertise to manage the transition.

If you have a massive custom ERP: Infosys or Capgemini. They have the scale to handle millions of lines of RPG code and complex data migration.

If you need business process re-engineering: Cognizant. They focus on the functional transformation, ensuring you don't just "lift and shift" bad processes.

Red flags:

• Vendors who promise "100% automated conversion" to Java without a POC
• No strategy for "Single Level Store" performance issues on x86
• Ignoring the "Integrated Database" (Db2 for i) coupling
• Lack of specific experience with your RPG version (RPG III vs IV vs ILE)

---

Section 05

When to Hire AS/400 Migration Services

1. Talent Extinction Event

Your youngest RPG developer is 62. You have zero internal documentation. The "Bus Factor" is 1.

Trigger: Key developer retirement announcement; inability to hire replacement.

2. Hardware Support Costs

IBM maintenance fees for older Power Systems are increasing. You are paying a premium for legacy hardware support.

Trigger: Hardware refresh quote >$500K; CFO demands OpEx model.

3. Digital Agility Blockers

The business needs real-time API integration with a mobile app or e-commerce site. The AS/400 team says "it will take 6 months" to build one API.

Trigger: Lost revenue due to inability to integrate with modern SaaS tools.

4. Data Silos

Your core business data is locked in Db2 for i. You can't run modern analytics (PowerBI, Tableau) without complex ETL that slows down the system.

Trigger: CEO demands real-time dashboard; IT cannot deliver.

5. Merger & Acquisition

Your company bought a competitor running SAP. You need to consolidate systems.

Trigger: M&A integration deadline; need to retire the acquired AS/400.

---

Section 06

Total Cost of Ownership: AS/400 vs Cloud

Hidden Costs NOT Included:

• Data Cleansing: Decades of "bad data" allowed by RPG logic but rejected by strict SQL constraints.
• Performance Tuning: Tuning SQL on x86 to match the I/O performance of Single Level Store.
• Training: Retraining RPG devs to become Java/C# devs (or hiring new ones).

Payback Analysis:

• Median Investment: $1.5M
• Annual Savings: $400K-$600K (Hardware + Licensing + Staffing)
• Typical payback (ROI): 24–42 months

---

Section 07

AS/400 to Cloud Migration Roadmap

Phase 1: Discovery & Disposition (Months 1-3)

Activities:

• Catalog all libraries, files, and programs
• Map dependencies (CL calling RPG calling CL)
• Identify "Dead Code" (often 40% of the system)
• Select strategy: Rehost (Emulation), Refactor (Rewrite), or Replace (COTS)

On the Replace (COTS) option: For generic ERP functions (accounting, HR, standard distribution), replacing the AS/400 with a packaged product such as SAP or Oracle Cloud can beat a rewrite on cost. It is only viable where customization is minimal — heavily customized "secret sauce" business logic rarely maps cleanly onto a packaged product and tends to generate costly "gap-fit" work.

Deliverables:

• Application Inventory
• Dependency Map
• Migration Strategy Document

---

Phase 2: Database Migration (Months 4-6)

Activities:

• Extract DDL from Db2 for i
• Convert to Target Schema (PostgreSQL / SQL Server)
• Handle "Multi-Member Files" (a unique AS/400 concept)
• Build ETL pipelines for data sync

Risks:

• EBCDIC to ASCII conversion issues
• Packed Decimal precision loss

Deliverables:

• Target Database Schema
• Data Migration Scripts
• Data Validation Report

---

Phase 3: Code Conversion & UI (Months 7-18)

Activities:

• Automated conversion of RPG LE/ILE to Java/C#
• Rewrite CL scripts to Python/Shell
• Build Web UI (React/Angular) to replace 5250 screens
• Expose business logic as REST APIs

Deliverables:

• Modern Codebase
• Web Application
• API Documentation (Swagger)

---

Phase 4: Testing & Cutover (Months 19-24)

Activities:

• Parallel Run: Compare AS/400 output with Cloud output
• Performance Tuning (Index creation, Query optimization)
• User Training
• Go-Live (Big Bang or Phased by Module)

Deliverables:

• Signed-off UAT
• Production System
• Decommissioned AS/400

---

Section 08

Architecture Transformation

---

Section 09

Post-Migration: Best Practices

Months 1-3: Stabilization

• Performance Monitoring: Watch for slow queries. The "Single Level Store" masked a lot of bad design. You will need to add indexes.
• User Support: "Green Screen" users are fast. Web users are slower initially. Provide keyboard shortcuts.

Months 4-6: Innovation

• DevOps: Implement CI/CD pipelines. You can now deploy daily instead of monthly.
• Analytics: Connect your new SQL database to PowerBI/Tableau for real-time insights.

---

Section 10

Expanded FAQs

Can we just use an emulator on the cloud?

Answer: Yes, tools like Infinite i or LzLabs allow you to run compiled RPG objects on x86 Linux. This is a "Rehost" strategy. It gets you off the hardware quickly but doesn't solve the talent issue (you still need RPG devs) or the monolithic architecture. It's a good intermediate step.

Should we emulate (replatform) or refactor?

Answer: Emulation is faster — typically 6-12 months — and lower risk, but it retains the existing technical debt and RPG dependency. Refactoring to Java or C# takes longer (2-4 years) but enables genuine cloud-native agility. A common pattern is to emulate first to exit the hardware, then refactor incrementally once the immediate hardware and support pressure is relieved.

What about "Multi-Member Files"?

Answer: This is an AS/400 specific concept where one physical file has multiple logical members. SQL databases don't support this. Solution: Teams typically migrate each member to a separate table, or add a "Member_ID" column to a single table and partition by it.

How do we handle "Packed Decimal" data?

Answer: AS/400 uses EBCDIC and Packed Decimal formats heavily. During migration to ASCII and standard SQL types (NUMERIC/DECIMAL), precision can be lost. Specialists use ETL tools that handle this byte-level conversion to preserve financial accuracy.

How do we migrate the data without downtime?

Answer: Change-data-capture (CDC) tools such as Qlik Replicate or AWS DMS can sync Db2 for i data to the target database in real time, which supports a near-zero-downtime cutover. The EBCDIC-to-ASCII and packed-decimal conversion still has to be validated byte-for-byte during the sync, so the CDC pipeline is paired with the ETL validation described above.

Is it better to rewrite in Java or C#?

Answer: Both are fine. Java is often preferred because the syntax is closer to modern RPG (Free Format) and runs well on Linux. C# is preferred if you are moving to Azure and want tight integration with the Microsoft ecosystem.

Why not just replace with SAP/Oracle?

Answer: If your AS/400 runs standard processes (Accounting, HR), yes, replace it. But most AS/400s run highly customized "Secret Sauce" business logic that gives you a competitive advantage. Replacing that with a generic ERP often leads to "Gap Fit" nightmares and loss of agility.

---

Section 11

Risk Factors

Integrated Database (Db2 for i)

On AS400, the database and OS are one. RPG code relies on this tight integration (Single Level Store). Decoupling the logic from the database is the hardest technical hurdle.

Proprietary CL Commands

Control Language (CL) scripts handle job orchestration. There is no direct equivalent in Cloud. These often need to be rewritten as Shell scripts, Python, or Ansible playbooks.

Screen Scraping Trap

Many 'modernization' tools just put a web skin on the 5250 green screen. This adds latency and fragility without solving the underlying talent or maintenance issues.

---

Section 12

Feasibility Analysis

Ideal candidates

• RPG developers are retiring with no backfill
• Hardware support costs are skyrocketing
• Business demands mobile/web access to green screens

Break-even cost: $300k Talent risk: Extreme. RPG talent is arguably scarcer than COBOL.