A mid-size insurer approved a plan three years ago to move its policy administration system off IBM i. The main reason was a growing skills problem. Its RPG developers were retiring, efforts to hire replacements had failed, and consultants warned that the platform would eventually become difficult to support.  

The rewrite to a cloud-native stack is now 40% complete. It is two years behind schedule and well over budget. Meanwhile, the remaining IBM i system continues to run reliably. 

A new developer who joined the company last year had no RPG experience. With the help of an AI assistant, the developer has been able to understand and modify existing programs and become productive within months. That has made the CIO question whether the original case for leaving IBM i still stands. 

It is a question worth asking more broadly. The IBM i skills gap is real, but the tools available to address it have changed. AI assistants can now explain older RPG code, generate documentation, and convert fixed-form RPG into modern free-form syntax. These capabilities weaken one of the most common arguments for leaving IBM i. 

An IBM i modernization company should help clients reassess that argument rather than assume that moving away from the platform is the only answer. 

The Skills Argument Behind Exit Plans 

For years, the case for leaving IBM i has followed a familiar pattern: 

• Experienced RPG developers are retiring. 

• Universities do not teach IBM i. 

• Younger developers are less interested in learning older languages. 

• Undocumented code is becoming harder and riskier to maintain. 

• Therefore, the platform needs to be replaced. 

The concern is supported by industry data. Fortra’s 2026 IBM i Marketplace Survey found that 69% of respondents considered IBM i skills a top concern. This moved ahead of cybersecurity for the first time in nine years. Application modernization was also cited by 62% of respondents. 

Still, a skills problem does not automatically mean there is a platform problem. The more useful question is whether the skills gap can be addressed on IBM i at a lower cost and with less risk than moving to another platform. 

What AI Assistants Now Do for IBM i 

IBM made Bob, its AI software development assistant, generally available in March 2026. In July 2026, IBM introduced a Premium Package for IBM i to help RPG and IBM i teams work within their existing environments. 

IBM describes several capabilities, including: 

• Converting fixed-form RPG to free-form RPG while preserving existing business logic. 

• Generating documentation and extracting business logic to reduce dependence on limited institutional knowledge. 

• Connecting directly to IBM i to read, write, compile, run SQL, and test code within existing IBM i workflows. 

• Supporting DDS-to-DDL conversion and SQL optimization. 

• Using an IBM i knowledge base to provide more relevant platform-specific guidance. 

Other vendors and open-source projects also provide AI support for RPG, CL, and COBOL on IBM i. Together, these tools make it easier for developers who are new to IBM i to work with existing applications. 

How This Changes the Skills Equation 

AI assistants address several of the problems that have traditionally made IBM i skills difficult to acquire. 

Explaining Undocumented Code 

A developer who is new to IBM i can use an AI assistant to understand what a program does, which files it uses, and how it interacts with other programs. This can reduce the time needed to understand a large and unfamiliar codebase. 

Modernizing Syntax 

Converting fixed-form RPG to free-form RPG also makes the code easier for developers familiar with Java, C#, or Python to read and work with. 

Creating Documentation 

AI-generated documentation can give teams a useful starting point for understanding large applications. It can also reduce dependence on a small number of experienced developers who hold much of the system knowledge. 

Supporting Modern Development Practices 

IBM i teams can already use tools such as Git, VS Code, and CI/CD. Adding AI assistants to these workflows can make development on IBM i feel more familiar to developers who have worked primarily with modern platforms. 

These tools do not remove the need for experienced developers or proper oversight. They can, however, reduce the time it takes for new developers to become productive and make critical system knowledge easier to access. 

The Cost of Leaving Has Not Changed Much 

AI has made it easier to address some of the challenges associated with staying on IBM i. Moving away from the platform is still a major undertaking. 

Rewrites and platform migrations can involve: 

• Hidden business logic embedded in decades of code. 

• Long project timelines as previously unknown dependencies emerge. 

• Additional costs while the old and new systems run in parallel. 

• Data migration challenges when moving from DB2 for i to another database. 

• Performance and reliability concerns for high-volume transaction processing. 

• Business disruption during the final cutover. 

AI coding tools can support modernization and rewrite projects, but they do not eliminate the risks involved in moving business logic to a different platform. Veracode’s GenAI code security research found that 45% of AI-generated code samples contained security flaws. This reinforces the need for careful review and testing of AI-generated code, regardless of where it is used. 

Re-Running the Exit Business Case 

IBM i leaders who approved an exit plan several years ago, as well as those considering one today, should revisit the original assumptions. The technology landscape has changed and so have the available options. 

A new assessment should consider: 

1. Skills assumptions: Test whether AI-assisted onboarding can help new developers become productive with the existing codebase. A pilot with one or two developers can provide useful evidence. 
2. Documentation gaps: Use AI tools to document critical applications and assess how much this reduces the risk associated with lost institutional knowledge. 
3. Rewrite estimates: If a rewrite is already underway, update the cost and timeline estimates using actual project progress rather than the original assumptions. 
4. Platform costs: Compare the total cost of running IBM i on current Power hardware or in the cloud with the expected cost of the target platform. 
5. Business capability needs: Define what the business needs, whether that means APIs, analytics, AI capabilities, or better user interfaces. Then determine whether those needs can be addressed on IBM i. 
6. Risk profile: Compare the operational risks of a large-scale migration with the risks of continuing to run and modernize IBM i. 

