Over the past few years, we have spoken with and worked alongside insurers who run their policy, billing and claims systems on the IBM i, still widely called the AS400. Some wanted to modernize it, some wanted to replace it, some only wanted to know whether the system they had worried about for years was as risky as it felt.
The same questions came up in almost every conversation, and so did the same mistakes. This article collects what we heard and saw while working with them.
And if you’re already in the middle of a decision and need answers sooner, you can talk to our IBM i experts directly by picking a time slot that works for you.
Why the AS400 Still Runs So Much of Insurance
With 95% of IBM i users in one annual survey saying the platform delivers better ROI than other servers, the problem is clearly not that the system cannot do its job.
In many insurance companies, it still does that job extremely well. It rates quotes, issues policies, runs billing cycles, keeps claims history, and processes large volumes of transactions with very little day-to-day attention.
So the real problem is not the AS400 itself.
It is how the business around it has evolved.
A new state, an acquired book of business, a digital agent portal, or a new security requirement can mean changing programs that fewer people know how to work with safely. In many cases, the business rules inside those programs have also been built up over years and are not fully documented.
That is where things get difficult. The system may still be reliable, but the question is whether the organization can change it, connect it, and extend it fast enough for what the business needs now.
So for most insurers, the real question is not:
“Does the AS400 still work?”
It is:
“Are we using it in a way that still works for the business today?”
What We Learned Before We Recommended Anything
Whenever an insurer came to us with an AS400 question, we did not begin with, “You should modernize,” or “You should migrate.”
We first tried to understand what the business was actually depending on.
That matters because two insurers can be running very similar IBM i environments and still need completely different answers-:
- One may only need cleaner integrations.
- Another may have undocumented business rules buried in custom programs.
- A third may genuinely be ready to move away from the platform.
So before suggesting a path, we worked through six questions. Each one became a lesson below.:
Lesson 1: The rules that matter most are not always the ones written down
One of the first things we wanted to know was where the rules actually lived in AS400. Every insurer runs on rules:
- How long a customer gets to pay late.
- When a reminder goes out.
- When a policy is marked as lapsed.
- How much a customer gets back if they cancel.
On the AS400, some of these rules are written down in the system where anyone can see them.
Other rules are not written down anywhere you can read. A developer built them into the AS400's programs years ago, and they run quietly in the background every night. Think of a senior employee who just knows that "if a customer misses two payments, send a letter and change the policy status." It works every day. But nobody can point to where the rule is written, and the person who set it up may have left.
Both kinds of rules matter, but they are not equally easy to move.
A rule that is written down in the setup can be carried forward easily. A rule that is inside the old AS400 programs has to be found and understood first. Otherwise, the new system will not behave the same way, and customers will notice.
So before anything else, we made a list of the rules and where each one lived on the AS400:
- How products work
- How a policy changes status (active, lapsed, cancelled)
- How customers are billed
- How policies renew each year
- How amounts are calculated
- The nightly tasks that tie it all together
That list showed us what would move easily and what needed careful work. It also changed how we planned the project: finding the rules became its own piece of work, instead of something we assumed would take care of itself.
Lesson 2: Customization is normal, but forgetting why it was done is the risk
Customization is very common in AS400 environments, and that is not necessarily a problem. What we wanted to understand was how much had changed over time, and whether anyone still remembered why those changes were made.
It usually starts small. An insurer partners with a bank to sell a savings plan. The bank's customers need a longer grace period before a policy lapses, so a developer adds a new status code and a small batch job just for those policies. It works, the partnership grows, and nobody thinks twice about it.
Then more requests come in. A regulator changes the rules on premium reminders, so someone adds an exception for one product line. Finance wants a special month-end report for the bank's policies, so another job gets written. Each change is reasonable on the day it is made.
Large reporting changes work the same way. For many insurers, accounting rules such as IFRS 17, or LDTI under US GAAP for larger public insurers, both took effect in 2023 and meant new ledger and report changes on core systems. Changes like these arrive with a fixed deadline, so the real question for a modernization is whether anyone can still explain how those ledger entries and reports are calculated. A good place to start is to ask which reports and ledger calculations changed for these rules, who owns each one, and where the logic is written down. If the answers are vague, finding and documenting that logic belongs in the project plan.
A decade later, there are dozens of these changes. Very few are written down, and the people who made them have moved on or retired.
A handful of local statuses or extra jobs is easy to deal with. Years of custom programs, special codes and workarounds that nobody documented are a different matter. In a modernization or migration, each one has to be found, understood, and then rebuilt or retired. The ones nobody knows about usually show up late, when a policy behaves differently in the new system than it did in the old one.
That is why we checked this early. It gave us a fairly honest picture of how much work a modernization or migration would really take. It also changed how we scoped the work: we asked for a change history before estimating, and priced undocumented customizations as a range.
Lesson 3: The overnight batch is often the real backbone of the system
We also looked closely at what was happening after business hours.
Not because the insurer needed us to explain batch processing to them, but because we had to understand what a recommended solution would need to preserve.
Renewals, premium billing, lapsation, commissions, maturity processing, and ledger updates often run through overnight batch jobs on the AS400. In many environments, those jobs depend on one another, and a failure early in the sequence can affect everything that follows.
So before recommending modernization, migration, or any other change, we wanted to make sure we understood:
- which jobs run first and what depends on them,
- where the process can safely restart if something fails,
- how long the full batch window takes,
- how much time is left before the business day begins,
- and who knows how to intervene when something goes wrong.
The reason was simple. Any new solution had to reproduce the important dependencies, timing, and recovery behavior, not just the visible application.
In quite a few AS400 environments we saw, the overnight batch turned out to be one of the most important parts of the system to understand before deciding what should change and what should stay exactly as it was. That is why we mapped batch dependencies and restart points before choosing a target platform. The batch window set the constraints, so any platform that could not run the full sequence and recover from a failure before the business day began was not a realistic option.
Lesson 4: The data reaches further than anyone remembers
Another thing we learned was how intricate the data can be. An AS400 holds years of policy, client, coverage and accounting records, and at first glance that looks like one tidy store. It rarely is, because the data has been shaped by everyone who has used it over time.
Three things made it more complex than it appeared:
- Age and history: Records go back many years and carry the rules and formats of different periods. A client record from a decade ago may follow different conventions from one created last month.
- Quality: Duplicate clients, half-complete records and fields filled in differently by different teams are common in long-running systems. These gaps stay hidden until someone tries to move the data.
- Reach: The data rarely stays in one place. Over the years, other people and systems start drawing from it. A finance analyst pulls a weekly extract into a spreadsheet. The agent portal reads policy status every morning. The claims system checks coverage. The finance platform picks up accounting entries each night. Each of these started as a small convenience, and most were set up by someone who has since moved on.
Here is a simple example of how this plays out. A team in sales operations builds a spreadsheet that pulls policy and premium data from the AS400 every Monday. Over time, regional managers use it to track their targets, and leadership begins quoting its figures in review meetings. It appears in no system diagram and no project plan, so nobody lists it as something that depends on the old system. If the system changes format or moves, the report breaks, and nobody knows why until someone asks where the numbers went.
That is why we looked at the data itself and also at who consumes it and how:
- Which reports, spreadsheets and extracts read from it
- Which applications, portals and finance systems connect to it
- How each one gets the data, whether through a direct connection, a scheduled file or a manual export
- Who owns each one, and what the business would lose without it
Finding these dependencies early meant we could size the work correctly and decide the order of the move before committing to an approach. Without that, we would have scoped only the core system and found the reports, portals and finance feeds that depend on it after go-live, when fixing them costs the most.
So in practice, the consumer list became the starting point for the estimate. We sized the work outward from it, counting each report, feed and connection as its own piece of work, with an owner who could say what the business would lose without it.
Lesson 5: Fixing the connections is often the fastest way to create value
Scoping the integrations was another thing we made sure to do before recommending any path.
An insurer’s policy data rarely stays inside the AS400. It may need to reach the claims system, agent portal, payment gateway, finance platform, reinsurers, analytics teams, and external partners. So we traced how each of those connections actually worked.
And they were not always as straightforward as they looked.
Some were clean, structured integrations where systems exchanged data automatically. Others relied on nightly file drops, scheduled extracts, spreadsheets, or even someone taking information from one screen and entering it into another system manually.
So for every important connection, we wanted to know:
- Where is the data coming from and where is it going?
- How does the claims system receive what it needs?
- What feeds the agent portal and payment systems?
- What information moves to finance, reinsurers, analytics, or external partners?
- Is that exchange automatic, or does someone still have to step in?
We checked this because the right recommendation had to account for everything already depending on the AS400, not just the core application itself.
In some cases, that mapping showed us that the system did not need to be replaced at all. Improving the integrations around it was enough to remove a large part of the friction.
It also changed the options we brought to the insurer. Fixing the connections became a path to compare against replacement, and the manual steps showed where to start, because each one could be improved whether or not the core system changed.
I Think You’ll Relate to This
A leading insurer had an AS400 core that was still doing its job well, but the systems around it had moved on. Credit checks, credit reporting, and digital payments needed faster, cleaner connections.
Instead of replacing the core, the team enabled secure real-time APIs around it and kept the AS400 doing what it already did best.
Lesson 6: Knowledge risk can matter more than technology risk
One of the most important questions we asked was who really understands the AS400. We were not looking for a name on an org chart. We wanted to find the people who could answer three things.
- Why does a particular rule exist?
- What do you do when the overnight batch fails halfway?
- Why does an old program handle one product differently from all the others?
In many insurers, that knowledge sat with two or three people, and some of them were close to retirement. Very little of it was written down. The system kept running because those people remembered things, not because the knowledge was recorded anywhere.
At that point the problem was no longer only technology, it was knowledge risk. If one of those people left, the insurer would lose the ability to explain its own system, and any later modernization or migration would have to start by rediscovering rules that had been known all along.
This changed the order of our work. In some cases, documentation and knowledge capture had to come first, before the conversation about modernization or migration went any further. We recorded the rules, the batch recovery steps and the special cases while the people who knew them were still available. That gave the insurer a safer starting point whichever direction it chose next.
That also gave the platform decision firmer ground. Estimates, vendor conversations and the comparison between options could draw on written rules and recovery steps, so none of them depended on someone’s memory of how the system behaves.
Read more: A healthcare technology company could not easily change its AS400 claims application because RPG skills were scarce, and claim backlogs kept growing. See how we documented the system first and delivered the first release of its replacement in five months.
Before You Modernize or Migrate: AS400 Readiness Checklist
Go through this checklist with your business and technology teams together. For each question, answer yes, no or not sure. The "no" and "not sure" answers show where to look first.
Do you know what your system decides on its own?
- Can you list the rules for late payments, lapsing, reinstating and cancelling a policy, and say where each one is set?
- Do you know which rules are written down in the system setup, and which are hidden inside custom programs?
- Are your products (what they cover, how premiums and payouts are worked out) written down somewhere outside the system?
- Do you know where state-specific or regulatory rules are applied?
Do you know what has been added over the years?
- Do you have a list of every special status, program and nightly job added since the system went live?
- Can someone explain why each one was added, and for which product or partner?
- Do you know which changes came from partnerships, acquisitions or new regulations?
- Is there any product or state that behaves differently from the rest, with nobody sure why?
Do you know what runs after everyone leaves?
- Do you have one page that shows every overnight job and the order it runs in?
- Do you know which jobs must finish before others can start?
- Do you know where a job can safely restart if it stops halfway?
- Do you know how long the full overnight run takes, and how much time is left before the working day begins?
- Do month-end, quarter-end and year-end runs have their own written steps?
Do you know who relies on your data?
- Do you know how many duplicate or half-complete client and policy records you have?
- Do you know which reports, spreadsheets and data pulls depend on the AS400, including ones individual teams built for themselves?
- Do you know which finance, claims, reinsurance and analytics work would stop without this data?
- Does each of these have a named owner?
- Do you know how long you must keep old policy and claims records?
Do you know how information gets in and out?
- Have you mapped how the claims system, agent portal, payment gateway, finance system and reinsurers each receive their data?
- For each one, do you know whether the data moves automatically, through a nightly file, or by someone doing it by hand?
- Is anyone retyping information from one system into another?
- Do you know which connections slow down quotes, claims or agent service today?
Do you know who can explain it?
- Can you name the people who understand why your rules work the way they do?
- Do you know how many of them there are, and whether any are close to retirement?
- Is there written guidance for fixing a failed overnight run?
- Could a new team member learn your special cases from documents alone, without needing to ask a person?
If the checklist left you with more "not sure" answers than you expected, let's talk. We can go through it together and help you decide what to do next with your AS400.
Planning Your Next Step
Skills concerns are a likely reason the share of organizations planning to move some or all applications off IBM i rose from 18% to 24% in the latest Fortra survey. For insurers the risk is sharper, because years of customization mean the rules, special cases and overnight jobs that keep your policies, billing and claims running often sit with two or three people, and every year that knowledge stays undocumented, the next decision gets harder and riskier.
You do not need to decide today whether to modernize, rehost, refactor or migrate. You need a clear picture of what your AS400 does, what depends on it and who can explain it. The checklist above is the place to start, and at Nalashaa, our IBM i experts can help you sort out the rest.
Book your free 30-minute consultation
Frequently Asked Questions
Can you document our AS400 if nobody has written down how it works?
Yes. This is common in insurance, where rules, status codes and special cases have built up over years with little written record. Our IBM i documentation service covers the data dictionary, data model diagrams, process and task flows, integration details, roles and permissions, and change procedures. We also use AI-assisted code analysis to surface rules and dependencies hidden in old programs, and an IBM i engineer reviews everything before it is used.
How can we connect our AS400 policy system to an agent portal, claims system or finance platform without replacing it?
Through integration around the core. Depending on the system and the data, we use APIs, ready-made connectors or a mix of both, so the AS400 keeps running while other systems read from it and write to it. This often removes manual re-keying and nightly file transfers, which is where many insurers lose the most time.
Can you help stabilize our overnight batch runs?
Yes, from two directions. Our support team handles batch failures, job queue problems and performance issues, with 24/7 coverage. Our automation work uses AI to map job dependencies that were never documented and to flag jobs that are slowing down or likely to fail. For renewals, billing, lapsation and commissions, this means fewer surprises before the working day starts, and every change is tested in parallel and signed off by an IBM i engineer.
