Every vendor selling IBM i RPG modernization services has a slide deck. Most of the decks look alike: legacy risk on one slide, a modern architecture diagram on the next, a case study with the client name removed. What separates a real modernization partner from a rewrite shop is not the deck. It is what they are willing to show you about your own system before any contract gets signed.
If you are evaluating services for a codebase your company has run for decades, the checklist below is what to demand up front, and why.
Ask to See Your Own Dependency Map
A vendor who intends to modernize your system responsibly should be able to ingest a slice of your source and show you what they found: the programs, the files, the copy members, and the edges between them. Not a generic architecture diagram. Yours.
This is the single most revealing request you can make. A vendor with real tooling can produce an interconnection graph of your code and walk you through it. A vendor without it will steer the conversation back to methodology and staffing. Methodology matters, but methodology without a map means their plan was built on assumptions about a system they have not read.
AS/Forward, our modernization platform, builds this map as its first act: it ingests IBM i source through a proprietary ingestion layer that reads six RPG dialects, then generates dependency graphs and plain-English descriptions of every program it touched.
Good Vendors Show You Their Flags, Not Just Their Wins
Here is a counterintuitive vetting signal: the best pre-contract demo includes the word "unresolved." Real codebases have missing copy members, dependencies that cannot be traced cleanly, and programs that resist automated understanding. Tooling that never flags anything is not confident. It is blind.
AS/Forward marks every program with a readiness status based on how confident the ingestion layer is in what it read. Clean programs are marked ready to convert. Ambiguous ones are flagged for human review. When a vendor shows you flags on your own code, you are looking at honesty you can verify. When every program is green, ask harder questions.
Line-by-Line Translators vs Context-First Tools
IBM i RPG modernization services split into two technical camps, and the difference shows up a year into the project.
Line-by-line translators convert syntax. RPG in, target language out, one statement at a time. The output compiles, and then your team spends the next eighteen months discovering that the translated code preserved every quirk of 1988 without preserving the understanding of why the quirks existed.
Context-first tools build a structured understanding of the system before converting anything. AS/Forward feeds an AI model both the original source and a programmatically generated English description of what that source does, so the conversion works from ground truth instead of statistical guessing. That structured context is the part of the platform with one US patent pending.
The Questions That Sort Vendors Quickly
Beyond the map and the flags, four questions do most of the vetting work:
- Where does our source code go? The answer you want is "nowhere." AS/Forward runs air-gapped inside your own infrastructure, and the AI layer is model-agnostic: it works with cloud models or with models running entirely on your own hardware. If a vendor needs your source uploaded to their cloud, your security team should hear about it now, not in procurement.
- Who picks the target language? You should. Some shops want Python. Some want free-format RPG and no platform change. Some want a staged mix. A vendor whose tooling only outputs one language has made your architecture decision for you.
- What happens to code that should not be migrated? Decades of development leave dead programs and duplicated logic. Migrating dead code is billable work for the vendor and pure waste for you. Ask how they find it.
- What do we get if we stop after the assessment? The honest answer is: a complete map of your system, program descriptions your team keeps, and a scoped plan. An assessment that only has value if you buy the migration is a sales tool, not a deliverable.
Where the Assessment Fits
We have written before about why the IBM i modernization assessment comes first: it converts the unknowns that sink migrations into a document leadership can act on. In a vendor evaluation, the assessment is also your cheapest test of the vendor themselves. How they handle your code at small scale, what they flag, and what they hand you at the end tells you what the full engagement will look like.
Put Us Through the Same Test
Golden Path Digital builds and runs AS/Forward, and we are comfortable being vetted exactly the way this article describes. Send us a representative slice of your RPG, and we will show you the dependency map, the descriptions, the flags, and the readiness picture before anyone talks contract. Call 501-232-7188 to set it up.