Everyone Is Talking About FRP. Nobody Is Talking to Relius Users.

The Conversation in the Room

Walk into any conversation in this industry right now and it is all FRP. Migration timelines. Deployment paths. Which version, which architecture, what it means for your data. The Omni world is consumed by it, and rightly so.

But there is a whole population sitting quietly at the edge of that conversation, and almost nobody is addressing them directly: the firms running Relius.

Here is the reality that matters to them. FRP is not a Relius upgrade. FIS has been clear about what the new platform is: a single cloud-based system that consolidates Omni and Relius. Will Hicks, who leads FIS Global Retirement, put it plainly this spring: "One goal was to consolidate platforms… An integrated platform would bring much of the functionality that Omni users enjoy to everyone."

That is a good outcome for the industry, and a serious engineering achievement. It also means something specific if you are the one running Relius today. Different codebase. Different architecture. Different data model. The functionality coming to "everyone" was designed around Omni, and the path from Relius to it is a conversion, not a version step.

The Questions Relius Shops Are Asking Each Other

I hear these from TPAs and independent recordkeepers, usually quietly and rarely in a vendor meeting.

When do we actually get migrated? FRP has a launch date. Nobody has published a client migration timeline, and for a Relius shop the date that matters has not been written anywhere.

What happens to our support in the meantime? A platform vendor running a migration of this scale has finite capacity, and that capacity will go where the scale is. That is arithmetic, not a criticism. It still leaves a question for a smaller Relius shop with a production issue on a Tuesday morning: who picks up the phone, and how fast?

Where are we in the sequence? FIS's installed base is roughly 650 clients and 68 million participants across both platforms. Those clients cannot re-platform in parallel. Sequencing will happen, and a firm that does not know where it sits in that sequence is planning around an unknown.

Who has done this before? For Relius-to-FRP specifically, the reference implementations are still being written. Every Relius shop is navigating a platform shift for which the map is being drawn while they walk.

Why This Is Harder Than It Looks

No two Relius environments are the same. That is the platform's strength, and it is the migration's problem.

Twenty years of customization. Hard-coded surrounds. Third-party applications bolted on at every layer. Custom Crystal reports. STP and trading interfaces. Job Queue automations. Interfaces someone built in 2011 who left the firm in 2014 and documented nothing. None of that is a criticism; it is what happens when a platform is flexible enough to let people solve real business problems. But it means every Relius environment is its own archaeology project.

You cannot migrate what you do not understand. And most shops, if they are honest with themselves, no longer fully understand their own environment.

What You Can Do Right Now

You do not need a migration date to start. This is the work that pays off regardless of when your number is called, and it is the same work that pays off if you decide to go somewhere other than FRP.

1. Inventory every customization. Every script, every hard-coded value, every workaround. If it touches Relius and someone at your firm built it, it goes on the list. Most shops are genuinely surprised by how long the list is.

2. Map your surrounds and integrations. Trading platforms, payroll feeds, custodian interfaces, document systems, third-party tools. What connects to what, in which direction, and what breaks if it stops. This is where migrations quietly die.

3. Catalog your custom reports and extracts. Reporting is one of the most disruptive pieces of any platform shift, and the one most firms discover last. Know what you have, who uses it, and what is genuinely business-critical versus what has been running unread for six years.

4. Clean your data now, not during conversion. Orphaned plans, terminated participants never purged, inconsistent coding conventions, forfeiture accounts nobody has reconciled. Dirty data does not get better under a go-live date. It gets expensive.

5. Separate mission-critical from historical baggage. Not everything in your environment deserves to make the trip. Deciding that on your own timeline is a strategy. Deciding it during a conversion is triage.

6. Write down what lives in people's heads. In most Relius shops, one or two people understand why things work the way they do. If they retire, leave, or get pulled onto the migration full-time, that knowledge leaves with them.

7. Build a support plan that does not assume vendor availability. Vendor bandwidth is about to become the scarcest resource in this industry. Plan for that now, while it is still a planning exercise.

Why Now Matters More Than You Think

For anyone planning to deal with this when the date comes, three things are worth underlining.

Remediation takes longer than migration. The conversion is the short part. Untangling twenty years of customization is the long part. Start it after you get a date and you are compressing years of discovery into a vendor-controlled timeline.

Preparation is leverage. A firm that knows exactly what it has can negotiate timeline, scope, and cost. A firm that does not takes what it is given. Dave DePue made this case for the Omni side in June; it is doubly true for Relius, where the conversion is larger and the shop is usually smaller.

Quiet is the cheapest time to do hard work. Discovery done calmly, with no go-live date and no clients watching, costs a fraction of discovery done under deadline pressure with participants affected.

The migration wave is coming whether Relius shops are ready or not. The firms that spend this window understanding their own environment will migrate on their terms. The ones that wait will migrate on somebody else's.

How We Help

We know Relius from the inside — the tools, the surrounds, the scripting, the administration, the installation. Not from a vendor deck; from doing the work. Our Relius team has spent years inside these environments untangling exactly this kind of accumulated complexity, and we have the conversions to show for it: migrating roughly 150 plans off FIS-hosted Relius under an aggressive deadline, then supporting that platform day to day for six years and counting, and stabilizing a mid-market recordkeeper's production environment while building its Relius decommissioning roadmap.

We can help you map what you actually have, disentangle the customizations and dependencies, keep the platform stable and supported while the industry sorts itself out, and get you genuinely FRP-ready instead of hoping the timeline works out. The full FRP migration readiness program starts exactly where this article does.

If you are running Relius and you do not have a clear answer to "what is actually in our environment," let's talk. That question is the whole project, and it is far cheaper to answer now.