Public Pension Administration Software: Custom Build or Off-the-Shelf

What Sagitec, Vitech and LRS actually do well

You are not choosing between good software and bad software. Sagitec Neospin, Vitech V3locity and LRS PensionGold have each put working systems into state and municipal retirement systems, and the consultants who implement them have seen a benefit calculation engine before. That counts for more than any feature list.

What they give you is a domain framework that already knows a member has service periods rather than a service total, a retiree payroll module that produces Form 1099-R by the 31 January deadline without anyone writing tax logic from scratch, employer wage and contribution intake, and a procurement story your board will accept because one named supplier carries the accountability. If your trustees want a single accountable vendor, that is not a foolish preference. It is how public bodies survive audits and staff turnover.

They also bring something an in-house build cannot. When the Governmental Accounting Standards Board changed employer allocation reporting under GASB 68, the packaged vendors built it once and shipped it to everybody. You paid a share of that work instead of all of it. The same applies to the Internal Revenue Service annual benefit limit under Section 415(b) and the compensation cap under Section 401(a)(17), both of which move every year and both of which somebody has to track.

Most retirement systems should buy. We say that to boards regularly and it costs us engagements. If you serve fewer than about 15,000 members, run a single benefit tier, and your legislature has not materially rewritten your statute in five years, a replacement programme is the wrong use of the money. Buy the package, or keep the mainframe and spend the budget on an employer reporting portal and document management instead.

Where the packages stop: the tier your legislature created last session

All of that holds until your statute stops resembling the frameworks the vendors built around. Then the gap opens in one specific place, and it is always the same place.

A benefit formula is not a rate. It is a rule set that varies by hire date, by statutory period, by employer, and by whether the service was earned, purchased or transferred under a reciprocity agreement. A member hired in 1991 who bought four years of military service in 2003, took a refund, repaid it in 2008 and finished at reduced hours is not an edge case. Her calculation depends on which multiplier was in force for each slice of her career, how final average compensation is defined for her tier, and whether that purchase counts toward eligibility as well as toward amount.

Packaged systems express this as configuration. Configuration is fine until it becomes the only description of the rule, at which point you have swapped mainframe code nobody can read for vendor configuration nobody can read, and the configuration lives with the vendor's staff rather than yours. Each legislative session then becomes a change order with a price and a lead time, which is an awkward position for an organisation whose rules change by law rather than by choice.

The second gap is reproducibility. A member can dispute a benefit fifteen years after retirement, and you have to show how the number was derived under the law as it stood. That needs versioned, effective-dated rules with a statute citation attached, and a stored record of which rule versions produced each calculation. Ask every shortlisted vendor how a 2027 calculation is reproduced in 2042. The answer thins the field quickly.

The arithmetic: per-member licensing against a one-time build

Do this on one page before you read another proposal. Packaged pension administration is normally priced as a fixed implementation plus annual maintenance, and the maintenance figure is usually anchored to your active and retired member count. Take the per-member figure from your last quote, multiply by headcount, then multiply by ten, because a pension system is a ten-year decision and almost nobody replaces one inside five.

Now set the build beside it. A first phase covering the member and service history data model, employer reporting and a versioned calculation engine with parallel verification runs $400,000 to $900,000 over nine to fourteen months in our delivery experience. Annual support afterwards sits at 15 to 20 percent of build cost. So a $700,000 build carrying 17 percent support costs roughly $1.9 million across ten years.

Against that, maintenance at $12 per member per year crosses $1.9 million over ten years at about 16,000 members. At $20 per member it crosses under 10,000. Those rates are arithmetic inputs, not a claim about the market. Put your own quoted figure in, because per-member pricing in this category varies more than any other line on the proposal.

Two corrections most boards forget. Price three legislative sessions of change orders into the packaged column, because your rules will change three times in a decade. Then add the staff time the package does not remove: pre-retirement clean-up, the manual parallel calculation your analysts run to trust the number, and rebuilding service credit histories from microfilm. In systems we have assessed, that second figure is frequently larger than the licence.

Where the line usually sits: below roughly 25,000 members with one or two tiers, buy. Above roughly 40,000 members with four or more tiers, the build wins on ten-year cost alone. Between those two numbers cost is a wash, and the decision turns on who you want holding the domain knowledge.

