You watch a vendor demonstration on a screen share. A sales engineer clicks a button and a utility converts one RPG program into clean target code. The output compiles perfectly. You ask what happens when the utility runs against the other 3,999 programs in your production environment. The engineer changes the subject.
That silence hides the actual cost of a legacy migration project. Most IBM i modernization tools look identical on a marketing sheet. They diverge when you point them at a massive production library. Your RPG developers are nearing retirement. The people who understand your billing systems will leave the company soon. Programs written in the 1990s still compile today. They run perfectly on modern Power hardware. The hardware functions well, so the business ignores the software.
You need utilities that scale to thousands of objects. You can filter the market quickly by asking vendors two practical questions. You must ask what exact text the utility ingests. You must ask what parts of your operating environment the utility ignores completely. The answers dictate how much manual labor your engineering team will absorb.
Sorting IBM i modernization tools by input
The market for legacy software conversion falls into five distinct categories. Standard vendor articles often sort these utilities by the company name. A better method sorts them by the exact files they require to function. The input format defines the ceiling of what the utility can accomplish. It dictates the boundaries of the output.
| Kind | What it reads | What it writes | What it leaves unread |
|---|---|---|---|
| Screen modernizers | Display files | Web interfaces | Business logic inside RPG programs |
| Free-format converters | Individual RPG programs | Free-format RPG code | Interconnections between multiple programs |
| Transpilers | Original source code | Target language source code | External system dependencies |
| Code analyzers | The whole library | A dependency graph | Target language conversion |
| Documentation generators | Original source code | Plain-English descriptions | Code conversion |
Screen modernizers update the visual presentation of your application. They parse display files and generate modern web interfaces. They leave the green-screen logic intact behind the new graphical interface. Free-format converters update the syntax of your RPG code one file at a time. A free-format converter changes the structure of a single file. It does not evaluate the files that call it. Transpilers take an old language and generate a new language automatically. Code analyzers ingest the entire library to build a map of your whole system. Documentation generators process original source code and write plain-English descriptions of the logic.
You must align the utility category with your specific project goals. A transpiler will not document your business rules. A screen modernizer will not convert your fixed-format syntax. The sorting process forces vendors to state their technical boundaries clearly.
Why the input boundary decides your migration risk
The input format defines the blind spots of the utility. A software package that processes one program at a time cannot see a copy member shared by 200 different programs. It evaluates the single file and assumes the surrounding environment will remain static. This assumption breaks down rapidly in a real production environment.
RPG developers spent decades building highly interconnected systems. A single business transaction might touch many physical files. IBM i programs rely on external resources constantly. A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. The conversion utility must account for that elevated authority. If the utility only scans the syntax of the program, it misses the security context entirely.
Data access creates similar dependencies across your libraries. The DSPPGMREF command reports which files a program references at the file level. It captures these file references at compile time. The DSPPGMREF command output provides a snapshot of the compilation moment. It does not track changes made after the compilation date. The migration utility must evaluate the current state of the database. A free-format converter updating a single program will not check if the referenced physical file still exists on the disk. The utility outputs clean syntax for a broken process.
The scope of the ingestion dictates the safety of the output. When a parser ignores the surrounding library, it shifts the discovery of broken links directly to your testing team. Your testing phase becomes a manual debugging exercise.
The failure reports that separate the field of options
Every software package handles clean code without errors. The defining question for a conversion utility is what it reports when it cannot resolve an object. You need to know the failure states before you buy the software license.
Copy members pull source from other libraries into a program at compile time. Over thirty years, developers move libraries and delete old objects. Developers create copy members to share common logic across hundreds of programs. When a developer deletes an old copy member, the referencing programs remain on the system. The scanning utility will encounter the broken reference eventually. An unresolved copy member is one the scanning utility could not find. Many IBM i modernization tools skip broken links silently. Other utilities halt the entire batch job immediately. A safe utility flags unresolved copy members as warnings and continues scanning the rest of the system.
Missing dependencies require an explicit paper trail. If a utility drops a variable because a physical file disappeared years ago, you need a warning report. You cannot afford to discover missing logic during user acceptance testing. Ask the vendor to show you the error logs from a failed compilation.
The quality of the failure report tells you how much manual debugging your developers will do. If the utility hides the errors, your team will spend months chasing missing variables. The utility must explicitly state what it could not parse. An honest error log accelerates your migration timeline.
Where AS/Forward fits in your software stack
Golden Path Digital developed AS/Forward to address the gaps in traditional parsing utilities. AS/Forward is a code analyzer and documentation generator first. We built a proprietary ingestion layer that processes six different RPG dialects. The software builds an interconnection graph across every program, file, copy member, and display file.
The software generates a plain-English description of each program from the ingested source. The artificial intelligence supports this structured read of your library. AS/Forward runs against Claude, OpenAI, Gemini, or local models on your own hardware. The preferred deployment is air-gapped inside your own network. You can run air-gapped AI source code processing without exposing your intellectual property to a public cloud.
The software shows a readiness status per program. It flags missing dependencies as warnings. It scopes a change in a migration view. You pick a field or an object, and the view lists what else moves. The migration view shows the exact impact of changing a single database field. You can see every program that touches the field before you make the change.
After the software completes the analysis, it handles conversion to any target language you pick. You might choose Python. You might choose free-format RPG. Both targets are valid business choices. AS/Forward carries one US patent pending for its ingestion technology. We tested this ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
How to test IBM i modernization tools on your library
You should evaluate IBM i modernization tools against your most difficult programs. Vendor demonstrations always use simple programs with clean dependencies. You need to know how the utility behaves when it hits thirty years of technical debt. Your developers know which programs contain the most complex logic. They know which programs crash frequently. These brittle programs expose the weaknesses in an automated utility. Ask your senior developers to pick five programs they hate modifying.
Give these five complex programs to the vendor. Ask for the generated output and the error logs. Look for hardcoded credentials in the output files. CL programs that drive FTP transfers often hold a user ID and password as literal text. Ask whether the tool reports those literals or copies them into the target language.
Review the target code with your engineering team. Check if the output matches your internal coding standards. You can review our approach to RPG to Python conversions to ensure the resulting code is maintainable. If the utility generates Python code that mirrors fixed-format RPG perfectly, you have simply transferred your technical debt to a new syntax. The output must be readable by developers who have never seen an IBM i terminal. The evaluation proves the actual value of the software license.
What no software package will do for your engineering team
No software package can decide the target architecture for your business. The migration destination is a fundamental business choice. Your team might move off RPG entirely. You could clean up to free-format RPG and keep your current hardware. A third option keeps the green screens and modernizes the data layer behind them. Every outcome is valid.
No parser can explain why a business rule exists. The software can tell you that a program checks a customer balance against a specific threshold. The software cannot tell you why the threshold sits where it does. Your business analysts understand the original requirements for the threshold. The modernization tool only translates the mathematical formula. The historical context of your business logic remains in the minds of your senior developers. You must capture that institutional knowledge before those developers reach retirement age. The retirement clock runs independently of the hardware lifecycle.
Automated utilities cannot discover dynamic runtime targets. Runtime-built call targets do not appear in any static cross-reference. A program name assembled from a parameter at runtime will evade static analysis. A software utility accelerates the migration project by documenting static connections. It gives your team time to focus on complex runtime behavior. It does not replace the judgment of your technical leadership.
Start your IBM i modernization assessment today
Golden Path Digital runs the IBM i modernization assessment to give you a complete map of your current system. We ingest your production source libraries. We hand back the program count, the dependency graph, the plain-English descriptions, the warning list, and the list of programs nothing calls. We prioritize understanding first and the target decision second. The second decision belongs to you.
You can call us to read your production source libraries securely. Or we install AS/Forward air-gapped on your own hardware and it reads the source there. We understand the limits of static analysis. If your programs assemble call targets dynamically, those connections require manual runtime testing. We outline these boundaries clearly before the project begins. Our assessment gives you the data required to plan a realistic budget. It removes the guesswork from the migration timeline. You can visit our contact page to schedule a technical review.
The timeline for these decisions is shrinking. IBM i 7.3 reached end of support on 30 September 2023. IBM i 7.4 reaches IBM end of support on 30 September 2026. IBM has announced no date for versions 7.5 or 7.6. The pressure to map your environment will only increase.
Call Golden Path Digital at 501-232-7188. Tell us how many RPG programs run in your production environment. We will help you catalog your source code and plan your next step.