
The Goalposts Moved. The Engine Didn't.
Three Words
Migration. Modernization. Consolidation.
I have been inside the programs those three words describe for twenty years. What they have produced, at scale, is mostly modern architecture sitting on top of a thirty-year-old engine.
Among the largest recordkeepers, 80 percent run home-grown platforms and 77 percent are mainframe-based. OmniPlus was under development in 1995 and completed in 1996 as the successor to a system SunGard was already delivering on IBM mainframes. TRAC was already at scale by 1997. FIS, which acquired SunGard in 2015 and owns OmniPlus today, is bringing a cloud successor to market this year, four years in the making.
Two decades of programs have mostly gone around those engines. Everest Group found that less than 25 to 35 percent of recordkeepers' transformation budgets goes to the core, while 65 to 75 percent goes to the layers around it: customer interaction, data analytics, infrastructure. The engine stayed.
I do not say that as a complaint. Those engines work. Thomas Nigro made that case on this site, and he is right. It is the starting point for a harder question.
The Harder Question
Everyone knows modernization is hard. The question is why these programs fail. Or, if "fail" is too strong a word, why the goalposts move until what was delivered counts as success.
Watch how it happens. A program is announced as a modernization of the core. Three or four years later it is completed as something else: the consolidation of acquired plans onto the existing engine, the outsourcing of that engine's operation, its re-hosting in the cloud, or a second engine stood up beside the first, with both kept running. Every one of those is a real achievement. None of them is what the word meant when the program was announced. The engine is still there, and "transformation complete" now means something narrower than it did at kickoff.
This is not a retirement-industry quirk. It is what large programs do everywhere. When The Standish Group dropped "on target" from its definition of a successful project, to avoid, in its words, "penalizing a project for having an evolving target," the measured success rate fell seven points on the definition alone. In core banking, a business with a far more standardized product than ours, McKinsey found that only about 30 percent of transformations in the past decade achieved a complete migration of ledgers and products, and that in many of the rest, legacy applications were still running more than five years after go-live.
The base rate is poor everywhere. Retirement adds to it.
Contracts, Not Accounts
A recordkeeper that has built and run its platform for decades goes looking for a technology partner large enough to take it on. It finds one: a firm with tens of thousands of engineers and a track record earned in banking, insurance and retail. Both parties are excellent at what they do. The recordkeeper hires the track record. The partner arrives with the confidence it has earned elsewhere, and it has earned it.
Then reality arrives, and it arrives in details.
A bank migrates accounts. A recordkeeper migrates contracts. There are 790,610 private-sector defined contribution plans in this country, each governed by its own document, and the IRS expects each one to be operated by that document to the letter. Not doing so is, in the IRS's words, "a very common mistake." The data is not a balance; it is a history, because federal law requires records sufficient to determine "the benefits due or which may become due": every source, every vesting event and every loan, back to the beginning. The rules change while the program is running: SECURE 2.0 alone carries roughly 90 provisions with effective dates spread from 2022 into 2028. And the cutover has a statutory clock: suspend participants for more than three consecutive business days and you have a blackout period that must be noticed 30 to 60 days in advance, with a penalty that runs per day if you get it wrong.
None of that is unmanageable. All of it is specific. Fifty core-banking migrations are a real credential. In retirement, the first one is still a first.
The Details, in Opposite Directions
Which brings me to why I think these programs stall. After nearly thirty years in this business, I have stopped believing it is the technology.
Recordkeepers get lost in the details. Everyone inside the building knows that every exception is load-bearing: the odd vesting rule for the plan acquired in 2004 exists because a client needed it and a regulator accepted it. So nothing can be simplified, nothing can be dropped, and the program slowly becomes a faithful reproduction of the old system on new hardware. It is very hard to modernize something you are not allowed to change.
Technology partners are built to see past the details. A methodology proven in banking treats the book of business as data to be moved, because in banking that is what it is. In retirement, most of it is logic to be understood. On one migration, more than 600 plans and 700,000 participants moved with zero days of blackout, and our team parsed more than 35,000 custom scripts before a record moved, because the business logic lives in the scripts, not the schema. Skip that step and you can move the data perfectly and still get the business logic wrong.
Neither side is wrong about what it knows. The recordkeeper is right that the details matter. The partner is right that a program cannot drown in them. The gap between those two truths is where programs stall. It is also where the goalposts move.
In the Gap
That gap is where we work. Our people ran these engines before they advised on changing them, and most of what we know is what went wrong.
The work starts with the recordkeeper's fingerprint: the core, the products, the plans and their customizations, the surrounding applications and, most of all, the people who built and run the system. The details are in their heads before they are anywhere else. From that comes a roadmap the partner can execute at scale: which details are load-bearing and which are habit, what can move and what must be rebuilt, in what order, with how many dry runs. We have done this across eighteen large-scale migrations. Along the way we built MAPTIVA, because the mapping was always the part done by hand.
We do not compete with the partner. We are the part that lets the program survive contact with a plan document.
Name One
Name one major recordkeeper that started on one of those engines and runs end to end on a modern platform today. Not one born on a modern platform with no engine to replace. One that got out.
I have looked. I can find consolidations, outsourcings, re-hostings, and second engines standing beside first ones. I can find a great deal of genuinely good work. I cannot find one that got out.
If you can, I would like to hear about it. If you are about to start a program that intends to be the first, let us talk before the goalposts are set. And if you are two years in and the steering deck no longer says what the charter said, they already have.
Sources
- Everest Group, Modernization in the Retirement Plan Industry and the Journey to the Cloud, 2021 (hosted by the SPARK Institute)
- SunGard Data Systems, Annual Report on Form 10-K, fiscal 1995, March 1996 (SEC EDGAR)
- SunGard Data Systems, Annual Report on Form 10-K405, fiscal 1996, 1997 (SEC EDGAR)
- DST Systems, Annual Report on Form 10-K, fiscal 1997, March 1998 (SEC EDGAR)
- FIS, FIS to Acquire SunGard, August 2015 (SEC EDGAR)
- WealthManagement.com, FIS Global Retirement Launches Cloud System in July, May 2026
- The Standish Group, CHAOS Report 2015, 2015 (hosted by Info-Tech Research Group)
- McKinsey & Company, How to get a core banking transformation right: Eight mistakes to avoid, February 2022
- U.S. Department of Labor, EBSA, Private Pension Plan Bulletin: Abstract of 2023 Form 5500 Annual Reports, January 2026
- Internal Revenue Service, 401(k) Plan Fix-It Guide: You didn't base the plan operations on the terms of the plan document, accessed September 2026
- 29 U.S.C. § 1059, ERISA § 209, Recordkeeping and reporting requirements, accessed September 2026 (Cornell LII)
- Groom Law Group, SECURE 2.0 Hitches a Ride Just in the St. Nick of Time, December 2022
- U.S. Senate Committee on Finance, SECURE 2.0 Act of 2022, Section-by-Section Summary, December 2022
- 29 CFR § 2520.101-3, Notice of blackout periods under individual account plans, accessed September 2026 (Cornell LII)
- U.S. Department of Labor, EBSA, Fact Sheet: Adjusting ERISA Civil Monetary Penalties for Inflation, January 2024
Get the next one in your inbox.
One email when new research lands. No drip campaign. Unsubscribe anytime.
More from the library
The Cost Line Nobody Puts on the Slide
Technology is the second-largest cost a recordkeeper carries, and the people who see it most clearly are the ones we keep asking to absorb it. The cloud proved the industry can change its mind in a decade. AI is the same story, on a faster clock.
Read article: The Cost Line Nobody Puts on the SlideEveryone Is Talking About FRP. Nobody Is Talking to Relius Users.
FRP is a merger of Omni and Relius into one cloud platform, not a Relius upgrade. If you run Relius today, your migration is a different project from the one the industry is discussing — and the preparation that protects you does not need a date to start.
Read article: Everyone Is Talking About FRP. Nobody Is Talking to Relius Users.Retirement Is Complex. The Answer Isn't More Complexity.
The retirement industry's instinct is to meet a complex problem with an equally complex process. That instinct is the problem. The hard, valuable work is making it simpler.
Read article: Retirement Is Complex. The Answer Isn't More Complexity.Your platform won't modernize itself. Let's talk.
Book a 30-minute platform assessment with a principal-level consultant. No pitch deck. No junior associate. Just a direct conversation about your systems, your challenges, and what it would actually take to solve them.
