AS400 Migration to Java or .NET: What Happens to Each IBM i Component?
Your IBM I (AS/400) application contains more than RPG or COBOL source code. Its business behavior also depends on CL programs, DDS display files, DB2 physical and logical files, batch jobs, reports, and the way these components work together.
IBM i / AS400
RPG · COBOL · CL · DDS · DB2
Recovered Application Design
Business rules · workflows · data relationships · dependencies
Java
Spring Boot
Java Services
React / Angular
.NET
ASP.NET Core
C# Services
React / Angular
Modernizing the whole IBM i application. Not just its source code.
CORE Migration modernizes IBM i applications—often called AS/400 or iSeries applications—into Java or C#/.NET systems. We recover the existing business rules and application design, then rebuild the components into a modern architecture with browser interfaces, application services, and relational data access.
The goal is to preserve the calculations, validations, workflows, and processing rules your business relies on while giving your team a maintainable system it can develop and support.
The key idea: modernization succeeds when the business behavior carried across RPG, COBOL, CL, DDS, DB2, jobs, reports, and runtime dependencies is preserved together.
What does an AS/400 application become after modernization?
The target design depends on the application and your technology standards. This table shows typical mappings; the detailed behavior must be assessed before choosing an implementation.
| IBM i component | Typical Java implementation | Typical .NET implementation |
|---|---|---|
| RPG and COBOL programs | Java business services and domain classes | C# business services and domain classes |
| Service programs and shared routines | Shared Java modules and service classes | .NET class libraries and shared services |
| CL programs | Batch orchestration, application services, and deployment scripts | Background workers, application services, and deployment scripts |
| DDS display files and subfiles | React or Angular interfaces calling Java APIs | React or Angular interfaces calling ASP.NET Core APIs |
| DDS printer files and spool output | Report generation, PDFs, and managed print delivery | Report generation, PDFs, and managed print delivery |
| DB2 physical files | Relational tables accessed through Java data access | Relational tables accessed through .NET data access |
| DB2 logical files | Indexes, views, and explicit SQL queries | Indexes, views, and explicit SQL queries |
| Multiple file members | Tables, partitions, or explicit member identifiers | Tables, partitions, or explicit member identifiers |
| Data areas | Configuration or state records with controlled access | Configuration or state records with controlled access |
| Data queues | Messaging infrastructure and consumers | Messaging infrastructure and consumers |
| Jobs, job queues, and scheduling | Batch jobs, workers, and schedulers | Batch jobs, workers, and schedulers |
| Commitment control | Defined database transactions and recovery behavior | Defined database transactions and recovery behavior |
| User profiles and object authorities | Identity, application permissions, and database permissions | Identity, application permissions, and database permissions |
A migration succeeds when these components continue to support the correct business outcomes together.
RPG and COBOL migration to Java or C#
RPG and COBOL programs often combine business calculations, database operations, screen handling, and calls to other programs. Modernization separates these responsibilities while preserving the rules behind them.
Business calculations and validations become Java or C# service methods. Shared routines become reusable modules. Database operations move into a defined data access layer. Screen interaction moves into browser workflows connected to APIs.
Program calls also need attention. Parameters, return values, shared state, error handling, indicators, and initialization behavior can affect how a process behaves across multiple calls.
For example, an order-entry program may check customer credit, calculate prices, reserve stock, and update several files. Its modern equivalent must preserve those rules and transaction boundaries across the service and database layers.
- Calculation results
- Decimal precision
- Decision logic
- Parameter behavior
- Record locking
- Business error handling
CL program migration: preserving orchestration and job control
Control Language (CL) programs frequently hold the instructions that make an application operate: choosing files, setting the environment, calling programs, submitting jobs, and handling failures. During modernization, each command is assessed according to its purpose. Business orchestration becomes application or batch logic. Environment setup moves into configuration. Operational tasks move into deployment or scheduling tools.
Common CL Commands
CALL
SBMJOB
OVRDBF
MONMSG
What must be Preserved
- Job sequnce
- File selection
- Parameters
- Completion conditions
- Restart behavior
- Failure Handling
- Fields
- Function Keys
- Subfiles
- Prompts
- Indicators
- Forms
- Actions
- Searchable grids
- Dialogs
- Validation
DDS display files and subfiles: from green screens to web workflows
DDS display files define more than the appearance of a screen. Together with the controlling program, they define field behavior, prompts, indicators, function keys, validations, and navigation. CORE models these interactions as business workflows and rebuilds them as React or Angular interfaces connected to Java or .NET services.
A subfile may become a searchable grid with pagination, selection, sorting, and row actions. Function keys become clearly labeled actions. Lookup windows become search dialogs.
The visual layout can change while the workflow retains its essential behavior. A cancel action must cancel the correct operation. A validation must run at the correct point. An update must save the correct records.
What must be preserved: field rules, selection behavior, permitted actions, navigation, validation timing, and save/cancel behavior.
DB2 physical files: migrating data and record definitions
DB2 for i physical files contain application data, but their definitions and usage also carry information about record formats, keys, field types, and member organization.
When moving to a different database platform, physical files typically become relational tables. The design makes data types, keys, and relationships explicit while accounting for the way existing programs use the records.
Packed and zoned decimal values require exact precision and scale. Character encodings, padded fields, numeric dates, special values, and implied decimal positions must be handled deliberately. Multiple file members need an explicit mapping. Depending on their purpose, they may become separate tables, partitions, or records with a member identifier. Records cannot simply be combined if their member identifies a company, period, or processing context.
What must be preserved: record meaning, member identity, field values, decimal scale, encoding, and business relationships.
- Packed decimal
- Zoned decimal
- Character encoding
- Padded fields
- Numeric dates
- Special values
- Impliefd decimal positions
- Multiple file members
DB2 Logical File
Indexes
Views
SQL Queries
An index alone does not guarantee query output order.
DB2 logical files: preserving keys, filters, joins, and read order
Logical files provide access to data stored in physical files. They can define keyed access, record selection, joins, and alternate access paths.
Modern equivalents may include indexes, views, and SQL queries. The correct choice depends on the logical file definition and how programs access it.
An RPG program using SETLL, READE, READ, or CHAIN relies on particular positioning and retrieval behavior. Replacing those operations with SQL requires explicit selection and ordering rules. An index alone does not guarantee query output order.
Duplicate keys, descending keys, collation, and record locking can also change results if they are overlooked.
What must be preserved: key comparison, filtering, joins, ordering, duplicate handling, and update behavior.
Printer files and spool output: rebuilding reports and print workflows
Printer files define report layouts, while application programs supply the calculations and control when output is produced. Modernization rebuilds both the report content and its delivery. Outputs may become PDFs, downloadable files, managed print jobs, or reporting dashboards, depending on the business requirement. Invoices, statements, and operational reports may still require precise layouts. Control totals, grouping, page breaks, and print distribution remain part of the migration scope.
What must be preserved: totals, grouping, required layout, document content, delivery destinations, and any approval or release steps.
DDS Printer File
Report Definition
PDF / Print / Dashboard
Data areas, data queues, and application messages
These IBM i mechanisms may look similar at first, but they serve different purposes and require different modern equivalents.
Data Areas
Data areas may hold configuration, counters, flags, or shared state. Their replacements need to preserve persistence, scope, and concurrency behavior. A shared counter, for example, needs an atomic update mechanism.
Data Queues
Data queues can coordinate work between jobs. Modern messaging needs equivalent decisions about ordering, consumption, retries, duplicate processing, and recovery.
Application Messages
Application messages have a different role. A message may signal a business error or cause CL logic to take a particular branch. Logging helps diagnose a process, but the business control behavior must be implemented separately.
What must be preserved: state ownership, message meaning, ordering requirements, concurrency, and processing guarantees.
Batch jobs, libraries, and runtime dependencies
An IBM i batch process may rely on job queues, library lists, overrides, temporary objects, and a particular runtime context. In Java, batch work can use Spring Batch or scheduled workers. In .NET, it can use background services and scheduling tools. The implementation is selected around the required processing and operational controls.
Library lists and overrides deserve particular attention because they can determine which object or file a program resolves at runtime. Temporary data in QTEMP also needs an equivalent scope and cleanup strategy. A migrated overnight process must finish within its batch window, produce the expected outputs, and recover correctly after a failure.
What must be preserved: dependencies, runtime object resolution, temporary data scope, scheduling, restart points, and throughput.
Job Queue
Library List
Overrides
QTEMP / Temporary Objects
Processing
Job Queue
Commitment control, journaling, and security
Commitment Control
Commitment control defines which related changes succeed or roll back together. Those boundaries must be preserved in the target application and database.
Journaling
Journaling may support recovery, audit, replication, or incremental extraction. Each use needs an appropriate replacement. Database recovery logs, audit records, and change data capture serve different purposes.
Security
Security also requires a deliberate mapping. User profiles, object authorities, and adopted authority do not automatically translate into web application roles. The modern system needs identity controls, business permissions, service permissions, and database access rules.
What must be preserved: transaction consistency, rollback, recovery requirements, audit evidence, and authorized access.
Choosing Java or .NET for IBM i modernization
Both platforms can support modernized IBM i applications. The choice depends on your development team, integration requirements, operating environment, and existing standards.
| Architecture layer | Java option | .NET option |
|---|---|---|
| Business logic | Java services | C# services |
| APIs | Spring Boot | ASP.NET Core |
| Batch processing | Spring Batch or scheduled workers | Background services and schedulers |
| Data access | MyBatis or another suitable Java data access layer | Dapper or Entity Framework Core where appropriate |
| Browser interface | React or Angular | React or Angular |
| Database | Selected for application requirements and client standards | Selected for application requirements and client standards |
Application modernization and database migration are separate decisions. A phased approach may retain DB2 for i while introducing new services and interfaces. A full platform migration may move data to SQL Server, Oracle, or another suitable relational database.
How CORE approaches IBM i modernization
Recover the application design
Inventory programs, files, screens, reports, CL procedures, and operational dependencies. Identify where the business rules live and how components interact.
Define the component mappings
Agree how each component will be represented in Java or .NET, including data structures, service boundaries, browser workflows, batch processing, and security.
Generate and refine the modern implementation
CORE uses repository-driven automation to support consistent generation from recovered design and defined transformation rules. Engineering work addresses platform behavior, integration requirements, and exceptions.
Compare business behavior
Run representative inputs through the legacy and modern implementations. Compare calculations, database updates, reports, and workflow outcomes—not just whether the generated code compiles.
Rehearse data migration and cutover
Validate data conversion, processing windows, operational procedures, and the transition plan before production deployment.
What must be preserved: transaction consistency, rollback, recovery requirements, audit evidence, and authorized access.
How do you verify that the modern application behaves correctly?
Testing should connect each migrated component to a business outcome.
Financial calculations
Compare amounts, precision, and rounding.
File access
Compare the selected records and their processing order.
Batch Processing
Compare counts, totals, updates, and restart behavior.
Browser workflows
Verify permissions, validation, navigation, and saved results.
Data migration checks
Include record counts, member mappings, control totals, and field-level comparisons for representative records.
Operational tests
Confirm performance under realistic volumes and recovery after interrupted processing. Differences should be explained and accepted before cutover.
The goal is not simply to prove that the new code runs. It is to prove that the business behavior still produces the correct outcomes.
Frequently asked questions
Can RPG applications be migrated to Java or C#?
Yes. RPG business logic can be rebuilt in Java or C#. The scope also includes the file access, screens, program calls, and runtime dependencies that influence the application's behavior.
What happens to CL programs during AS400 migration?
Their responsibilities move into application logic, batch orchestration, configuration, scheduling, and operational scripts. Each CL procedure must be assessed for the behavior it controls.
Can DDS display files become React or Angular screens?
Yes. Display files and their controlling programs provide the basis for rebuilding fields, validations, navigation, subfile actions, and business workflows in a browser interface.
Does IBM i modernization require replacing DB2 for i?
No. New Java or .NET applications can retain DB2 for i where that fits the architecture. Moving the database is a separate scope decision.
What happens to physical and logical files?
Physical files typically map to relational tables when moving databases. Logical file behavior maps to suitable indexes, views, and queries. Member selection and keyed processing must remain explicit.
Can an AS400 application be modernized in stages?
Yes, where dependencies allow it. A phased approach needs defined integration boundaries, ownership of data updates, and a plan for operating the legacy and modern components together.
Modernize your IBM i application with CORE Migration
Your RPG, COBOL, CL, DDS, and DB2 components represent years of business knowledge. CORE helps recover that knowledge and carry it into a Java or .NET architecture your team can maintain.