The hard part of an AS400 database migration is not moving the data. Db2 for i is a real relational database, the data is intact, and copying rows is a solved problem. The hard part is that your data model was defined in DDS decades ago, and somewhere between 50 and 500 programs have opinions about exactly how those files look. Change the file, and every one of those opinions becomes a potential production incident.
That is why database migration on IBM i is a dependency problem wearing a data costume. Treat it as a data problem and you will do the easy 90 percent quickly, then spend a year on the 10 percent you could not see.
Why DDS-Defined Files Resist Change
DDS physical and logical files were built for a world where the program and the file were designed together. Record formats are compiled into the programs that use them. Field definitions echo through display files and printer files. Logical files encode access paths that application logic quietly depends on.
The result is a data layer that works remarkably well and changes remarkably badly. A field widened from 7 digits to 9 is a one-line change in the file definition and an unknown number of changes everywhere else: every program that declares the record format, every internally described workfile that copies it, every report that prints it into a fixed column. “Unknown number” is the phrase that should worry you. Migrations do not fail on the changes you scoped. They fail on the ones you did not know existed.
Map Every Program That Touches a File, Before You Touch the File
The prerequisite for a safe AS400 database migration is a complete answer to one question, asked per file: what touches this, and how?
This is exactly what AS/Forward’s dependency mapping was built for. It ingests your source through a proprietary ingestion layer that reads six RPG dialects plus the DDS around them, then builds an interconnection graph of programs, files, and copy members. The migration view scopes impact at the field and object level: pick the file you intend to change, and you see every program, logical file, display file, and report in its blast radius.
With that map, “modernize the customer master” stops being a leap of faith. It becomes a named list: these 34 programs read it, these 6 update it, these 2 print jobs format it, and these 3 programs reference a field nobody has populated since 2011.
A Staged Path That Keeps Production Running
Shops that get this right almost never do it as one cutover. The pattern that works is staged:
- Map first. Build the dependency graph for the files in scope, and let it surface what the team’s memory missed.
- Retire before you migrate. Dead programs and orphaned logical files come off the list. There is no reason to carefully preserve compatibility for code nothing calls.
- Move definitions, keep behavior. DDS to SQL DDL conversion works best file by file, with surrogate logical files preserving the access paths existing programs expect while new development reads the SQL definitions.
- Convert consumers in dependency order. The map tells you which programs can move independently and which travel in clusters because they share record formats.
- Verify with the graph, not with hope. After each stage, the same dependency map that scoped the work confirms nothing outside the stage was touched.
None of this is exotic. What makes it rare is step one. Most teams cannot build the complete map by hand, so they skip to step three and meet their unknowns during cutover weekend.
What This Looks Like With Real Tooling
Because AS/Forward generates a plain-English description of each program alongside its dependency edges, the migration team gets more than a list of affected objects. They get what each affected program actually does with the file: reads it for validation, updates it in batch, joins it for a report. That is the context that turns an impact list into a work plan.
Everything runs air-gapped inside your own infrastructure. Your database definitions and your source code stay on your network for the entire analysis, which for the banks and insurers running these systems is not a preference. It is a requirement.
Start With the File You Are Most Afraid Of
There is a version of this project that starts small: pick the file your team is most nervous about, map its true blast radius, and use that single map to decide whether the wider migration is a quarter of work or a year. Golden Path Digital can run an IBM i modernization assessment scoped to your database layer and show you the map before you commit to anything. Call 501-232-7188 and name the file.