Insure90 Migration & Decomissioning: How to Preserve and Access Historical Data

If your policy administration system still opens with green-screen menus and your DBA is the only person who remembers what F4=Prompt does, you are dealing with a familiar insurance IT problem.

This is hardly unique to Insure90. Deloitte’s research on life and annuity insurers found that the share of carriers intending to upgrade or enhance existing core systems rose from 36% in 2017 to 73% in 2022, highlighting how deeply legacy cores remain embedded in insurance operations.

The problem isn’t that Insure90 still works. It’s that decommissioning it without a real historical data strategy is how insurers end up producing system not available instead of a policy document during a regulatory audit.

This piece goes deep on the actual engineering problems an Insure90 migration; packed decimal fields, EBCDIC encoding, undocumented RPG business logic, and what migration experts misses.

What Is Insure90?

Insure90 (also referred to as I90) is an insurance ERP built on CREATE90, a development framework native to IBM’s AS/400 midrange platform. That heritage matters technically: Insure90 environments run on DB2/400, store data in physical and logical files rather than conventional relational tables, and lean on RPG and CL programs, with subfile-based green-screen interfaces to handle policy, billing, and claims processing.

Why Are Insurers Still Running It in 2026

Insurers kept these environments running for the same reason most core insurance platforms outlive their intended lifespan: the system is deeply embedded in daily operations, integrations were never fully documented, and nobody wants to be the person who signs off on a cutover that loses a decade of policy history.

That caution is rational. What isn’t rational is running a full AS/400 environment; licensing, hardware refresh cycles, and a shrinking pool of RPG/CL talent, purely to preserve read access to historical records.

The Real Cost of Keeping Insure90 Alive Just for Historical Data

Enterprises typically spend between $100,000 and $250,000 annually to maintain records in a single legacy application, largely because insurers are forced to keep aging systems running to satisfy retention requirements even as the application’s performance and support quality decline.

For an AS/400-based system like Insure90, that number climbs further once you factor in IBM i licensing, disk subsystem maintenance, and RPG/CL contractor rates: a shrinking, aging talent pool that commands a premium.

None of that spend buys the business anything new. It’s pure cost-to-preserve: you are paying full production-system rates to keep a read-only archive online. The focus should be on why we are still paying high costs to maintain data that nobody actively uses.

The Technical Challenges Inside an Insure90 Migration

Migrating legacy data sounds simple until you’re staring at a DB2/400 physical file with zoned decimal fields and no data dictionary. Here’s what actually breaks.

EBCDIC to ASCII/Unicode Conversion Isn’t a Checkbox

AS/400 systems store character data in EBCDIC, not ASCII or UTF-8. This is a recurring, practical headache for anyone who has pulled data off one of these systems: a straight file transfer only handles the EBCDIC-to-ASCII conversion for character data: every other translation, especially packed numeric fields, has to be handled manually.

Get the code page wrong (variants like Cp500 and IBM1047 are common culprits) and you silently corrupt currency fields, dates, or policy numbers without any error being thrown.

Packed and Zoned Decimal Fields: Where Insure90 Migrations Actually Break

This is the single most common technical failure point in Insure90 and AS/400 migrations generally. Packed decimal fields store two digits per byte in a proprietary binary-coded format, and when they’re extracted without the correct interpretation logic, they don’t fail loudly; they produce plausible-looking but wrong numbers.

Pull raw AS/400 binary data onto a Windows or Linux box without the right unpack logic and you get wildly different decimal values depending on which bytes get interpreted as the packed sign nibble, with no clean algorithm evident from the raw hex alone.

The same issue shows up on the database side: run a SQL query against packed decimal fields that have landed in a modern relational database without proper conversion, and the values come back meaningless, because the target platform never natively understood the two-digits-per-byte packed format to begin with.

The fix is consistent every time it comes up: unpack the field into a portable representation before it ever leaves the source system, not after.

For Insure90 specifically, where premium amounts, reserve balances, and commission calculations are near-certainly stored as packed or zoned decimal, this isn’t an edge case. It’s the default state of the data, and every field needs explicit digit-length and decimal-position mapping before extraction, not after.

Undocumented Table Relationships and Buried Business Logic in RPG/CL

Insure90’s business rules: how a policy renewal recalculates premium, how a claim reserve is adjusted, how commission splits are validated, frequently live inside RPG and CL program logic rather than in any data dictionary or schema documentation.

The most common reverse-engineering questions in this space are strikingly consistent: how to trace a logical file back to the physical file it’s built on, how CL programs read keyed files, how referential integrity is (or isn’t) enforced across transaction and master files.

When none of that is documented, migration teams end up decompiling business rules from decades-old compiled programs instead of reading a spec.