This exercise may show that some of the original reasons for leaving, such as the need for faster change or better integration, can be addressed through IBM i modernization. 

When Leaving Still Makes Sense 

Revisiting the business case does not mean every organization should stay on IBM i. In some situations, leaving the platform is still the better option. 

That may be the case when: 

• A commercial package can meet the business needs more effectively than custom software. 

• The application is small enough to be replaced without significant risk. 

• The company is consolidating platforms after a merger. 

• Its long-term strategy requires capabilities that IBM i cannot provide at a reasonable cost. 

• The existing code is so poorly structured that modernizing it would cost more than replacing it. 

The decision should ultimately be based on business requirements, total cost, and risk. It should not depend on the assumption that IBM i skills cannot be found or developed. 

IBM i Application Modernization as the Alternative 

For many organizations, IBM i application modernization provides a practical middle path between keeping the platform unchanged and replacing it entirely. 

Organizations can: 

• Refactor RPG into free-form, modular code that is easier for new developers to maintain. 

• Modernize data by converting DDS files to SQL DDL and using SQL for data access. 

• Expose APIs so other applications and cloud services can access IBM i data and business logic. 

• Replace green screens with web or mobile interfaces where users would benefit from them. 

• Adopt modern development tools such as Git, VS Code, and automated testing. 

• Connect with analytics and AI platforms through APIs and data pipelines. 

These changes can deliver many of the benefits associated with a rewrite without introducing the same level of migration risk. They also allow organizations to retain the reliability and security of IBM i while gradually improving how the platform is used. 

AS400 Modernization Without a Platform Exit 

The term AS400 modernization still carries some outdated associations. For many executives, AS400 brings to mind green screens, aging hardware, and a platform nearing the end of its life. 

The reality is different. Systems that organizations still refer to as AS400 typically run on modern IBM i versions and Power hardware. They can support SQL, REST APIs, open-source languages, and cloud deployment, while continuing to receive updates from IBM. 

This changes what AS400 modernization can look like. 

Instead of treating modernization as one large project that ends with the platform being switched off, organizations can take a phased approach. The first phase might convert frequently changed programs to free-form RPG and move their files to SQL tables. The next could expose order and inventory data through APIs for a web portal. A later phase could connect transaction data to an analytics platform and introduce AI-assisted forecasting. 

Each phase delivers a specific improvement while reducing risk and building internal skills. The organization can also reassess its platform strategy as it learns more. 

An incremental approach can make funding easier as well. Business stakeholders can see results within months instead of waiting years for a complete rewrite. If priorities change, the modernization program can be adjusted without leaving the organization with a partially completed replacement system. 

Governance for AI-Assisted Development on IBM i 

AI assistants can speed up work on core systems, but they need to be used within clear controls. 

AI-generated explanations should be checked against actual system behavior before they become part of official documentation. Converted code should go through the same testing process as manually modified code, including regression testing with real data where appropriate. 

Changes should also move through source control and code review. Teams should maintain a record of which AI tools were used during development. Sensitive data in test environments should be masked before being provided to tools that send information outside the organization. 

These controls allow teams to benefit from AI without compromising the reliability that makes IBM i valuable. 

What to Expect From an IBM i Modernization Company 

A good IBM i modernization company should help clients evaluate both sides of the stay-or-leave decision. 

That includes: 

• A neutral assessment of modernization and platform exit options. 

• AI-assisted pilots to test assumptions about skills and documentation. 

• Updated cost models for each option. 

• An incremental roadmap that delivers value early. 

• Knowledge transfer so the client develops a better understanding of its own systems. 

iSeries modernization services that promote only one approach, whether that means always staying on IBM i or always leaving it, may not give clients the objective guidance they need. 

Questions for Leaders Considering an Exit 

Before committing to a rewrite, IBM i leaders should ask: 

• What specific business problems is the platform exit supposed to solve? 

• Could those problems be addressed through as400 application modernization? 

• What would an AI-assisted development pilot tell us about the current skills risk? 

• How reliable are the rewrite estimates, and what assumptions are behind them? 

• How will we identify and preserve hidden business logic in the existing applications? 

• What happens to the business if the migration takes twice as long as expected? 

The answers can change the recommendation. 

A Representative Reassessment 

Consider the insurer from the opening example. Its CIO commissions an independent review of the modernization plan. 

The review finds that the remaining IBM i modules can be modernized in place. RPG can be converted to free-form, key files can be moved to SQL DDL, and APIs can be exposed for the new customer portal. AI-assisted documentation can cover the most important programs within a few months, while new developers can become productive on the platform. 

The company then scales back the rewrite and focuses it on the areas where a commercial package offers a clear advantage. 

This approach reduces a significant portion of the remaining rewrite cost while preserving a stable core system that is easier to maintain and integrate. 

An IBM i modernization company should not assume that leaving IBM i is always the right answer. AI tools that explain, document, and convert RPG have changed the skills equation behind many platform exit plans. 

That makes it worth revisiting the business case before committing more money to a rewrite. Current tools, costs, risks, and business requirements may show that AS400 modernization services can achieve the same goals without the disruption of a full platform migration.