IBM i Modernization with IBM Bob: How We Use It to Improve Processes and Architecture

IBM Bob, extended with the Premium Package for IBM i, speeds up the most expensive part of IBM i modernization: understanding decades-old code, planning a change, making it and proving that it works. The business value appears only when a team builds the tool into a disciplined process, where people still own the scope, the sign-off and the deployment.

We walk through that process on a model project at an insurer, in five steps. For each one, we start with the business problem, show what Bob does and what people decide, and end with what changes in the insurer’s processes and architecture.

What Does IBM Bob Do for IBM i Teams?

IBM Bob is IBM’s AI development partner. It does more than suggest code: it can analyze an application, plan a change, carry it out and help test it. The Premium Package for IBM i adds knowledge of the IBM i platform and a direct connection to the system the team maintains.

Bob works in three modes, and each one matches a stage of a modernization project:

• Ask mode explains existing code without changing anything. This is how a team learns what an old application actually does.
• Plan mode turns a goal into an ordered list of steps that people can review before any work starts.
• Agent mode makes the approved changes, runs them and fixes errors.

For IBM i, the most important addition is the Native Connection. Bob works directly with the code and database on a connected IBM i system, instead of developers copying files back and forth. The package also includes four guided workflows, each tied to a common modernization task:

1. Code Modernization: rewrites old-style RPG into the modern format most developers can read.
2. Business Rules Extraction: documents the business rules buried in the code.
3. Unit Testing: plans and builds tests that check the code still behaves correctly.
4. SQL Index Strategy: finds database changes that keep the system fast.

For the wider product picture, see what IBM Dev Day revealed about Bob.

Bob is not autocomplete for legacy code. It is a way to run a whole engineering task, which is why the process around it matters more than the tool itself.

The Scenario: Modernizing an Insurer’s Claims and Policy Core on IBM i (AS/400)

The engagement below is an illustrative example of how we structure an IBM i modernization with IBM Bob.

A mid-sized property and casualty insurer runs claims handling and part of its policy administration on IBM i, the platform many teams still call AS/400. The core has worked reliably for more than 20 years. The pressure comes from the business around it.

Most of the code was written in older styles of RPG, IBM i’s main business language, and data reaches the customer portal and reporting through nightly batch jobs. Three problems keep surfacing:

• Product changes are slow. A new product needs different claims eligibility rules, and nobody can quickly say where the current rules live.
• The portal is a day behind. Customers see yesterday’s claim status, so they call the contact center instead.
• Knowledge is concentrated. Two senior developers who understand the claims logic plan to retire within two years.

The board does not want to replace the core, which matches the approach we describe in modernizing around IBM i without a rip-and-replace. The goal is to modernize the code and open the system while it keeps running.

The skills gap is not one insurer’s problem. IBM i skills ranked as the top concern among the 320 IBM i users who responded to 2026 IBM i Marketplace Survey, ahead of cybersecurity. AI and machine learning was the fastest-rising concern, up from 30% in 2025 to 42% in 2026.

We run this kind of IBM i application modernization in five steps:

1. Extract the business rules before changing anything.
2. Plan small, reversible changes.
3. Make the code readable again, with guardrails.
4. Prove that claims logic has not changed.
5. Connect the core to digital channels.

Step 1: Extract the Business Rules Hidden in Legacy RPG Code

Before anyone changes the system, the business needs to know what it actually does. In the first weeks, Bob works in Ask mode, analyzing the claims programs without changing them, and uses its Business Rules Extraction workflow to draft a readable report of the rules they apply, plus a map of which programs depend on which.

In the insurer scenario, that report covers claims eligibility, reserve thresholds and exceptions kept for older products. Bob produces the draft. Business analysts and the claims team then check it line by line, because the real question is whether the code does what the business believes it does.

This is where process problems surface: the same rule applied differently in two places, or a manual workaround in the claims team that exists only because the system never handled a case. Finding these before any change is far cheaper than finding them after a release.

What this changes for the business: the rules become a shared, documented asset owned jointly by IT and the business. A new developer no longer depends on two people being available.

Step 2: Plan Small, Reversible Changes by Splitting the Claims Monolith into Modules

Large modernization projects fail because too much changes at once. We use Bob’s Plan mode to break the work into small steps, then choose one slice of the system that can be changed, and rolled back if needed, without risk to the rest.

For the insurer, the first slice is claim status and eligibility, because it serves both pressures at once: faster product changes and a fresher portal. The plan makes three architecture decisions explicit:

• Split the claims logic into modules (on IBM i, ILE service programs), so each part can be changed and tested on its own instead of touching one large program.
• Move key data definitions to standard SQL (DDS to DDL), which any modern developer and tool can work with.
• Draw a clear boundary around claim status, so it can be offered to other systems through an API later.

Two people approve the plan before any change: the enterprise architect signs off on scope and technical risk, and the claims process owner signs off on the rules that must not change. That second signature turns “behavior stays the same” into a written acceptance criterion.

What this changes for the architecture: modernization stops being one large, risky project. It becomes a series of small changes, ordered by how easily each one can be undone.

