The Pension Administration System Is a Forty-Year Record

The plan document is four hundred and twelve pages. The legacy calculation engine is four million lines of code. They agree on most things. The disagreements are the project.

When a pension fund decides to replace its administration platform, the initial project plan assumes the legal documents are the source of truth. Six months into data mapping, the steering committee learns the actual truth: the legacy database is the only rulebook that matters. You are not migrating a database. You are excavating forty years of labor agreements.

In a customer relationship management migration, a ten-year-old phone number is useless. In a pension administration system, a three-month leave of absence recorded in 1986 is a load-bearing variable. It dictates the continuous service multiplier for a retirement happening next month. There is no cold storage. Every row is hot data the moment a member files for retirement.

A steering committee meeting derails when the systems integrator reveals that fourteen thousand member records have a start date of January 1, 1900. The data architects explain it was a default null value used during a migration from microfiche in the early nineties. The business leads realize they have to manually verify the service records of fourteen thousand active workers before the new system can project their future benefits.

The migration unit is not the member record. It is the member’s entitlement history. A clean current balance or monthly payment can hide an unusable history. The project must account for which service periods count, which plan terms applied during each period, and which earlier decisions must still be honored. Clean fields can carry badly interpreted history.

Trustees and legal teams believe the rules live in the bound volumes stored in the legal department. They do not. The actual rules live in the legacy system’s calculation engine. If the plan document describes one method for calculating final average salary, but a patch to the mainframe in 1998 accidentally implemented another, the fund has been paying that rate for decades. The error is now precedent.

A developer opens a legacy program last modified in the late nineties. He scrolls to a specific block of logic handling members who transferred from an old fund. He warns the business analyst not to touch a specific rounding rule because it handles members who were paid in a currency the jurisdiction no longer uses. He knows what the code does. The person who knew why it does it retired fifteen years ago.

A business analyst tracks down a retired developer to understand a hardcoded lookup table containing forty-two member identifiers. The developer explains those people were involved in a specific labor dispute in the nineteen-eighties and were granted a custom accrual rate as part of the settlement. There is no other documentation of this agreement. The mainframe is not just hosting the rules. Through decades of undocumented workarounds, it has become the rules.

The bulk of the budget does not go to software configuration or cloud infrastructure. It goes to the parallel run. The first parallel run does not tell you whether the new system is correct. It tells you how much you do not know.

Parity testing requires cases chosen for rule boundaries, not just a large random sample. You need members immediately before and after amendments, transfers between plans, interrupted service, and partial retirements. A tester compares benefit outputs for a retired member. The old and new systems agree to the cent. Then she changes the retirement date in a test copy by one day, and the results diverge. The agreement was a poor test of the rule; both systems just happened to land on the same side of an undocumented effective-date boundary.

During a conversion rehearsal, a field labeled “service date” contains employment start dates for one predecessor scheme and pensionable-service start dates for another. Both populations look plausible in aggregate. The distinction only appears when someone follows a small set of members through the predecessor files and their first calculations.

When the legacy and new systems produce a payout difference of less than two minor currency units per month, the organization must establish a mathematical tolerance threshold. The new system’s calculation is accepted as the new baseline. Establishing that threshold requires sign-off from actuaries, auditors, and legal counsel, because it technically alters the benefit.

Every migration is a data quality project that happens to end with a new system. But fixing corrupt historical data often breaks the member’s expectation.

If a project team discovers a member was credited with two extra years of service due to a data-entry error a decade ago, correcting that data in the new system means their projected pension drops. The fund sent them an annual benefit statement last year based on the bad data. Clean data is a liability if the dirty data is what you used to promise a member their retirement income. The IT modernization project suddenly triggers a wave of member communications and dispute resolutions.

A data mapping team profiles a text field in the legacy database labeled “Notes”. In thousands of rows, administrators have typed instructions like “do not apply statutory indexation” or “ex-spouse gets forty percent”. The new system requires these to be boolean flags and relational links, not free-text strings. Every unexplained manual adjustment is a rule-discovery task until someone can show otherwise.

The knowledge is not lost. It is concentrated. It lives in three places: the code, the data, and the heads of a few senior staff members who are within five years of retirement.

When the legacy code is too tangled to read, the project team feeds dummy profiles into the old system, records the payout outputs, and hands the input-output pairs to an actuary. The actuary works backward to deduce the mathematical formula the computer is actually using, so the developers can build that formula into the new platform. The actuary becomes the data quality auditor you did not hire.

You cannot test a pension calculation platform by asking if the math is correct. You have to ask if the math matches the mistake you made in 1996.

The first production payrun after cutover is the real go-live. Everything before that is preparation. The new platform will calculate the benefits. It will also begin accumulating its own history, its own undocumented workarounds, and its own gaps between the plan document and the code.

The system of record is the database. The system of truth is the set of rules that determine what the database means. They are not the same system.