AS400 Migration to Java or .NET
AS400 migration to Java or .NET is one of the most effective ways to modernize legacy business applications while preserving critical business logic and improving long-term maintainability. IBM i (commonly referred to as AS/400) platforms have earned a reputation for stability, predictable batch processing, and durable business logic. Many organizations still run critical order management, finance, manufacturing, and claims systems on IBM i because the systems work and the risk of change feels high.
- Preserve decades of business logic
- Reduce modernization risk
- Modern Java and .NET architectures
- Incremental migration strategies
Why AS/400 Modernization Is More Complex Than It Looks
Modernizing an IBM i application isn’t simply about rewriting code—it’s about preserving decades of business knowledge while adapting to modern technologies and development practices.
The Modernization Challenge
The challenge is that the surrounding ecosystem has shifted. Integration expectations are now API-first, UI expectations are browser and mobile, and operational expectations include CI/CD, automated testing, observability, and rapid change. Meanwhile, IBM i estates often rely on tightly coupled application logic, unique data structures, and platform-specific artifacts that make modernization appear more complex than it needs to be.
Legacy Strengths
- Stable business logic
- Predictable processing
- Proven workflows
- Platform specific data
Expectations
- API-first systems
- Cloud deployment
- CI/CD pipelines
- Automated testing
- Observability
CORE'S Engineering Philosophy
At Core, we approach AS400 migration to Java or .NET as a design preservation and forward engineering exercise. We capture the legacy intent, separate concerns cleanly, and rebuild the system into a modern stack, typically Java (Spring Boot, MyBatis, Angular/React) or .NET (C#/.NET 8, Dapper/EF where appropriate, React/Angular). The end state is a cloud-ready, supportable application with a modern data platform and a testable codebase.
CORE Modernization Principles
- Preserve business intent
- Seperate business concerns
- Rebuild using modern frameworks
- Deliver cloud ready applications
- Improve maintainability and reduce technical debt
What makes AS/400 migration different
AS400 migration to Java or .NET is not only about converting RPG or COBOL syntax. It is about migrating a set of platform-specific concepts that are often intertwined:
Display & Printer Files
DDS based UI and reporting artifacts
DB2 Physical & Logical Files
Including multi-member files.
Data Areas & Queues
Messaging and inter-process coordination.
Commitment Control
Transaction and journaling semantics.
Jobs & Subsystems
Batch, interactive, spooling and scheduling.
Security Model
Profiles, authorities
and adopted authority.
A successful migration preserves the business rules and behavior while translating these concepts into modern equivalents such as REST services, message queues, schedulers, relational schemas, and role-based security.
Typical drivers for modernizing IBM i
Organizations usually modernize for one or more of these reasons:
Skills Risk
Diminishing availability of RPG and CL developers
API Integration
expose functionality via APIs and integrate with SaaS platforms
User Experience
Green-screen UX limitations and training overhead
DevOps & Delivery
Difficulty scaling change delivery without automated builds and tests
Reporting & Analytics
Data access constraints, reporting demands, and analytics modernization
Infrastructure Strategy
Cloud, hybrid, standardization on Windows or Linux platforms.
Core’s migration philosophy
Every modernization project follows three core engineering principles that reduce risk while preserving business value.
01
Preserve Design & Intent
Capture business rules, validations, and workflow that matter.
02
Separate Concerns
Isolate data access, business logic, and presentation, then rebuild each cleanly.
03
Automate Delivery
Repository-driven automation reduces risk and improves consistency.
This is especially important for IBM i where logic, data structure, and UI artifacts are often co-dependent.
Target architectures: Java and .NET
CORE modernizes IBM i applications using proven Java or .NET architectures, depending on client standards, existing technology investments, and long-term business goals.
- Spring Boot APIs and services
- Spring Batch for batch processing equivalents
- MyBatis for deterministic SQL mapping
- Angular or React front end
- DB2 LUW, Oracle, or SQL Server as the RDBMS
The technologies may differ, but every migration follows the same engineering principles: preserve business intent, modernize architecture, and deliver a maintainable, cloud-ready application.
High-level migration approach
A typical end-to-end modernization workflow that transforms IBM i applications into cloud-ready Java or .NET architectures while preserving business intent.
Migrating AS/400 data structures and data formats
CORE modernizes IBM data structures by preserving business semantics while mapping legacy constructs to modern relational architectures and application frameworks.
01
DB2 for Physical & Logical Files
IBM i “files” often blend storage and access strategy:
- Physical files map closely to tables, but may include member concepts, record formats, and legacy constraints not explicitly declared.
- Logical files can represent indexes, filtered views, joins, alternate keys, and access paths used directly by programs.
Migration strategy:
- Convert physical files to relational tables with explicit keys, constraints, and normalized types.
- Convert logical files to a combination of indexes, views, and query patterns.
- Identify program dependencies that rely on access-path behavior (read next, keyed reads, setll, reader) and preserve semantics in the DAO layer.
KEY MIGRATION CONSIDERATIONS
- Primary key inference where legacy designs rely on alternate keys
- Packed decimal and zoned decimal conversions to decimal/numeric types
- Date and time fields stored as numeric or character formats
- Record format changes over time and backward compatibility
- Referential integrity that exists in code rather than in the database
02
DDS Artifacts (Display Files & Printer Files)
DDS artifacts usually represent two modernization opportunities:
- User interface modernization: translate green-screen workflows into a modern web UI.
- Reporting modernization: translate spool and printer files into modern report generation.
APPROACH
- Model screens as workflows: inputs, validations, prompts, function keys, and navigation.
- Rebuild the UI as React/Angular pages that call APIs.
- Rebuild printed output as PDF templates, server-side report generation, or BI outputs.
03
DDS artifacts (Display files and Printer files
IBM i applications frequently use:
- Packed decimal (COMP-3 in COBOL terms)
- Zoned decimal
- Overpunch sign representations
- Character numeric fields with implied decimals
OUR APPROACH
- Preserve precision and scale exactly.
- Avoid floating point for money and high precision values.
- Use explicit conversion utilities and unit tests against real extracts.
04
Data areas, Data Queues, and Message Handling
Data areas and queues are frequently used for:
- Parameter passing between jobs
- Lightweight state storage
- Batch coordination and integration
MODERN EQUIVALENTS
Database tables for durable state
Redis or distributed cache for ephemeral state (where appropriate)
Message queues (Azure Service Bus, RabbitMQ, Kafka) for asynchronous processing
Structured Logging and correlation IDs replacing message queues used as diagnostics.
05
Journaling and Commitment Control
IBM i journaling is often used for:
- Recovery
- Auditing
- Synchronization patterns
- Incremental extracts
RDBMS transaction semantics
Change tracking (where required)
Audit columns and audit tables
CDC tooling when needed
We ensure transactional consistency, traceability, and recoverability in the modern environment.
06
Program Migration: RPG, COBOL, and CL
The goal is to preserve business rules while improving maintainability:
- Extract program structure, files used, and call chains.
- Preserve the decision logic, validations, and computations.
- Rebuild into service methods with explicit inputs and outputs.
Every migration is driven by the same principle: preserve business intent, modernize architecture, and deliver a secure, reliable, and maintainable solution.
CL command language and job control
CL often encodes:
- Batch orchestration
- Environment setup
- File overrides
- Subsystem job behavior and scheduling
We translate this into modern orchestration:
- Scheduler jobs (Quartz, Hangfire, Windows Task Scheduler, Kubernetes CronJobs)
- Parameterized batch runners
- Environment configuration and secrets management
- Repeatable deployment pipelines
There are several proven patterns, and selection depends on volume, downtime tolerance, and integration complexity.
OPTION A
One time extract and load (small to medium sized systems)
- Extract DB2 for i data to flat files or staging tables
- Transform and load into the target RDBMS
- Validate with reconciliation and functional tests
OPTION B
Parallel run with incremental (small to medium sized systems)
- Extract DB2 for i data to flat files or staging tables
- Transform and load into the target RDBMS
- Validate with reconciliation and functional tests
OPTION C
One time extract and load (small to medium sized systems)
- Extract DB2 for i data to flat files or staging tables
- Transform and load into the target RDBMS
- Validate with reconciliation and functional tests
Testing and validation that reduces risk
IBM i migrations fail when testing is treated as an afterthought. We build validation into the migration lifecycle:
Unit Tests
For conversion utilities (packed decimal, date formats, keyed reads)
Golden Data Tests
using known input and expected outputs
Batch Reconciliation
Comparing totals, counts, and key financial metrics
UI Workflow Tests
Replicating function-key behavior and navigation paths
Performance benchmarking
for high-throughput batch windows
A critical technique is comparing the legacy and modern system against the same input datasets, then proving equivalence in outputs and side effects.
Security and operational modernization
A modern solution must match or exceed IBM i operational maturity:
Role Based Security
Mapped from profiles and authorities
Centralized Identity
Azure AD, Okta, etc.
Auditing
Of key business events and data changes
CI/CD Pipelines
Automated builds, tests, and repeatable deployments.
Observability
logs, metrics, traces, and alerting
A practical migration roadmap
Here is a typical sequence for an IBM i modernization project:
This roadmap supports iterative delivery.
You can modernize one functional area at a time rather than waiting for a single big release.
What you get at the end
A successful AS400 migration to Java or .NET produces:
Modern Java or .NET Code
Clean separation of concerns
Relational Data Platform
With explicit schema, constraints, and indexes
API Endpoints
For integration and future extensibility
Modern UI
Replacing green-screen workflows
CI/CD Pipelines
logs, metrics, traces, and alerting
Testing Framework
Proves functional equivalence and supports change
How Core Helps
Core brings an automation-first approach that is built for legacy complexity. We preserve your existing design, extract and model the rules, and forward engineer into a modern stack with less risk than manual rewrites. If your IBM i estate includes RPG, COBOL, CL orchestration, DDS screens, and DB2 for i data structures, we can help you modernize to Java or .NET in a controlled, auditable way.