FRP Has a Launch Date. You Still Don't Have a Migration Date. Build One Before the Queue Builds It For You.

A Launch Date Is Not a Migration Date

After four years of shifting timelines, FRP has a date: July 2026, when the platform goes live for an installed base of roughly 650 clients and 68 million participants running on OMNI and Relius today. Shipping a unified successor to two 30-year platforms is a serious engineering commitment, and a committed date is real progress. But the date that matters to your operation hasn't been published — yours. There is no client migration timeline. No sequencing plan. No answer to the only scheduling question that matters: when do you convert?

Whatever the reason, the effect is the same: until a client timeline exists, your conversion date is an open question. And the math behind that question is unforgiving: 650 clients cannot re-platform off a 30-year core in parallel. FIS's conversion capacity is the binding constraint, and it will be rationed. The recordkeepers who arrive prepared will set their terms. The ones who wait for the call will be sequenced into the crunch — at the back of the queue, on the vendor's schedule, with far less negotiating leverage.

You Can't Set Their Date. You Can Set Yours.

Here's what the FRP debate keeps missing: the migration date is not actually the decision in front of you. Readiness is.

The preparation that determines whether your migration is a managed event or a crisis takes months — in a heavily customized environment, the better part of a year. None of it commits you to FRP. Every piece of it is portable: it pays off identically whether you land on FRP, move to a different platform, or run OMNI longer than planned. What it produces is something most shops have never had — a complete, current picture of the platform they actually operate.

In 18 large-scale migrations, we have never once walked into an environment that was fully documented. Not one. The platform in production is never the platform in the manual. Closing that gap is the preparation, and there are three places to start.

Start With the Platform You Actually Run

The first workstream is an honest evaluation of your current OMNI environment: every process the platform runs and every job on the schedule. Not the processes in the operations manual — the ones in the nightly batch. The job that runs at 2 a.m. because it has always run at 2 a.m. The dependency between the trading file and the reconciliation job that exists only in one operator's head. The processing window sized for a constraint that disappeared two upgrades ago.

The deliverable is a process inventory and a job-schedule map: what runs, when, in what order, depending on what, producing what. It sounds basic. It is also the document every conversion scope starts from — and the one almost no shop can produce on day one. You cannot sequence a migration of processes you haven't enumerated, and you cannot price one either. When the scoping conversation eventually happens, this map is the difference between an estimate built on your facts and an estimate built on the vendor's assumptions.

Map Your Script Environment

Twenty years of OMNI operation accumulates scripts. OmniScripts, external programs, utilities bolted on alongside the core — each one written to solve a real problem, most never revisited. On a single engagement we analyzed over 35,000 custom scripts. The shop that owned them had estimated "a few thousand."

A script environment map does two things. First, it classifies the estate: which scripts are load-bearing, which duplicate functions the platform has since absorbed natively, which are dead code still faithfully running on schedule. Second — and this is the part with immediate payback — it finds the opportunities to lessen the dependence now. Every script you retire before conversion is a script you never have to convert, test, and defend at cutover. Every external program you fold back into native platform function shrinks the migration surface and de-risks the operation you're running today.

This is months of work in any real environment. It is also the single highest-leverage preparation you can do, because script conversion is where migration budgets go to die.

Map Your Data Environment

The third workstream is the one that breaks migrations when it's skipped: a complete map of where your data actually lives and moves. It has two halves.

Non-core data and UDFs. User-defined fields are where twenty years of workarounds went to live. The field repurposed in 2009 to drive one plan's contribution logic. The side table a compliance analyst maintains because the core couldn't hold what the auditor asked for. None of it is in the data dictionary, all of it is load-bearing, and every piece needs a target-state answer before cutover — not a production surprise after.

Imports and exports. Payroll feeds in. Trading files, trust and custodial feeds, compliance extracts, and participant files out. Each one needs a documented source, format, owner, and downstream consumer. Undocumented feeds don't fail loudly during a migration — they fail silently, weeks later, when a number doesn't tie and nobody can say where it came from.

The deliverable is a data environment map your team can defend line by line: every non-core store, every UDF and what consumes it, every interface crossing your platform boundary.

Preparation Is Leverage

These three maps do more than de-risk the conversion. They change your negotiating position. A recordkeeper that shows up with a complete process inventory, a classified script estate, and a defensible data map can scope its own migration, sequence its own cohorts, and challenge the vendor's assumptions with facts. A recordkeeper without them inherits whatever timeline and price it's handed.

The base rates here are not kind. McKinsey's research on large technology programs puts the average budget overrun at 45 percent — and the overruns concentrate in scope that was discovered late. The cheapest migration you will ever run is the one scoped from a complete inventory. The most expensive one is the one where the inventory gets built mid-flight, in production, under deadline.

The Window Is Now

The preparation takes months. The conversion-capacity crunch is coming regardless of whether you're ready for it. Start the inventory after the migration conversations begin in earnest, and you'll be doing discovery work on the vendor's clock instead of your own.

We've completed 18 successful large-scale migrations — 21,000 plans and $300 billion in assets, including a 700K-participant, $20 billion engagement with zero-day blackout. Our 1,200+ task Migration Playbook starts exactly where this article does: evaluate the platform, map the scripts, map the data. If you're running OMNI or Relius and watching the FRP calendar, we've helped recordkeepers across the industry build this runway. We can help you too.