Top Rated AS/400 (IBM i) to Cloud Migration Services

The IBM i Dilemma

The AS/400 (IBM i) is legendary for its stability and “it just works” nature. This is also its curse. The tight integration between the OS, the Database (Db2 for i), and the Language (RPG) makes it incredibly sticky.

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.

3. Replace with COTS

For generic ERP functions, replace with SAP/Oracle Cloud. Only viable if customization is minimal.

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)

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.

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).

Break-Even Analysis:

• Median Investment: $1.5M
• Annual Savings: $400K-$600K (Hardware + Licensing + Staffing)
• Break-Even: 3-4 years

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)

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

Architecture Transformation

graph TD
    subgraph "Legacy AS/400"
        A[5250 Terminal] --> B[Interactive Jobs]
        C["Batch Jobs (CL)"] --> D[RPG Programs]
        B --> D
        D --> E["(Db2 for i)"]
    end

    subgraph "Modern Cloud"
        F[Web Browser] --> G[API Gateway]
        H["Job Scheduler (Airflow)"] --> I["Microservices (Java/C#)"]
        G --> I
        I --> J["(PostgreSQL / SQL Server)"]
    end

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style F fill:#bbf,stroke:#333,stroke-width:2px

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.

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.

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: We 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. We use specialized ETL tools that handle this byte-level conversion to ensure financial accuracy.

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.