The Reconciliation FilesNon-lifeAS/400 · DB2
FILE 02

The Dead Data Graveyard

Case Summary
Legacy core
AS/400 + DB2, 40 years in production
Access paths reconstructed
~340 load-bearing, of several thousand
Median claim lookup
48s → under 200ms
Nightly batch window
9+ hrs, missed SLA → back to ~90 min
Migration scope
Legacy data + opening balances only
Legacy data availability
Guaranteed under SLA

Correct, and Completely Unusable

We hit go-live on a Sunday night in March, eleven months after signing the business case. Every number reconciled — we'd already been through that fight with the data, months earlier, and won it. Every technical provision, every claims reserve, every policy balance matched the legacy platform to the centime.

By Tuesday morning, our call centre had a queue of four hundred people because looking up a single claim took forty-eight seconds. By Thursday, our nightly batch — renewals, reinsurance ceding, the regulatory extract our compliance team files monthly — hadn't finished by 6am for three nights running. Friday, our Head of Compliance was five hours from explaining to FINMA why a scheduled submission would be late, because a batch job that used to take ninety minutes hadn't finished in nine hours.

We hadn't broken anything. We'd built a technically correct system that was, for all practical purposes, unusable.

Forty Years of Tuning You Never See

Here's the part nobody put in the business case. Our AS/400 had been running the same core policy and claims platform for just over forty years. In that time, it had accumulated something no data migration project ever accounts for: forty years of index tuning.

Every access path on that system — which fields to index, which composite keys mattered, when to force a table scan versus an index lookup, which encoded vector index to build for which reporting job — had been decided empirically, one production incident at a time, by people who mostly weren't at the company anymore. None of it lived in a design document. All of it lived in the DB2 catalog, in access path statistics nobody had exported, and in the muscle memory of two DBAs who'd long since moved into consulting.

We had migrated forty years of data. We had not migrated forty years of knowing how to read it fast.

$ explain --compare policy_lookup_by_claim
>>> legacy runtime — AS/400 · DB2 for i
access path: EVI_CLAIM_POLICY_XREF
rows scanned: 4,200 · elapsed: 0.04s
>>> target platform — post-migration, pre-remediation
access path: none matched
rows scanned: 214,000,000 · elapsed: 48.0s
⚠ full table scan · access path never rebuilt, never documented
>>> delta: 1,200× slower — same query, same data

What We Tried First

We did the obvious thing: we sized the target infrastructure the way every vendor calculator wants you to — off data volume. Terabytes in, compute and storage out. It's a reasonable method for a system with no history. It's the wrong method for one with forty years of it.

We over-provisioned compute to roughly three times what the workload actually needed, on the theory that raw horsepower would cover for the indexing we didn't have. It still wasn't enough for the queries that mattered most, because no amount of compute fixes a full table scan across two hundred million rows. We spent six figures on infrastructure we didn't need, and still couldn't tell you, with any confidence, whether we'd sized right for the queries that actually mattered.

Bringing In an AI Managed Service

What changed things was bringing the same AI Managed Service that had reconciled our data back in for a second pass — this time pointed at the AS/400's runtime behaviour, not just its stored procedures. It pulled access path statistics, query optimizer logs, and years of RUNSTATS history off the legacy platform, and reconstructed something we'd never had in any document: an empirical map of exactly which access paths carried real production weight, for which queries, at which volumes, and how that had shifted as our book of business changed over four decades.

A Performance Picture I Could Finally Defend

That map is what let us size correctly the second time. Not a guess dressed up as a sizing spreadsheet — an actual, evidenced answer to "what does this system need to be fast for the workload it actually carries," built from forty years of real access patterns instead of a vendor's rule of thumb.

We rebuilt the target platform's indexing strategy around roughly 340 access paths the data showed genuinely mattered, out of several thousand nominal indexes accumulated over four decades. Median claim lookup went from forty-eight seconds to under two hundred milliseconds. The nightly batch that had ballooned past nine hours came back down to roughly ninety minutes — right where it had been on the AS/400.

Data I Could Finally Ask Questions Of

The second benefit, again, surprised me. A system too slow to query in under a minute is a system nobody runs ad hoc analysis against — so for three years, our claims and pricing teams had quietly stopped asking questions they used to ask weekly. Fraud-pattern clustering. Renewal behaviour by segment. Loss ratios by channel, refreshed same-day instead of at quarter-end.

Once the AI Managed Service had both the logic and the performance profile in hand, that data went from technically present to actually usable — queryable in plain language, fast enough to explore rather than schedule. We found two claims-handling segments quietly running loss ratios well outside appetite for eighteen months, invisible not because nobody was looking, but because looking took long enough that nobody kept doing it.

Why We Could Finally Go Greenfield

This is the part that made the migration actually work. Once the AI Managed Service stood behind the legacy estate — not just reconciling the data, but serving the deep archive under an SLA that guaranteed it would stay available and fast enough to query on the rare occasions anyone needed forty-year-old history — we stopped trying to migrate, and re-tune, four decades of data we mostly never touch.

We sized and indexed the target platform for the book of business that's actually live: current policies, open claims, the retention window our regulators and our own operations genuinely need at speed. Everything older sits with the AI Managed Service, reconciled, indexed on its own terms, answerable in seconds if anyone asks. My infrastructure team designed for the system we actually run today, not a system-shaped replica of everything that ever happened on the AS/400.

We hadn't inherited a slow system. We'd inherited a system with no memory of how it used to be fast. I signed off on that platform twice — once for correctness, once for speed. The second sign-off is the one that actually mattered to the four hundred people who'd been sitting in a queue. It taught me that a migration isn't finished when the numbers match. It's finished when nobody notices it happened at all.

1,200×Faster median claim lookup
~340Load-bearing access paths rebuilt
9+hrs→90mNightly batch window restored
0Restatements filed