AS/400 to Cloud Migration Services

Section 02

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.

Section 03

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.

---

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 04

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 05

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 06

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 07

Architecture Transformation

---

Section 08

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 09

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 10

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 11

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.