Public Pension Administration Software: How Do You Replace a Mainframe Whose Benefit Formula Nobody Dares Touch?

The formula nobody will touch

A benefits analyst is calculating a retirement for a member hired in 1991, who moved between two employers in the system, purchased four years of military service in 2003, took a refund and repaid it in 2008, and worked a final year at reduced hours. The calculation depends on which tier the member falls into by hire date, what the multiplier was under the statute in force for each period of service, how final average compensation is defined for that tier, and whether the service purchase counts toward eligibility as well as benefit amount.

The system produces a number. Nobody in the building can fully explain how it got there, because the logic lives in code written across three decades by people who have retired. So the analyst calculates it again by hand in a spreadsheet, and if the two agree within a few dollars, the number goes out. That parallel manual calculation is the actual control, and it is performed by a small number of people who are themselves approaching retirement.

That is the real driver of these programmes. Not user experience, not cloud strategy. Institutional knowledge that is walking out the door, encoded in a language nobody hires for.

Why this category is unlike every other build

Three things make public pension administration different. First, the rules are statutory and they change with each legislative session, and changes usually apply prospectively to some members and not others, creating another tier. A system with five tiers today will have six after the next session. Second, the calculation must be reproducible decades later, because a member can dispute a benefit years after retirement and the system must show how the number was derived under the law as it stood. Third, the data spans an entire working career, so the migration is not a data transfer, it is an archaeological project across formats, employers and eras.

Any vendor or developer who talks about this like an enterprise system replacement without addressing those three points has not done one.

Where Sagitec, Vitech and LRS actually sit

Sagitec Neospin, Vitech V3locity and LRS are the established names and they have delivered real systems for real retirement systems. They bring domain frameworks, implementation experience and staff who have seen a benefit calculation engine before, which is worth a great deal. If your board wants a single accountable vendor with a track record in public sector procurement, this is a legitimate path and we would not argue against it.

The honest concerns with the packaged route are the ones every retirement system already knows about. Implementations run long, frequently longer than planned, because the configuration effort to express your specific statute is enormous. The resulting configuration is often as opaque as the mainframe code it replaced, just newer, and it lives with the vendor's staff rather than yours. And each legislative session becomes a change order with a price and a lead time, which is a difficult position for a system whose rules change by law rather than by choice.

The custom path is not automatically better. It is better when the calculation engine is treated as the deliverable and is built to be readable and testable by your own analysts, and when your system commits to holding the domain knowledge internally rather than renting it.

Problem one: the calculation engine is the system

Everything else is workflow. The engine is the risk. It has to express the benefit formula per tier per statutory period, apply eligibility rules that differ from benefit accrual rules, handle service purchases with their own crediting logic, handle reciprocity with other systems, and compute optional payment forms with actuarial factors that themselves have effective dates.

What a build must do is make each rule a versioned, effective dated, individually testable unit with a citation to the statute or the board resolution that created it. Then every calculation stores which rule versions produced it. When a member disputes a benefit in 2041, the system reproduces the 2027 calculation using the 2027 rules, not today's.

The second requirement is a regression suite built from real historical cases. Before any release, the engine recalculates thousands of members whose benefits were computed by the legacy system and reports every difference. Some differences will be legacy errors and that is exactly what you want to find, deliberately, in a controlled way, rather than discovering them one member at a time.

Problem two: employer reporting is the data quality problem

Wage and contribution reporting arrives from every participating employer, which for a state system can be hundreds of school districts, municipalities and agencies with wildly different payroll capability. Files arrive late, with wrong pay codes, missing hours, retroactive adjustments spanning prior periods, and members reported under the wrong tier. Every one of those errors eventually surfaces in a benefit calculation years later, when correcting it requires contacting an employer that has changed payroll vendors twice.

The fix is validation at the point of submission with a structured return to the employer, plus an employer portal that shows their outstanding exceptions and their compliance position. Systems that push validation forward to submission time reduce the volume of pre retirement clean up dramatically, and pre retirement clean up is where analyst time actually goes.

Problem three: service credit history has to be first class

Service credit is not a number on a member record. It is a timeline of periods, each with an employer, a tier, an hours or earnings basis, a purchase or refund event history, and a crediting rule. Legacy systems often store a total and lose the derivation, which is why staff rebuild it manually at retirement from microfilm, paper files and employer records.

A build has to store the timeline and compute the total, never the reverse. That single modelling decision determines whether the system can answer a member question in a phone call or a two week research request.

What a first phase should include

• The member, employer and service history data model, with service credit stored as an event timeline rather than an aggregate.
• Employer wage and contribution reporting with pre submission validation, exception return and an employer portal.
• A versioned, effective dated benefit calculation engine with statute citations and a stored record of which rule versions produced each calculation.
• A regression harness running historical cases against the new engine with full difference reporting.
• Migration tooling with reconciliation, not a one time conversion script.
• Analyst tooling that shows the derivation of a calculation step by step, so the manual spreadsheet check can eventually be retired with confidence rather than by decree.

Cost, timeline and what actually drives them

A first phase as scoped above runs $400,000 to $900,000 across 9 to 14 months. A complete replacement covering service purchases, disability and survivor processing, retiree payroll, member self service, document management and employer portals is a multi year programme in the millions, typically three to five years for a system of meaningful size. Anyone quoting a full replacement of a career spanning administration system in twelve months is either scoping something smaller than they said or has not seen the data.

What drives the number: the number of benefit tiers and the depth of statutory history you must reproduce. The number of participating employers and their payroll sophistication. Whether retiree payroll is in scope, since that brings tax withholding, deduction management and a payment run with a hard monthly deadline. Disability and survivor processing, which are workflow heavy and evidence heavy. And the state of your legacy data, which is the single largest unknown and should be assessed before the programme is budgeted, not during it.

What holds it down: sequencing the engine and the data model first and leaving self service to later. Member portals are visible and politically attractive, and they are worth nothing on top of a data model you do not trust.

When not to replace

Do not run a replacement programme if your member population is small, you have a single benefit tier, your legislature has not materially changed your rules in years, and your legacy system still has vendor support and staff who understand it. In that situation the right investment is targeted: an employer reporting portal, a document management upgrade, or a calculation verification tool that reduces reliance on the manual spreadsheet.

Replace when the mainframe skills are concentrated in people who are retiring, when each legislative change takes months and creates fear, when benefit calculations require a manual parallel check to be trusted, when your employers cannot submit data cleanly and your analysts spend their time on pre retirement clean up, or when your actuary and auditor are asking for member level data your system cannot produce reliably for GASB reporting.

How to choose a partner for this

Ask them to describe how a member hired under one tier who later purchases service and transfers employers is represented in their data model. If the answer is a service credit field, stop the conversation.

Ask how a 2027 calculation is reproduced in 2041. If there is no concept of versioned rules with stored linkage, the system cannot defend a dispute and your general counsel should be in that meeting.

Ask what the regression approach is against the legacy system. Recalculating tens of thousands of historical cases and investigating every difference is the only credible verification method, and a partner who has done this will describe it before you ask.

Ask who holds the domain knowledge at the end. The correct answer is your staff, supported by readable rule definitions and documentation, not a vendor's configuration team. This is the whole point: you are replacing a system because knowledge left the building, so do not rebuild the same dependency with a newer logo.

Settle ownership before procurement closes. You should own the repository, the infrastructure accounts, the schema documentation and the unrestricted right to engage another firm. At Digital Heroes the client owns the code from the first commit. For a public body administering benefits under statute, anything less becomes a procurement problem in five years.