What We Learned Migrating 700K Participants Without a Blackout

The Scale

700,000 participants. $20 billion in assets. 600+ individual retirement plans. A migration from FIS OmniPlus to SS&C DST TRAC. And an absolute requirement: zero days of blackout.

This was the engagement that established our Migration Playbook — a methodology of 1,200+ tasks that we now use on every conversion. Here are the lessons we learned.

Lesson 1: Know Every Custom Configuration

The biggest risk in any platform migration isn't the standard data. It's the customizations. Over decades of operation, plans accumulate custom configurations, business rules, and workarounds that nobody fully documents.

On this engagement, we analyzed over 35,000 custom OmniScripts and TRAC programs. We built custom applications specifically to parse, categorize, and map these scripts. Without this step, we would have migrated the data but broken the business logic.

Takeaway: Before you start any migration, audit your customizations. All of them. If you don't know what you have, you don't know what you need to move.

Lesson 2: Three Dry Runs, Not One

We executed three progressively rigorous dry runs before go-live. Each one was a full simulation of the conversion process, with real data, real validation, and real defect tracking.

The first dry run finds the obvious issues. The second finds the edge cases. The third proves you're ready. Skip any of these, and you're gambling with production.

Takeaway: Budget time and resources for at least three full dry runs. The cost of an extra dry run is trivial compared to the cost of a failed production cutover.

Lesson 3: Build Custom Tooling

Off-the-shelf ETL tools can handle standard data transformations. But retirement platform migrations involve data structures, business rules, and validation requirements that no generic tool was designed for.

We built custom ETL applications, data standardization tools, and automated validation scripts specifically for this migration. The investment in custom tooling paid for itself many times over in accuracy and speed.

Takeaway: Don't force your migration into a generic tool. Build what you need for your specific source and target platforms.

Lesson 4: Staff With Practitioners, Not Analysts

The team that executes a migration needs to have operated both the source and target platforms. Not studied them. Operated them.

Our team included people who had personally written OmniScripts, configured TRAC plan rules, and run nightly batch processing on both platforms. That operational experience is what enabled us to catch issues that a test script wouldn't find.

Takeaway: The people doing the migration need to have been inside both systems. Domain expertise isn't optional — it's the difference between success and failure.

Lesson 5: Zero-Blackout Requires Zero Assumptions

The zero-blackout requirement forced a level of rigor that we now apply to every migration, regardless of whether the client requires it. When you can't afford a single day of downtime, you validate everything.

Every participant record. Every balance. Every plan configuration. Every trading integration. If it exists in the source system, it has to be verified in the target system.

Takeaway: Even if your client says a short blackout is acceptable, plan for zero. The discipline required for zero-blackout migrations produces better outcomes in every scenario.