The board meeting opens on Tuesday morning to discuss your core financial applications. One slide shows a proposal to replace your current system with a packaged ERP. The next slide proposes a project to modernize the applications you already run. The debate quickly turns into an AS400 vs SAP discussion. The financial officers want the predictability of a commercial product. The engineering leaders point to the decades of custom business logic running the warehouse. A vote is approaching, and everyone in the room has an opinion.
Then someone asks what the four thousand programs on the current machine actually do. The room goes quiet. The source code contains the rules that govern your pricing and inventory. Nobody in the room can say exactly what those rules are. The original authors retired years ago. The remaining developers spend their time applying patches. Your company is about to make a massive financial decision based on an empty map.
What an AS400 vs SAP comparison actually measures
The system people call the AS400 is an operating system and a hardware line. The operating system is currently named IBM i. IBM previously sold it as AS/400 and iSeries. The company also sold it as System i. It runs on Power hardware. This platform holds custom applications written in RPG over decades. Those applications were built to match your specific business processes exactly. Programs written in the 1990s still compile and run today. The platform is a blank slate that your company filled with code. The resulting system is unique to your operations.
SAP is a packaged enterprise resource planning product configured to a business. The vendor wrote the software to support standard business practices across multiple industries. You buy the product and configure it to fit your company. The vendor updates the core product on their own schedule. A decision between these two options is a choice between maintaining custom software and configuring a commercial package. The term AS400 vs SAP is simply another name for a build-versus-buy decision. Both roads start at the exact same place. You must know what your current code does before you can pick a direction. The source code is the only reliable record of your business logic. You have to read it. The board needs a factual foundation before they sign the check.
The map both roads require on day one
A packaged ERP migration needs the business rules extracted from the RPG before anybody configures a new screen. A modernization project needs the exact same map. The read of the source code is the first step on either road. Every outcome is valid, and the right choice depends on facts hiding in your production libraries. We provide an IBM i modernization assessment that gathers those facts. The following table shows what both approaches require from your source code before the project begins.
| Asset category | What a packaged ERP project needs | What a modernization project needs |
|---|---|---|
| Business rules | Extracted logic to configure the new package | Plain-English definitions to guide the new developers |
| Field definitions | Exact lengths and types to map data transfers | Current sizes to plan database expansion and upgrades |
| External interfaces | Connection details to recreate missing links | Security requirements to protect open ports and sockets |
| Exceptions | Rules that fire twice a year for unusual orders | Specific routines that require special testing blocks |
| Unused programs | A list of programs nothing calls to reduce scope | A list of dead code to exclude from the conversion effort |
This map prevents costly delays on both paths. You capture the facts once. You use those facts to shape the future of your technology stack. A structured read of the source does the extraction in one pass. The extracted logic becomes the blueprint for the entire transition.
Why a source inventory starts every successful path
A map of your code is the first deliverable on any project plan. The source inventory tells you exactly how much work your team must do. You cannot schedule a migration or a rewrite without a program count. You also need to know how those programs connect to each other. The RPG developers who wrote the original routines are near retirement. The documentation they left behind is out of date. The actual rules live only in the production source libraries.
When a company attempts an AS400 vs SAP decision without reading the source code, they guess. They guess how many custom processes they need to recreate. They guess how many files their nightly batch jobs update. A formal inventory replaces those guesses with counted facts. You see exactly which files a program references at compile time because DSPPGMREF reports those details. You understand your exact starting point. You can confidently compare the IBM i modernization cost against the price of configuring an ERP. The map gives your board a foundation for a massive financial commitment. The extraction process forces the business logic into the open. You can see the logic, and you can plan the project around it. The risk drops immediately when the unknown code becomes a documented asset. The technical teams stop arguing about opinions and start working from evidence.
What packaged ERP projects discover late
Companies that buy a packaged ERP often skip the source code extraction step. They assume the new software has a configuration screen for every current process. The project starts with enthusiasm and high-level process mapping. Six months later, the testing phase begins. The warehouse managers realize the new system handles standard orders perfectly. The warehouse managers also realize the new system cannot process the seasonal bulk discounts that drive your revenue. The rules for those discounts were never extracted from the RPG code. The original developers wrote them decades ago and nobody documented the math.
The ERP project suddenly stalls. The implementation team must write custom extensions to the packaged software. The budget increases to cover the unexpected development hours. The release date moves back a year. The business rules that seemed minor in a boardroom presentation turn out to be vital to your daily operations. A structured read of the source code prevents this failure. When you extract the rules first, the ERP implementation team configures the exceptions before the first test cycle. They know exactly what the custom extensions must do. The extraction eliminates the surprises that ruin implementation schedules.
What modernization projects discover late
Companies that choose to modernize their existing applications face a different set of risks. A modernization team often decides to convert every program in the production library to a new language. They feed the entire library into a conversion tool. The team spends thousands of hours reviewing and adjusting the output. Two years into the project, they discover that many of the converted programs are never called by any active job. The modernization project discovered the dead code late. The company paid developers to rewrite programs that stopped being useful a decade ago. The budget drained away into obsolete routines.
A related failure happens when a modernization team misses the connections between programs. Copy members pull source from other libraries into a program at compile time. If the team moves a program without moving its copy members, the new code breaks. The failure cascades through the daily operations until someone tracks down the missing dependency. Runtime-built call targets present another hidden trap. A program name assembled from a parameter does not appear in any static cross-reference. You must identify these dynamic calls early to ensure your modernized system functions correctly. Security issues also hide in legacy code. A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. CL programs that drive FTP transfers often hold a user ID and password as literal text. A proper map identifies the programs nothing calls and the hidden dependencies before the first line of code changes. The clean code moves forward, and the security flaws get fixed.
How AS/Forward reads your production source
Golden Path Digital maps your systems to make your AS400 vs SAP choice clear. We use AS/Forward to read your IBM i RPG source. AS/Forward is software that reads six RPG dialects through a proprietary ingestion layer. It builds an interconnection graph across every program, file, copy member and display file. You read this graph to see exactly how your applications fit together. The software generates a plain-English description of each program from the ingested source. You can read these descriptions and understand what your system does without knowing how to read RPG. The business analysts can review the rules and verify the logic.
AS/Forward scopes a change in a migration view. You pick a field or an object, and the view lists what else moves with it. The software flags unresolved copy members and missing dependencies as warnings. An unresolved copy member is one the reading tool could not find. The software shows a readiness status per program to help you plan your timeline. AS/Forward carries one US patent pending. We tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
The tool converts your logic to any target language you pick. Python and free-format RPG are two examples of target languages. AS/Forward runs against Claude, OpenAI, Gemini or local models on your own hardware. The preferred deployment is air-gapped inside your network. An air-gapped install keeps your proprietary logic secure behind your own firewalls. The reading process leaves the final choice entirely in your hands. Understanding comes first, and the target decision comes second. You can move off RPG. You can clean up to free-format. You can keep green screens and modernize behind them. You can leave the system exactly as it runs today. Every outcome is valid. Your final choice rests on a complete and accurate map.
Four questions to answer before the board votes
Your team needs hard facts before they approve a massive technology change. The pressure to make a decision is real. IBM i 7.4 reaches IBM end of support on 30 September 2026. IBM i 7.3 reached end of support on 30 September 2023. No date is announced for 7.5 or 7.6. You can prepare for the final meeting by answering specific questions about your current environment. These answers clarify the scope of your upcoming project.
- Your team must find the exact count of active programs running in your production libraries today.
- You must record the plain-English business rules for your custom pricing and inventory routines.
- Your technical leads must identify the specific files your nightly batch jobs update.
- You need a complete list of programs that no other active process calls.
An AS400 vs SAP choice demands clarity on all four of these points. If you cannot answer them, your project timeline and budget are at risk. The board needs a reliable baseline before they commit company funds. Gathering this information requires a structured read of the source. You cannot afford to guess the answers when the business depends on the results.
The first step toward a final choice
The choice between a new platform and your current system shapes the future of your company. You can make this decision on solid ground by extracting the facts from your code first. We have the tools and the experience to uncover those facts. We provide custom software development and deep analysis of legacy systems. We ingest your production source libraries and hand back the program count, the dependency graph, the plain-English descriptions and the warning list. You receive the documentation you need to plan your next steps.
You can call Golden Path Digital at 501-232-7188 to start the conversation. Ask us to read your production source libraries through our modernization assessment. Or we install AS/Forward air-gapped on your own hardware and it reads the source there. Tell us how many programs you run and what deadlines your board faces. We will map your business rules and give you the clarity you need. We help you replace the guesswork with a reliable inventory of your digital assets. Your team will step into the boardroom with confidence. You will make your final choice based on counted facts.