Public Pension Administration Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the calculation engine get scoped as one module among many?

Because on a programme plan it looks like one. Member records, employer reporting, service purchases, disability, survivor benefits, retiree payroll, self service, document management, and somewhere in that list, benefit calculation. Equal boxes on a slide.

It is not one module among many. It is the system, and everything else is workflow. The engine has to express the benefit formula per tier per statutory period, apply eligibility rules that differ from benefit accrual rules, handle purchased and reciprocal service with their own crediting logic, and compute optional payment forms using actuarial factors that themselves have effective dates. Then it has to reproduce any of that decades later.

When it is treated as a module, two things follow. It gets scheduled in parallel with the visible components rather than ahead of them, so the data model is fixed by whichever team moved first. And its verification is scoped as testing rather than as a research programme, which is the actual mistake.

The correction is a sequencing decision made before procurement. The data model and the calculation engine come first, verified, and everything else is built on top of what they prove. Member self service is visible and politically attractive, which is exactly why it gets pulled forward, and a self service estimate tool sitting on an unverified engine generates member expectations you cannot honour and phone calls you cannot answer.

What goes wrong when you migrate career spanning member data?

This is not a data transfer. It is an archaeological project across formats, employers and eras, and it is the single largest unknown in the programme. It should be assessed before the budget is set rather than during delivery, and the number of retirement systems that discover this in the wrong order is not small.

The defect that causes the most downstream pain is service credit stored as a total. Service credit is not a number, it is a timeline of periods, each with an employer, a tier, an hours or earnings basis, a crediting rule, and a history of purchase, refund and repayment events. Legacy systems commonly store the aggregate and lose the derivation, which is why staff rebuild it manually at retirement from microfilm, paper files and employer records. Migrate the total and you migrate the problem, permanently.

The other recurring defects are tier assignment recorded once at hire and never revisited when a statute changed, purchased service credited without the purchase evidence attached, and member records from an employer that has since merged out of existence carrying identifiers nothing else in the system recognises.

Profile before you plan. Rank what can be reconstructed from source records, what has to be marked as unverified, and what genuinely cannot be recovered, and publish that assessment to the analysts, because they are the people who will be asked about a 1994 service period by a member on the phone. Build the timeline in the new system and compute the total from it, never the reverse. That one modelling decision determines whether a member question is a phone call or a two week research request.

Why do employer reporting interfaces break after launch?

Because you have hundreds of counterparties with wildly different payroll capability and no obligation to tell you when they change anything. A state system takes files from school districts, municipalities and agencies, and a district changing payroll vendors is a routine procurement for them and a broken interface for you.

The failures are the ordinary kind and they compound. Files arrive late. Pay codes are wrong because a district added an earnings type and mapped it by guess. Hours are missing. Retroactive adjustments span prior periods and land without explanation. Members are reported under the wrong tier. Every one of those errors is invisible now and surfaces years later inside a benefit calculation, at which point correcting it means contacting an employer that has changed payroll vendors twice and lost the staff who knew.

Push validation to the point of submission. The employer uploads, the system validates immediately against the expected structure and against what it knows about those members, and returns a structured exception list they must clear before the file is accepted. Give each employer a portal showing outstanding exceptions and their compliance position, because visibility changes behaviour in a way that a monthly email does not.

Then monitor for silence as well as error. An employer that stops submitting looks like an employer with no payroll that period, and the gap only becomes visible when a member from that employer retires. In our delivery experience, moving validation forward is the single largest reduction in analyst clean up work available in this category, and it is frequently deferred because it is unglamorous.

What happens when reproducibility for disputes is not covered?

You inherit the exact problem you set out to solve, in a newer language. 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, not under today's rules. Systems that hold current formula logic cannot do this, so the answer becomes a manual reconstruction by whoever understands the statute history, which is the dependency the replacement was supposed to remove.

The requirement has to be explicit and it has to be in the architecture rather than in a reporting layer. Every rule is a versioned, effective dated, individually testable unit with a citation to the statute or board resolution that created it. Every calculation stores which rule versions produced it. Reproducing a 2027 calculation in 2041 then means loading the 2027 versions and running them, and the answer is identical by construction.

This also determines what happens at the next legislative session. Rules change by law rather than by choice, 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. In a well designed system that is a new versioned rule set with an effective date and a citation, testable in isolation, and it is work measured in weeks. In a system that treats tiers as configuration branches inside one large formula, each session makes the next one harder, and eventually nobody will touch it. That is precisely how the mainframe you are replacing got that way.

Should you build custom or configure what you already own?

Do not run a replacement programme at all 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. The right investment there is targeted: an employer reporting portal, a document management upgrade, or a calculation verification tool that reduces reliance on the manual spreadsheet. Those are months of work rather than years.

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

The trade offs are the ones the industry already discusses openly. Implementations run long because expressing your specific statute is an enormous configuration effort. The resulting configuration is frequently as opaque as the code it replaced, 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 awkward for a system whose rules change by law.

Build when the deciding factor is where the domain knowledge ends up. The usual reason a retirement system starts a replacement is that knowledge walked out of the building inside mainframe code. Rebuilding the same dependency with a newer logo solves nothing.

How do hidden costs get into the quote?

• Legacy data condition. The largest unknown in the programme, and the one most often priced from an assumption rather than an assessment. Fund a profiling phase before the budget is fixed.
• Statutory history depth. How many tiers and how far back you must reproduce. This drives engine work more than any other single factor.
• Employer count and sophistication. Every payroll vendor in your employer base is an integration variant.
• Retiree payroll. Brings tax withholding, deduction management and a payment run with a hard monthly deadline. It is a system, not a screen.
• Disability and survivor processing. Workflow heavy and evidence heavy, and consistently underestimated.
• Regression investigation. Recalculating tens of thousands of cases produces differences, and investigating them is real calendar time for your analysts, not just compute.

What separates a build that works from one that fails here?

The programmes that work treat regression against the legacy system as the verification method, not as a test phase. Recalculate tens of thousands of real historical cases before any release and report every difference. Some of those differences will turn out to be legacy errors, and finding them deliberately in a controlled exercise is far better than discovering them one member at a time in a letter. A partner who has done this will describe the regression approach before you ask, and will expect the investigation to take months rather than sprints.

They build analyst tooling that shows the derivation of a calculation step by step, so the manual spreadsheet check can be retired with evidence rather than by instruction. Telling experienced analysts to stop double checking does not work and should not. Showing them a derivation they can follow does.

They sequence the data model and the engine first and leave self service to later, accepting that the visible wins arrive in year two. Boards find this uncomfortable and it is the correct answer anyway.

They keep the domain knowledge in the building, supported by readable rule definitions with statute citations and documentation your own staff can maintain. That is the entire point of the exercise.

And they settle ownership before procurement closes: 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 and a governance problem sooner.