Step 3: RPG Modernization with Guardrails: Making Legacy Code Readable Again

Old RPG code is hard to read for anyone outside a small group of specialists, and that is the real source of the skills risk. In this step, Bob rewrites the selected code from the old fixed format into modern free-format RPG and tests it on a development system, while engineers review every change.

The guardrails are part of our working standard, not an afterthought:

• Development and test systems only. Bob never connects to production.
• People approve actions. We start with restrictive permissions, so Bob asks before it runs anything on the system, in line with IBM’s own auto-approve guidance.
• Sensitive data stays out of reach. Files with policyholder data are excluded from what Bob can read.
• Team standards apply automatically. Our coding conventions are written into Bob’s project rules, so the result looks the same whoever runs the session.

Engineers also make the calls the tool cannot make alone, where old code carries business meaning that a straight conversion would lose.

What this changes for the business: the claims code becomes readable for a much wider pool of developers, which addresses the skills gap directly instead of working around it.

Step 4: Prove Claims Logic Has Not Changed with Regression Tests and Parallel Runs

For an insurer, a modernized system that calculates one claim differently is worse than no modernization at all. Every change is therefore verified before it moves on. Bob helps prepare the tests, but the proof is the test results, not the fact that a change was generated.

Verification has four layers:

1. Unit tests check each module on its own, prepared with Bob’s Unit Testing workflow and reviewed by an engineer.
2. Regression tests run the system on anonymized, production-like claims data.
3. Parallel runs process the same claims in the old and new versions and compare the results case by case.
4. Business sign-off from the claims process owner confirms the rules documented in Step 1.

Performance gets its own check: Bob’s SQL Index Strategy workflow reviews how the Db2 for i database performs, so customers and claims staff do not notice slower response times after the change.

What this changes for the business: a change to the core becomes predictable and auditable. In a regulated industry like insurance, that evidence matters as much as the change itself.

Step 5: Connect IBM i to Digital Channels with APIs and Change Data Capture

Once the claims logic lives in clean modules, other systems can use it directly. We add an API for live requests and stream data changes to modern platforms, without adding load to the core.

In the insurer scenario, the architecture changes in two ways:

• A REST API for the portal. The portal asks the core for claim status directly, instead of waiting for last night’s batch file.
• Change data capture for everything else. Every update to claims data is read from the database’s own change log as it happens and streamed, for example through Kafka, to analytics and other systems, so they work with near real-time data. We describe this pattern on our page on log-based CDC from IBM i journals.

The tool has a clear boundary here. Bob helps write and test the code, but it is not part of the integration platform and does not run production data flows. Architecture, security and operations stay with the team.

What this changes for the architecture: the core stays on IBM i, but it stops being the bottleneck for digital channels.

How IBM i Modernization Changes Claims Processes, Change Lead Time and Knowledge Transfer

The biggest change is not faster coding. It is predictability: the business knows where its rules are, what a change will involve and when data will be available.

Area	Before	After	What we measure
Business rules	Held in code and in a few people’s heads	Documented, confirmed by the claims team	Share of claims programs with confirmed rules
Product change lead time	Long analysis before every change	Analysis starts from the rules report	Time from request to production
Claim status in the portal	Updated overnight	Near real time	Data delay, related contact-center calls
Developer onboarding	Depends on two senior developers	Readable code and documentation	Time to a new developer’s first reviewed change
Change audit trail	Scattered across tickets	Plan, approvals and test results for each change	Completeness of evidence per release

We set a baseline before the project starts and track it with process data plus Bob’s own usage and cost reporting, so the client judges the work on its own numbers rather than on vendor claims. If claims handling itself is the next target, the same baseline feeds into claims process automation.

IBM Bob Security, Governance and Pricing: What to Check Before You Start

Bob proposes and carries out work, but decisions about scope, approval and deployment stay with people. The table shows how responsibility splits across the five steps.

Step	IBM Bob	Engineers	Business owner
1. Business rules	Drafts the rules report and dependency map	Check technical accuracy	Confirms the rules
2. Planning	Breaks work into steps	Choose the slice, sign off risk	Signs off rules that must not change
3. Code modernization	Rewrites and runs code on a dev system	Review every change	Kept informed
4. Verification	Drafts test plans and tests	Run regression tests and parallel runs	Signs off results
5. Integration	Helps write and test code	Design and operate APIs and data streams	Defines data needs

Before you start, check five things:

• Access scope. Connect Bob to development and test systems only.
• Permissions. Start restrictive, and keep human approval for anything Bob runs on the system.
• Security history. Review the prompt injection issue IBM patched in Bob’s command-line tool in 2026, covered in our Dev Day analysis.
• Licensing. The IBM i package is an add-on to a Bob subscription. As of October 2026, IBM lists it from USD 40 per authorized user per month on the individual plan, with enterprise pricing through IBM sales.
• Deployment. IBM offers SaaS and on-premises options, which matters when policyholder data is regulated.

Planning an IBM i Modernization with AI?

We start where this article starts: understanding your system and choosing the first slice worth changing. Then we connect code modernization with the integration work that makes it pay off, including APIs and real-time data.

Let’s map the first slice of your IBM i core!