What a custom build actually costs

Bands first. A first phase covering the member, employer and service history data model, employer wage and contribution reporting with validation at submission, and a versioned benefit calculation engine with a regression harness runs $400,000 to $900,000 across nine to fourteen months. A complete replacement adding service purchases, disability and survivor processing, retiree payroll with withholding and deductions, document management, member self-service and employer portals is a multi-year programme in the millions, typically three to five years for a system of any size. Anyone quoting a full replacement of a career-spanning administration system in twelve months is scoping something smaller than they described.

Then the two lines nobody quotes. Data migration runs 10 to 25 percent of build cost on its own, and in this category it sits at the top of that range, because you are not moving records, you are reconstructing careers across formats, employers and eras. Commission a legacy data assessment before the programme is funded rather than during it. Year two and every year after runs 15 to 20 percent of build cost annually, covering hosting, security patching, statutory changes and enhancement.

What drives the number up: the count of benefit tiers and the depth of statutory history you must reproduce; the number of participating employers and their payroll sophistication, since a state system can carry hundreds of districts and agencies; whether retiree payroll is in scope, which brings withholding, deduction management and a payment run with a hard monthly deadline; and the condition of your legacy data, which is the single largest unknown.

What holds it down: sequence the engine and the data model first and leave self-service until later. Member portals are visible and politically attractive, which is exactly why they end up sitting on a data model nobody trusts.

The four situations where building wins

• Regulatory fit. Your statute has produced four or more tiers, your board issues resolutions that alter crediting rules, and reciprocity agreements with other systems each carry their own arithmetic. When the rules are the product, renting the expression of them is the wrong shape.
• Scale economics. Above roughly 40,000 members, per-member maintenance plus three sessions of change orders passes the ten-year cost of owning the system outright. Run that sum with your own renewal figure before anyone shows you a demonstration.
• A workflow that is your actual mission. The benefit calculation engine is not a back-office function you are optimising. It is the thing your organisation exists to do, and every year it stays unreadable is another year of institutional risk concentrated in a handful of people approaching retirement.
• Integration sprawl across three or more systems. Employer payroll files, the actuarial valuation extract, your general ledger, the document imaging archive and a bank file for retiree payments. When five interfaces each need a vendor change request, the interfaces become the project.

One of these on its own is rarely enough. Two together is the tipping point in our experience, and three makes the packaged route more expensive than it looks on the proposal.

How to decide in a week

Run this test rather than another requirements workshop. Pull five real member files: one with purchased military service, one with a refund and repayment, one under a reciprocity agreement, one with a Qualified Domestic Relations Order splitting the benefit, and one who retired under a tier that no longer exists. Calculate all five by hand with your analysts and record how long it takes and how many people are needed. Then hand the same five files to every vendor and every developer on your shortlist and ask two questions: how is this member represented in your data model, and how would you reproduce this calculation in 2042.

If a vendor answers the first question with a service credit field, stop the conversation. If nobody can answer the second, your general counsel should be in the next meeting. That exercise takes four days and tells you more than a six-month procurement.

Then buy a paid discovery phase, from whoever wins the exercise, that ends with a written specification you own outright: the data model, the rule versioning approach, the migration and reconciliation plan, permissions and acceptance criteria. Take that document to any other firm on your shortlist. A specification you own converts four incomparable quotes into four prices for the same thing, which is the only way a fixed price stays fixed.

Digital Heroes will not start writing code without a signed product requirements document. We contract through India LLP, US LLC and UK LTD entities so the intellectual property assigns under law your own counsel already reads, and the client owns the repository from the first commit. More than fifty specialists, over 2,000 projects, and a named team you meet before signing, verifiable on Clutch, Trustpilot, Fiverr Vetted Pro and D-U-N-S. We also build our own products, including ShopScore, HeroCheckout and Section Vault, so we know what a decade of ownership costs.

We are the wrong firm for a system under 15,000 members with one tier and a working mainframe. We are also wrong if your board wants a single vendor to carry every risk under a fixed-price prime contract for a five-year programme. Buy the package in both cases.

Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.