A wholesale distributor starts an IBM i modernization program with a clear goal: make the system look modern. Within six months, a new web interface replaces the 5250 screens for order entry and inventory lookup. Users are pleased, and executives see progress. Then the next requests arrive. Sales wants a customer API for a partner portal. Finance wants daily data in a cloud analytics platform. Operations wants an AI model to forecast demand. Each request runs into the same obstacle. The data sits in DDS-defined files with cryptic field names, no constraints, and business logic scattered across hundreds of RPG programs that read and write files directly. The new screens changed nothing underneath.
This is a common path. Screen refacing is often the first step because it is visible and relatively quick. But it leaves the foundation untouched. IBM i modernization that starts with the data layer, by converting DDS to SQL DDL and introducing SQL data access, creates the base that APIs, analytics, and AI all depend on. The early progress is less visible, but everything built afterward goes faster.
Why Refacing Comes First So Often
Screen modernization remains a popular starting point for many organizations because the immediate visual improvements deliver tangible benefits:
- Users see immediate change in how they work.
- Executives can demonstrate progress to boards and business units.
- Tools exist that convert or wrap 5250 screens with limited code change.
- Risk appears low, since back-end programs stay the same.
For some organizations, refacing solves a real problem, especially for user training and adoption. But when modernization goals include integration, analytics, and AI, refacing addresses the wrong layer.
What Stays Unchanged Under a New Interface
Simply wrapping an older application in a modern graphical interface leaves the core technical debt entirely intact. Beneath those newly polished screens, legacy IBM i environments typically retain:
- DDS-defined physical files with short, cryptic field names and limited metadata.
- Logical files used as indexes and views, often numerous and overlapping.
- No declared constraints, so relationships between files are enforced only in program logic.
- Record-level access in RPG, where programs read and write files directly.
- Business rules embedded in programs, often duplicated across many of them.
- Tight coupling between screens, logic, and data in monolithic programs.
These characteristics make the data hard to use outside the original applications.
Why APIs, Analytics, and AI Need a Better Data Layer
Modernizing legacy enterprise systems is no longer just about updating applications; it requires fundamentally strengthening how data is structured, accessed, and governed. As organizations push to adopt advanced digital capabilities, legacy database structures often become the primary bottleneck slowing down progress.
APIs
APIs need clear data models and consistent business rules. When logic is scattered across programs, building an API means either duplicating that logic or wrapping old programs in ways that are fragile and hard to test.
Analytics
Analytics platforms need data with clear definitions, relationships, and quality rules. DDS files with cryptic names and no constraints require extensive mapping and cleansing before they can be used.
AI
AI initiatives depend on accessible, well-understood data. Experts have warned that organizations frequently abandon AI projects that remain unsupported by clean, accessible, and AI-ready data. For IBM i shops, AI readiness usually starts with the database.
What DDS-to-DDL Conversion Involves
Converting DDS-defined files to SQL DDL means redefining tables, indexes, and views using SQL, while preserving compatibility with existing programs. A typical approach includes:
- Inventory files: physical files, logical files, and their usage by programs.
- Generate SQL DDL for existing physical files, keeping record formats compatible so existing RPG programs continue to work.
- Add meaningful names through long column names and aliases, while retaining short names for compatibility.
- Define constraints such as primary keys, unique keys, and foreign keys where data supports them.
- Replace logical files with SQL indexes and views where appropriate.
- Add column-level metadata such as labels and descriptions.
- Test thoroughly to confirm that existing programs behave identically.
This work can be done incrementally, file by file, starting with the most important business entities.
Data Quality Work Hidden in the Conversion
Converting file definitions exposes data problems that have lived quietly for years. When teams try to add a primary key, they find duplicate records. When they add a foreign key between orders and customers, they find orders pointing to customers that no longer exist. Date fields stored as numbers contain zeros or impossible values. Numeric fields hold codes that mean different things in different programs.
These discoveries are valuable, even when they slow the project. Every issue found during conversion is one that would otherwise surface later in an API response, an analytics dashboard, or an AI model’s training data. Teams should plan time for profiling and cleansing, agree with business owners on how to resolve each class of problem, and record decisions so they are not revisited. Some constraints may need to start as informational or be added only after cleansing is complete.
Data profiling also helps prioritize. Files with high usage and good quality can be converted quickly. Files with heavy quality problems may need cleansing projects of their own before constraints are enforced.
Performance, Journaling, and Operations
Data modernization touches operations as well as development. Moving to SQL-defined tables can change how the database optimizer handles queries, and some older programs may perform differently. Testing with production-like volumes, reviewing index advice from the database, and monitoring query performance after conversion avoid surprises.
Journaling and replication deserve attention too. Many IBM i environments use journaling for high availability and for feeding data to other systems. Conversion should confirm that journals, replication tools, and backup processes continue to work with the new definitions. For companies planning to stream IBM i data into cloud analytics, well-defined SQL tables with consistent journaling make change data capture simpler and more reliable, which is one more reason to modernize AS400 data before building new pipelines on top of it.
Moving Programs Toward SQL Data Access
Once files are defined in SQL, programs can gradually shift from record-level access to embedded SQL. That brings several benefits:
- Set-based operations that can be more efficient for many workloads.
- Centralized logic through views, triggers, and stored procedures.
- Better use of the database optimizer.
- Easier integration with tools that expect SQL.
Programs do not need to change all at once. New programs can use SQL from the start, and existing programs can be updated as they are modified for other reasons.
IBM Application Modernization Through Separated Layers
Data modernization creates an opportunity to separate concerns:
- Data layer: SQL tables, views, constraints, and stored procedures.
- Business logic layer: modular RPG service programs or other services exposing clear functions.
- Presentation layer: web, mobile, or API interfaces calling business services.
This structure makes IBM application modernization more sustainable. It also means IBM application modernization can proceed one business function at a time, with each new service replacing duplicated logic in older programs. New interfaces, APIs, and integrations can call the same business services, reducing duplication and inconsistency.
AI Tools Speed Up Data Modernization
AI assistants now support IBM i modernization work directly. IBM’s Bob Premium Package for IBM i, announced in July 2026, includes support for DDS-to-DDL conversion and SQL optimization, alongside conversion of fixed-form RPG to free-form and documentation of business logic.
These tools can speed up inventory, analysis, and conversion. Human review remains essential, especially for constraints and business rules, where the right answer depends on how the business actually uses the data.
How Should Organizations Sequence an IBM i Modernization Program?
A data-first modernization sequence starts by assessing current assets and building a strong database foundation before tackling application interfaces. This structured approach prevents technical debt from compounding and ensures subsequent integrations stand on reliable ground.
Phase One: Assess
Inventory applications, files, programs, and dependencies. Identify the business entities most needed for APIs and analytics.
Phase Two: Modernize the Data Layer
Convert priority files to SQL DDL, add names, constraints, and metadata, and replace logical files with SQL indexes and views.
Phase Three: Introduce Services
Build modular service programs or stored procedures for key business functions, using SQL access.
Phase Four: Expose APIs
Publish REST APIs for priority business services.
Phase Five: Connect Analytics and AI
Feed data into analytics platforms through replication or APIs, and build AI use cases on that foundation.
Phase Six: Modernize Interfaces
Replace or reface screens where user benefit is clear, calling the new services.
Screen work can still happen early for high-impact areas, but it should sit on top of the data and service layers rather than replacing them.
How Can Teams Measure Progress in Data Modernization?
Because foundational data work lacks the immediate visual appeal of a new user interface, progress must be tracked through concrete technical and operational metrics. Clear reporting helps executive leadership visualize the tangible value generated by backend improvements.
- Files Converted: Track the volume of legacy files migrated to SQL DDL categorized by business priority.
- Constraints Defined: Monitor the implementation of primary keys, foreign keys, and validation rules across key entities.
- SQL Adoption: Measure the transition rate of legacy programs moving from record-level file operations to modern SQL access.
- Integration Velocity: Compare the delivery time for new integrations and APIs against historical baselines.
Reporting these measures helps executives see the value of foundation work.
Choosing IBM i Modernization Services
When evaluating IBM i modernization services or as400 modernization services, organizations can ask:
- Does the provider start with the data layer, or only with screens?
- How will DDS files be converted while keeping existing programs working?
- How will constraints and metadata be defined and validated?
- What is the plan for moving programs to SQL access?
- How will APIs and analytics be enabled?
- How will AI tools be used, and how will results be reviewed?
Providers that propose only screen refacing may deliver quick wins but leave the harder problems for later.
A Representative Reset
Return to the wholesale distributor. After its screen project, it launches a data modernization phase. The team converts its customer, item, order, and inventory files to SQL DDL, with long names, primary keys, and foreign keys. Logical files are replaced with indexes and views. New service programs expose order and inventory functions through SQL, and REST APIs follow. Data flows to the cloud analytics platform through replication.
The partner portal API launches in weeks instead of months. Finance gets daily analytics data with clear definitions. The demand forecasting model trains on clean, consistent history. The web interface from the first phase now calls the same services, reducing duplicate logic.
IBM i modernization that starts with DDS-to-DDL conversion and SQL data access builds the base every API, analytics, and AI initiative depends on. Refacing screens can come later, on top of a modern data and service layer. IBM i modernization services cover data modernization, RPG refactoring, API enablement, and interface updates. For teams ready to modernize AS400 systems, it is worth asking what sits underneath the next new screen.
