An AS/400 cloud migration moves the machine. Your code arrives unchanged.
The RPG programs run the same logic in the new data center. The DDS files carry the same record formats. Every copy member the compiler cannot resolve today stays unresolved after the cutover. The developer who is the only person alive who understands the nightly billing job retires on the same date either way.
Hosting vendors price capacity and a cutover window. Those numbers do not depend on one line of your source. A shop can sign an AS400 cloud hosting contract and run a clean cutover. In March it still owns every problem it owned in February. This guide separates the two decisions, then shows you how to inventory your own source before a vendor prices the job.
What an AS/400 cloud migration moves, and what it leaves behind
A migration project moves objects. Your team ships the libraries, the database files, the journal receivers, the user profiles, and the subsystem descriptions. A hosting partner handles the IBM i release level and the network path back to your users. Done well, the whole move is unremarkable.
A capable partner takes on more than floor space. Backup schedules, replication targets, disaster recovery, and release currency all move onto somebody else's runbook. What stays with you is every question about the code. No hosting contract answers what a program does or what breaks when a field grows.
The migration does not touch the logic. A program that computes a discount from a hard-coded customer number computes the same discount in the cloud. A CL program that calls a library by literal name still calls that library. Green screens stay green. Your batch window still ends when the longest job ends.
Distance is the one thing that changes. When the hardware sat in your building, a senior developer walked to the console. After the move, that same developer opens a ticket. The knowledge that used to walk down the hall now travels through a support queue.
AS400 hosting and IBM i modernization are two separate decisions
Decision one asks where the workload runs. You can refresh the hardware in your own room or move the partition to an AS400 cloud services provider. A shop can also move development hosting to a partner first and keep production in house until the pattern proves out.
Decision two asks what the code is. The options are to leave the RPG source as it stands, convert fixed-format programs to free-format RPG, move selected programs into another language, or work through some of each by phase.
The two decisions share almost no inputs. Decision one runs on capacity numbers, user counts, your IBM i release level, and your ISV license terms. Decision two runs on what your programs actually do. A vendor who has read none of your source cannot price decision two. Most quotes for AS400 cloud migration bundle both anyway, and the second half of the number is a guess.
Either order works. Host first and the hardware risk comes off the books while the code inventory runs. Map the code first and you move a smaller system after retiring what nothing calls. The failure is one quote that prices the move and treats the code as a line item nobody inspected.
What your RPG codebase hides from an AS400 hosting quote
A hosting questionnaire asks for measurable things. It wants core counts, disk capacity, interactive user counts, IBM i release level, and ISV license inventory. Every answer comes from a system value or an invoice. None comes from reading a program.
Five things stay invisible to that questionnaire, and each one moves what the code work costs.
- Dialect spread. Most source libraries hold more than one RPG. Fixed-format RPG III sits beside free-format RPG IV. DDS-defined display files and printer files thread through both. Members that embed SQL inside RPG add a shape of their own. A tool that reads only the modern dialect leaves the oldest and riskiest code unread.
- Dead programs. Forty years of development leaves sediment. Objects survive whose only caller somebody deleted two upgrades ago. Nobody retires them because nobody can prove nothing calls them.
- Hard-coded assumptions. Library lists, IP addresses, printer names, and device names sit inside source that ran on one machine for decades. A new address space finds them the hard way.
- Third-party calls. Programs reach into ISV products through service programs whose license terms may or may not follow you into a hosted partition.
- Integrations. Batch interfaces, FTP scripts, ODBC connections, and scheduled transfers point at addresses that made sense in your building. Each one needs a new answer after the move.
Our guide to RPG code analysis covers the analysis side in more depth. A hosting quote measures the box. Your real risk sits inside the source.
Copy members and DDS files hide the dependencies nobody wrote down
Copy members are the dependency an IBM i estimate cannot see. A /COPY directive pulls source out of a different member in a different library. The compiler resolved it once. Whether it resolves today depends on a library list nobody has audited since the last upgrade. AS/Forward flags unresolved copy members and missing dependencies during ingestion. The gap lands on a report before it lands in a failed compile.
DDS files carry the second problem. A physical file's DDS defines the record format, and every program that reads that format inherits the field definitions. Add two characters to a customer number and the change does not stop at one file. It reaches every program that reads the format, every display file that shows the field, every printer file that prints it, and every downstream file that carries it.
Then there are the dependencies with no artifact at all. A CL program calls a program by a literal name that appears in no cross-reference. A data queue connects two jobs that never mention each other in source. A database trigger fires a program that no caller ever names. A program builds another program's name at runtime from a parameter. Each of those edges runs in production tonight and appears in no document your team owns.
Database work adds its own inventory. Moving from DDS-defined files toward SQL tables changes how programs open and read data. That is a separate project with a separate scope, and we walked through it in our guide to AS/400 database migration.
How to read a 40-year IBM i codebase before you scope the move
Nobody inventories four thousand programs by opening them one at a time. The practical method ingests the whole source library at once and builds the map from what the source says. Machine time carries that pass, and your developers spend theirs on the exceptions.
AS/Forward does that job. It reads six RPG dialects through a proprietary ingestion layer, then builds an interconnection graph across every program, file, copy member, and display file it finds. From that structure it generates plain-English descriptions of what each program does. Because the descriptions come from the ingested source, a developer can check one against the code.
The tool also reports what it could not read. Unresolved copy members and missing dependencies appear as warnings on the program page. A readiness status tells your team how confident the ingestion layer is in what it read. Clean programs move forward. Programs with warnings go to a person before anyone converts them.
A real library never ingests cleanly on the first pass. Some members sit in a library the list never reaches. Somebody edited other source in place years ago, and it no longer matches the object that runs. The report names those cases by member and by program. Your team then decides which gaps to chase before the move.
Ingestion needs one thing from your team: a copy of the source libraries. Where that copy sits is the question a regulated shop asks next. The preferred deployment runs air-gapped inside your own infrastructure, and nothing leaves your network. AS/Forward carries one US patent pending on the approach.
Golden Path Digital tested the ingestion layer against a corpus of roughly 5,000 programs. Every one came from a public source: PUB400 and open code repositories. The full workflow sits on our IBM i modernization assessment page, and the AS/Forward page covers the product itself.
What a dependency map changes about the quote you receive
Hand a hosting vendor a system profile and you get a price for the box. Hand a modernization vendor a dependency map and you get a price for the work.
The map turns opinions into counts. Your team can state how many programs the library holds and how many of them nothing calls. It can state how many copy members refuse to resolve and which programs touch the field somebody wants to change.
That list changes the conversation. A field length change stops being a judgment call and becomes a named list of programs and print jobs. AS/Forward scopes that directly in its migration view: pick a field or an object, and the view shows what else changes. A quote built on a walkthrough produces change orders once the work starts.
The map also lets you phase the move. A shop with four thousand programs does not have to convert four thousand programs. It can host the whole system, then convert only the programs that block the next audit.
The saving runs in the other direction too. Dead code is a finding your team can act on. Every program the map proves nothing calls is a program nobody has to convert or host.
Choosing a target language for the code you decide to convert
AS/Forward converts to the target your team names. Free-format RPG keeps the platform and keeps your current staff productive on day one. A move off RPG widens the hiring pool, and the target can be Python, Java, C#, or whatever stack your architects already support.
Conversion quality depends on what the model sees. AS/Forward feeds the model the source code and the plain-English description the ingestion layer generated from that same source. The description carries structure that raw fixed-format source does not spell out on its own.
Model choice stays yours. AS/Forward runs against Claude, OpenAI, Gemini, and local models on your own hardware. For an air-gapped install, the local option keeps every call inside your network. A security review that asks where your source code goes gets a one-word answer: nowhere.
Some shops convert almost nothing. Green screens still work, and a warehouse crew that knows every key sequence by heart does not want a browser. For those shops the exercise delivers the map, the descriptions, the unresolved list, and a plan for the day the last RPG developer retires.
Questions to ask an AS400 cloud hosting vendor about your source code
Bring these to the next AS400 hosting services call. The answers separate a vendor who has read your source from a vendor who has read your invoice.
- Which RPG dialects does your assessment read? A library with fixed-format RPG III needs an answer that names it.
- How do you find copy members that no longer resolve? Ask to see the report.
- If we change one field, what tells us which programs change with it? Ask to see that view on a live program.
- Which programs in our library does nothing call? A vendor who cannot answer will quote you for converting dead code.
- Where does our source code live during the assessment? A regulated shop needs it air-gapped inside its own infrastructure.
- Which target language does the conversion produce, and who picks it? The answer should be your team.
An AS/400 cloud migration and an IBM i modernization are both worth doing. Running them as one project is how a shop pays for the move twice.
Golden Path Digital runs AS/Forward against your RPG library and hands your team the dependency map, the program descriptions, the unresolved copy members, and the list of what nothing calls. Call 501-232-7188 and tell us what your system runs. We start with the source.