Sagitec Neospin Alternatives for Public Retirement Systems: Replace the Core, Extend It, or Stay

Why retirement systems start looking at alternatives

The first driver is the change order. A legislature amends a benefit tier, adds a purchase of service provision, alters a cost of living adjustment or creates a new plan for new hires, and the system that was configured beautifully three years ago now needs work that arrives as a scoped engagement with a price and a schedule. Pension administration is unusual in that your business rules are written by a legislature on its own timetable, and if your ability to implement those rules depends on a vendor queue, you have a structural exposure rather than an irritation.

The second is the end of an implementation. These programmes run for years, and when the last phase closes the internal team that has lived inside the project disbands. Institutional knowledge walks out with the contractors, and the retirement system discovers that the people who understood how a service credit rule was actually implemented are no longer under contract.

The third is member expectation. Members compare your self service experience to their bank, not to another pension system. Retirement estimates, beneficiary changes, document upload, employer reporting corrections: these are the things boards hear complaints about, and they are usually the parts of the platform that were configured last and with the least budget left.

What Sagitec Neospin genuinely does well

Domain depth is the real value, and it is substantial. Public pension administration involves member records spanning fifty year careers, service credit accrual with dozens of exceptions, contribution reconciliation against employer payrolls that arrive in inconsistent shapes, benefit calculation across multiple tiers and plan generations, disability and survivor processing, refunds, purchases, deferred retirement option arrangements, and tax reporting on the payment side. Each of those has edge cases that only appear in a real fund's data, and a vendor that has implemented for multiple retirement systems arrives already knowing where the bodies are buried.

The delivery model is also a genuine strength for a public agency. Procurement, phased delivery, defined acceptance, a vendor accountable under contract: these are the mechanics a board and an auditor understand. A retirement system that has never run a software programme gets a structure to run it inside, which matters more than any feature list.

Where it actually strains

Configuration ownership is the central issue. A heavily configured platform sits in an awkward place: it is not generic enough that anyone can maintain it, and not yours in the way that source code you commissioned would be. When the legislature acts, whether you can respond in six weeks or six months depends entirely on how much of the rule layer your own staff can safely touch. Ask that question during procurement, not afterwards.

Release cadence is the second constraint. Vendor upgrades and your configuration interact, and heavily configured environments upgrade slowly and carefully, which is correct for a system paying benefits and frustrating for everyone waiting on it.

Third is reporting. Actuarial extracts, board reporting, GASB disclosure support and ad hoc analysis of membership demographics all tend to become extract driven work, and a data analyst with a workbook becomes an unofficial part of your control environment. Fourth is the member and employer experience, which is usually the thinnest part of a configured platform because it was scoped last. Fifth is cost of change generally: in a fixed price configured model, every deviation is a variation, and variations accumulate.

Option one: replace the core with another platform

The realistic alternatives are Vitech with V3locity, LRS, Milliman on the actuarial and administration side, and the large systems integrators who deliver bespoke pension administration under a services contract. Advisory firms that specialise in running these procurements are worth engaging, because the difference between a well specified pension procurement and a poorly specified one is measured in years.

Understand the true cost. A pension administration core replacement is a three to six year programme for a statewide system, involving conversion of member records spanning decades, verification of service credit histories that may exist partly on microfilm or in an inherited mainframe, recalculation and reconciliation of accrued benefits, employer onboarding to new reporting formats, and parallel benefit calculation for a full cycle. It is the largest technology undertaking a retirement system will attempt in a generation. Replace when the current core genuinely cannot administer the plans you are legally required to administer. That threshold is high, and it should be.

Option two: stay and take ownership of the rule layer

For most systems already live on Neospin, staying is right and the improvement available is organisational rather than technological. Negotiate for knowledge transfer and configuration access at contract renewal rather than at crisis. Build an internal team, even a small one, that can read and change the rule layer under supervision. Document benefit rules independently of the platform so that a future procurement or a future audit does not depend on reverse engineering. A retirement system that can implement a legislative change itself has removed the thing that actually hurts, without spending a cent on new software.

Option three: keep the core, build what members and employers touch

This is where custom work is cheap, fast and genuinely valuable. A member self service portal with a retirement estimate calculator that shows the working, so a counsellor is not re explaining an arithmetic result over the phone. An employer reporting portal that validates contribution files at upload, shows errors in plain language and lets a school district or a city payroll clerk fix them without a phone call to your staff. A workflow layer for disability applications, survivor claims and service purchases, so a case has a visible status instead of living in a queue nobody can see. A reporting warehouse feeding actuarial extracts, board packets and demographic analysis from a defined data model rather than from a workbook.

All of it reads from and writes to the administration core through defined interfaces. None of it recalculates a benefit independently, which is the line you must not cross.

When a custom core genuinely pays back

There is a real case, and it is the smaller fund. A single plan municipal system, a county fund, a supplemental plan or a closed plan with a defined population does not need a platform engineered for a statewide system with hundreds of employers and six benefit tiers. For those funds, a vendor pension administration procurement is over scoped, the licence and services cost is disproportionate, and a purpose built administration system covering members, contributions, benefit calculation for a bounded rule set, payments and reporting is both cheaper and easier to change. If your rules fit on a wall and your membership is measured in thousands rather than hundreds of thousands, build.

Migration reality

Whatever you do, the data is the project. Member records carry service history, contribution history, salary history, beneficiary designations and prior plan participation, and much of it originates in systems that predate everyone currently employed. Budget for data remediation as a separate workstream with its own staff, because it always is one whether you plan it or not. Recalculate a statistically meaningful sample of benefits in both systems and reconcile to the cent, including the awkward cases: reciprocity, purchases, disability, survivor continuations. Run payments in parallel for at least one full cycle. Onboard employers in waves rather than all at once, since employer reporting failures generate the loudest and fastest complaints. Keep the legacy record readable for the life of the fund, because a benefit dispute can reach back forty years.

Cost bands

Vendor pension administration programmes are procured competitively and priced as multi year delivery engagements, so the useful comparison is against what surrounding and smaller scale work costs. Based on what Digital Heroes typically delivers, a focused component, a member self service portal with estimates, an employer reporting portal, or a case workflow layer, runs $80k to $200k over 12 to 20 weeks. A full member administration platform for a smaller single plan fund runs $250k to $600k. Those are build costs you own, with source code, documentation and the ability to implement the next statutory change without raising a variation.

The honest recommendation

If you are a large statewide system already live on Neospin, stay, and spend your energy on owning the rule layer and on the member and employer experience. That is where your board complaints come from and it is the cheapest thing to fix. If you are mid procurement for a large system, a configured vendor platform with a proven public pension delivery record is a defensible choice, and you should negotiate configuration ownership and knowledge transfer as a first class requirement rather than an afterthought. And if you are a smaller fund being quoted a statewide sized programme, stop and price a purpose built system instead. Paying for depth you will never use is the most common and least discussed failure mode in public pension technology.