You sit in a status meeting during the fourteenth month of a project sold as a nine-month delivery. A change order waits on the table for a signature.
Nobody in the room can tell you exactly how many programs are left to migrate. This is the exact moment a technology director starts searching for reasons why legacy modernization projects fail on IBM i systems. The sales process promised an automated conversion of every RPG program in your production library. The reality looks like a stalled migration with an expanding budget.
The underlying cause of this failure usually begins before the vendor wrote the contract. The project relied on assumptions about the source code. Those assumptions proved false when the new system tried to run. We see five specific breakdowns that stall a migration. Each breakdown traces back to a gap between what people thought the code did and what the system actually executes.
The first reason why legacy modernization projects fail is the raw program count estimate
A modernization vendor often asks for a simple inventory of your production libraries. Your team runs a system command and exports a spreadsheet. That file contains a row for every program object. The vendor multiplies that count by a conversion rate and hands back a project estimate. This approach assumes every object in the library requires migration. It ignores the dependencies between programs. It obscures the difference in complexity between a simple utility and a core business process.
You cannot evaluate the complexity of a program from a flat list. One program might perform a simple database read to check a zip code. Another program might hold four thousand lines of billing logic. A flat estimate treats both programs as equal tasks. When the migration team opens the large program in month three, they realize the work will take four times longer than planned. The flat count also hides the true boundaries of your business applications. You cannot accurately price a migration without a dependency graph that connects the user interface to the business logic and the database files. You need to know which objects actually interact. An estimate built on a flat list invites a schedule overrun. The true scope of work remains invisible until the project stalls.
The migration tool converted thousands of lines of dead code
Most IBM i environments hold decades of accumulated history. Programs written in the 1990s still compile and run today. The stability of the operating system means developers rarely delete old objects. A business process changes, a new program replaces an old one, and the original code stays in the library. When a project scopes the entire library for conversion, the migration team spends months converting dead code.
Dead code consumes budget at the same rate as active production logic. The automated tools parse the old syntax. They apply the conversion rules. They generate thousands of lines of modern code. Human developers review the output. Testing teams build test cases for logic that the business stopped using twenty years ago. The effort burns through the project schedule. A successful project requires an exact list of programs that nothing calls. You must filter out the dead code before you authorize a migration. Migrating abandoned programs drives cost overruns. This wasted effort shows exactly why legacy modernization projects fail. IBM i 7.4 reaches IBM end of support on 30 September 2026. This hard deadline pushes companies to rush their migrations. They grab entire libraries and blindly convert everything inside them.
An unresolved copy member breaks the nightly batch job
RPG developers use copy members to share code across multiple programs. Copy members pull source from other libraries into a program at compile time. The developer maintains the logic in one single file. The compiler inserts that logic wherever it is needed. This practice creates hidden dependencies across your system. The migration tool reads the main program file during the conversion process. If the reading tool cannot locate the copy member, it generates incomplete target code.
This failure often remains hidden until the testing phase. A migrated batch job runs in the new environment and crashes at two in the morning. The investigation reveals a missing routine. That routine originally lived in a separate utility library. An unresolved copy member is one the reading tool could not find. The modernization vendor must manually trace the missing logic. They write a custom patch. They restart the testing cycle. A proper analysis flags unresolved copy members as warnings before the project begins. You must identify every external reference before you attempt a conversion. Hidden dependencies break production schedules. Finding those dependencies early keeps the project moving forward.
The developer who knew the run sequence retired mid-project
IBM i applications often rely on complex execution sequences. These sequences exist entirely in the minds of senior developers. A nightly process might involve fifty different programs. These programs call each other in a specific order based on business rules. Some of these programs use runtime-built call targets. The call target gets assembled from a parameter at runtime. These dynamic calls do not appear in any static cross-reference. You cannot see them using the standard DSPPGMREF command. DSPPGMREF reports which files a program references at the file level. It captures references at compile time.
When the developer who maintains this sequence retires, the unwritten knowledge disappears. The migration team attempts to recreate the batch process in the new environment. The process fails because a dynamic call triggered a program out of order. The team spends weeks reading job logs. They attempt to rebuild the execution sequence by trial and error. The loss of institutional knowledge derails the timeline. You must capture plain-English descriptions of how these programs interact while your senior staff is still available. The documentation must exist before the retirement party. Losing the person who knows the run order is a common reason why legacy modernization projects fail.
The source code no longer matches the running object
A compiled program running in production does not always match the source code file stored in the development library. A developer might compile a quick fix into production. They might forget to save the modified source code. Another developer might restore an older version of the source file over the updated version. Over several years, the source libraries drift away from the running objects. The text file you can read stops matching the instructions the machine executes. The source that runs in production becomes disconnected from the source that gets read.
A modernization tool reads the source code text. It analyzes the developer instructions. If the tool reads outdated source code, it generates a modernized application that lacks critical bug fixes. The business users test the new system. They report that the application behaves incorrectly. The modernization team must compare the behavior of the new system against the old system. They identify the discrepancies. They manually apply the missing logic. A pre-project assessment must compare the modification date of the source file against the creation date of the compiled object. This source-to-object date compare identifies the gaps before the conversion starts. You must know exactly which files match production.
Catching migration risks before the contract begins
You can identify these risks by matching the underlying cause to a specific artifact. We generate these artifacts during our initial read of your system. Reviewing these outputs gives you a clear picture of the actual effort required. A structured read replaces guesses with checkable facts.
| The cause of the failure | The artifact that catches it before the contract |
|---|---|
| Estimate from a program count | The program count of programs actually called |
| Dead code converted | The graph |
| An unresolved copy member | The warning list |
| The developer who retired | The descriptions |
| Source that no longer matches the running object | The source-to-object date compare |
The table shows exactly how a structured analysis prevents surprises. You demand these artifacts before you sign a statement of work. You use them to hold the vendor accountable for the true scope of the project.
Golden Path Digital reads the source code first
We run a structured read of your source code before anyone makes a target decision. Golden Path Digital developed AS/Forward to handle this analysis. AS/Forward is software that reads IBM i RPG source. It reads six RPG dialects through a proprietary ingestion layer. It builds an interconnection graph across every program, file, copy member, and display file. It generates a plain-English description of each program from the ingested source. It flags unresolved copy members and missing dependencies as warnings.
AS/Forward shows a readiness status per program. It scopes a change in a migration view. You pick a field or an object, and the view lists what else moves. It converts to any target language you pick. We can convert fixed-format to free-format RPG if you plan to stay on Power hardware. We can manage an RPG to Python conversion if you plan to leave the platform. Python and free-format RPG are two examples.
The AI engine sits behind the structured read. It runs against Claude, OpenAI, Gemini, or local models on your own hardware. We install AS/Forward air-gapped inside your network, and nothing leaves. AS/Forward carries one US patent pending. We tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
What a static read of your source code cannot prevent
Even the most thorough analysis has limits. We recognize the boundaries of automated tools. An automated tool cannot stop a business from choosing a target environment for the wrong reason. You might mandate a move to the cloud because of a corporate directive. Keeping green screens and modernizing the logic behind them might make more technical sense. A static read also cannot uncover a business rule that nobody wrote down. The AI explains the code behavior. A human developer must explain the original intent. You need human context to understand the application history.
A static read cannot identify security flaws hidden in operational processes. CL programs that drive FTP transfers often hold a user ID and password as literal text. The tool will document the text. A human review must flag it as a risk. A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. A security expert must evaluate whether it poses a threat. You must apply human judgment to the technical outputs. Skipping this human review is exactly why legacy modernization projects fail when companies rely entirely on automation.
Ask us to read your IBM i production libraries
The best way to protect your modernization budget is to analyze your source code before you commit to a migration schedule. Call Golden Path Digital at 501-232-7188. Ask us to run the IBM i modernization assessment on your production source libraries. We ingest the code. We hand back the program count. We provide the dependency graph and the plain-English descriptions. We list the warnings and the programs that nothing calls.
If your security policies prohibit external transmission, ask us to install AS/Forward air-gapped on your own hardware, and it reads the source there. You achieve a complete understanding of your system first. You make the target decision second. We support custom software development to bridge the gaps in your new architecture. Every outcome is valid. You can move off RPG. You can clean up the logic to free-format RPG. You can keep the green screens and modernize behind them. You can blend these approaches across different applications. Call us today and tell us what your source code libraries hold.