Subfiles, Logical Files, and the Myth of a Clean Schema Map

Insure90’s UI layer runs on subfile-driven green screens, and its data layer typically has multiple logical files (indexed views) layered over a smaller number of physical files. A migration team that maps only the logical file structure; the thing visible in the UI, routinely misses derived fields, hidden select/omit logic, and multi-record-format physical files that don’t correspond 1:1 to any single table in the target system.

Migration vs. Archiving: Why Moving Insure90 Data Isn’t Enough

Migrating to the new core system and preserving historical data are not the same project. Industry-wide, the majority of insurers running core system transformation programs report they have not been able to fully retire even one legacy claims, policy, or billing system.

This is the “zombie legacy system” scenario, where the old platform stays online indefinitely because nobody built a proper archive for it, is the norm rather than the exception.

The better-run programs treat this as two distinct tracks: actively-used data gets migrated into the new policy administration system, while closed policies, settled claims, and historical records get archived separately.

Insurers that have taken this approach report prioritizing active policies and open claims for migration first, while archiving closed and historical claims separately for compliance and reporting purposes, with archived historical data becoming fully accessible within 24 hours of the archiving step.

That’s the operating model Insure90 decommissioning programs should be benchmarking against, not a single big-bang cutover that tries to force forty years of policy history into a new PAS schema.

A Technical Framework for Insure90 Historical Data Preservation

A defensible Insure90 decommissioning program generally runs through five stages, and skipping any of them is where programs get into trouble:

1. Discovery and data profiling. Map every physical file, logical file, and record format, including ones with no active UI reference, before writing a single extraction script.
2. Format-aware extraction. Pull data with explicit EBCDIC code-page handling and explicit digit-length/decimal-position definitions for every packed and zoned field, not a generic FTP or bulk copy.
3. Transformation and reconciliation. Convert to modern types, then validate row counts, control totals, and sample-level field accuracy against the source system before anything is considered “migrated.” Programs that use a phased, sprint-based extraction and validation model rather than a single bulk pass consistently report cleaner reconciliation outcomes.
4. Immutable, compliant storage. Land the reconciled data in WORM-protected storage with cryptographic hashing so the archive itself becomes evidentiary, not just a database copy that could theoretically be altered.
5. Staged decommissioning. Insure90 modules come offline only after their corresponding data has been validated in the new environment, mirroring the staged-validation approach used in comparable core insurance system replacements, where legacy modules are retired incrementally as each one is confirmed rather than on a single fixed date.

Compliance and Retention Obligations You Can’t Decommission Away

Powering off Insure90 does not power off your retention obligations. Insurance data is subject to layered requirements: state insurance department retention rules, and for insurers offering investment-linked products, SEC recordkeeping, retention, and accessibility requirements that apply directly to those product lines. None of those obligations pause because the AS/400 box in the data center got decommissioned.

If you retire the system without properly archiving its data, your audit risk can actually increase. A regulator or litigant asking for a 12-year-old policy file will not accept the system being gone as an answer, and recovering a single record from tape backup under deadline pressure can cost far more than archiving it properly from the start.

How Archon Approaches Insure90 Decommissioning and Historical Data Access

Moving data out of an AS/400 environment is only half the job. The other half is making sure that data is still trustworthy, searchable, and legally defensible years after the platform is gone. That’s specifically where Archon is built differently from a generic ETL or migration consultancy.

Archon’s Lakehouse-native architecture is purpose-built for this exact scenario, not retrofitted from a transactional database product.

With 200+ pre-built connectors and 1,000+ transformation rules, Archon handles the AS/400-specific extraction work: EBCDIC decoding, packed and zoned decimal interpretation, subfile and logical-file mapping, as a configured, repeatable process rather than a one-off scripting exercise every migration team has to reinvent.

Once Insure90 data lands in Archon, it’s written with WORM/immutability at ingestion, so the archive itself stands up as evidence, not just a convenient copy. Cross-application search means a compliance or claims team can query historical Insure90 records from a centralized archive, instead of maintaining separate silos.

And because retention and legal hold orchestration is built into the platform, records stay protected exactly as long as regulation requires; no longer, no shorter, without anyone having to manually track expiration dates in a spreadsheet.

For insurers deciding between a Lakehouse-based archive and continuing to lean on native AS/400 retention tools or a database-centric archiving approach, the technical gap is capability, not just cost: native retention tools weren’t designed to reconcile packed-decimal legacy formats against modern schemas or to provide cross-system search across a genuinely heterogeneous data estate.

That’s the gap Archon is built to close.

Still keeping Insure90 online just to access historical records? Let’s see what it would take to move that data into a searchable archive and finally retire the system. Plan Insure90 Decommissioning with Archon