The IBM AS/400 was renamed IBM iSeries, then renamed IBM i, then renamed IBM Power Systems running IBM i. The platform itself has not been “AS/400” since 2000. The shops that run it still call it the AS/400, and the modernization conversations still happen under that name.
This guide is for AS/400 shops where the platform itself is stable, the business logic is sound, but the green-screen interface is no longer acceptable to the business. Customers expect web. Internal users expect mobile. The CFO expects modern dashboards. The application running underneath is fine. The interface is not.
What follows covers what modernization actually means in this scenario, the four architectural paths available, and how to choose between them.
The Modernization Question Is Rarely “Replace the AS/400”
For most shops running AS/400 in 2026, replacing the platform itself is not the goal. The AS/400 is reliable. It runs banking, insurance, manufacturing, and government workloads at scale, with uptime characteristics that newer platforms struggle to match. Replacing it would mean rebuilding decades of business logic on a stack with worse reliability characteristics for higher cost.
The actual goal is usually narrower: keep the AS/400 doing what it does well, change the interface and integration surface to match modern expectations. This produces four candidate architectures.
Architecture 1: Keep Green Screens, Modernize Around Them
The application keeps running on the AS/400 with its existing 5250 green-screen interface. Modern functionality is added at the edges: web portals that consume AS/400 data via APIs, mobile interfaces that wrap specific workflows, dashboards that pull from the same database.
What this looks like: The accounts payable clerk still uses green screens because that workflow is fast and reliable on 5250. Field reps use a mobile app that calls into AS/400 over REST APIs. Executives see modern dashboards pulling from the same database the green screens write to.
Pros: Lowest risk. No business logic changes. The users who like green screens (and there are many in industries where data entry speed matters) keep what they know. New surfaces serve new users.
Cons: The green screens still exist, which means RPG developers are still needed to maintain them. The talent cliff is not addressed. The architecture is hybrid and stays hybrid.
Where it fits: Shops where business logic is stable, RPG talent is still available, and the modernization driver is external (customer-facing surfaces) rather than internal (developer continuity).
Architecture 2: Screen Scraping and 5250 Web Wrappers
Tools that wrap the existing 5250 green-screen interface in a browser-based or modern web shell. The underlying AS/400 application is unchanged. The user sees a modern-looking interface that is structurally still the green screen, with mouse navigation, themed presentation, and modern fonts.
Pros: Fast to deploy. No application changes. No RPG developer involvement required. Cosmetically modern.
Cons: The architecture is still 5250 underneath. Performance is what 5250 performance is. Mobile support is awkward. The application logic remains what it was, with all the same maintenance characteristics. Most shops outgrow this approach within a few years.
Where it fits: Tactical intermediate step. Shops that need to show modernization to their users before a more substantive modernization is ready.
Architecture 3: Convert RPG to Modern RPG (Free-Format)
The AS/400 application is rewritten from fixed-format RPG to free-format RPG (RPG IV). The platform stays the same. The language gets meaningfully more readable, more maintainable, and more accessible to engineers trained on modern languages.
Pros: Preserves the AS/400 investment. The application keeps running on the platform it was designed for. New developers can read and modify the code without the steep RPG fixed-format learning curve. AI-driven tooling (AS/Forward and others) automates much of the conversion work.
Cons: The interface is still green-screen unless paired with Architecture 1. The application still runs on IBM i, which requires IBM i infrastructure and licensing. The team still needs people who understand RPG, although the talent pool is broader for modern RPG than for fixed-format.
Where it fits: Shops committed to the AS/400 platform but addressing the talent and maintainability problem. Often paired with Architecture 1 (keep green screens for some users, modern surfaces for others).
Architecture 4: Convert RPG to Python (or Another Modern Language)
The AS/400 application logic is converted to a modern language (commonly Python, sometimes Java, sometimes others depending on the customer’s broader stack) and runs on modern infrastructure. The database may stay on DB2 for IBM i, may migrate to a modern relational database, or may be split across multiple data stores depending on workload.
Pros: The application is now in a language the broader developer community speaks. Talent acquisition is straightforward. Modern tooling, frameworks, and integrations apply. The application can be hosted anywhere (cloud, on-premise modern infrastructure, hybrid).
Cons: Largest scope. Highest risk if done by hand. AI-driven tooling reduces both substantially, but the conversion is still a real engineering project. Some AS/400-specific behaviors (record-level locking, specific RPG idioms, certain DB2 features) require translation that goes beyond syntax conversion.
Where it fits: Shops where the AS/400 platform itself is being phased out, where the long-term direction is cloud or modern on-premise infrastructure, and where the team has the leadership air cover to commit to a multi-year project.
The Tooling Difference
The reason this conversation is different in 2026 than it was in 2018 is that the conversion tooling has changed.
Manual RPG-to-Python conversion in 2018 meant a developer reading each RPG program and writing the equivalent Python. Velocity was measured in programs per month per developer. The work was slow, error-prone, and required engineers who understood both languages well.
AI-driven modernization tooling in 2026 (AS/Forward from Golden Path Digital, IBM’s tooling, emerging competitors) starts with deterministic ingestion of the codebase: every program parsed, every dependency mapped, every copy member resolved, every program described in plain English. The AI then operates with that structured context rather than guessing about what a program does. Conversion output is reviewed by humans, but the throughput is multiples of what hand conversion achieves.
This changes the cost calculus for Architecture 4 specifically. The “convert to Python” option is now economically tractable for codebases where it was prohibitive five years ago. Some assessment engagements that previously took six months can complete in weeks.
How to Choose Between the Four
The right architecture depends on five factors:
- Why are you modernizing? External (customer-facing) drivers favor Architecture 1. Internal (developer continuity) drivers favor Architecture 3 or 4.
- How committed are you to IBM i as a platform? Committed: Architecture 3. Phasing out: Architecture 4. Unsure: Architecture 1 buys time.
- What does your RPG team look like in five years? If the answer is “we won’t have one,” Architecture 3 or 4 is required. If you have a stable team, Architecture 1 is viable.
- What is your tolerance for project risk? Lowest risk: Architecture 1. Highest reward: Architecture 4 if executed well.
- What is the broader stack? If the rest of the enterprise is on Python and AWS, Architecture 4 has integration advantages. If the rest is on Java and on-premise, Architecture 3 may align better.
Most shops do not pick a single architecture for the whole portfolio. Different applications get different treatments. The point of the framework is to make those choices deliberate.
Common Mistakes
- Picking the architecture before the assessment. Different applications fit different architectures. A blanket “modernize everything to Python” is rarely the right answer.
- Underestimating the screen-scraping path. 5250 web wrappers are a tactical intermediate step. Treating them as the destination produces buyer’s remorse two years later.
- Treating “modern” as a destination instead of a process. Modernization is ongoing. The IBM i shop that moved to free-format RPG in 2020 should be evaluating AI-driven tooling in 2026.
- Skipping the assessment. An architecture decision made without seeing the actual dependency graph is guesswork. Assessment first, decision second.
- Underestimating user attachment to green screens. Many AS/400 users prefer 5250 over web interfaces because data entry speed is faster. Ignoring this produces user revolt regardless of how good the new interface is.
Golden Path Digital and AS/Forward
AS/Forward is Golden Path Digital’s IBM i and AS/400 modernization platform. The proprietary ingestion layer parses 6 RPG dialects, builds the full dependency graph, generates plain-English program descriptions, and outputs to modern RPG, Python, or other modern languages depending on customer choice. The platform runs air-gapped on customer infrastructure with model-agnostic AI backends. 1 US patent pending.
For AS/400 shops considering any of the four architectures above, the recommended starting point is an assessment engagement. The output is a complete codebase inventory plus a written plan describing what each architecture would actually look like for your specific codebase, delivered in weeks.
What to Do Next
If your organization runs AS/400 (IBM i) workloads and the modernization conversation is on the roadmap, the next step is a scoping conversation. Visit goldenpathdigital.com/as-forward/ for product details, or reach out via the contact form to schedule a discovery call.
Golden Path Digital is an enterprise software and AI modernization company headquartered in Hot Springs Village, Arkansas. AS/Forward modernizes IBM i and RPG codebases. Laravel Ascend automates Laravel application upgrades. QuantaPath AI delivers HIPAA-compliant CRM and workflow automation. Serving enterprises nationwide with US-based delivery and air-gapped deployment options. 1 US patent pending.