What We Learned Migrating 700K Participants Without a Blackout

The Scale

The engagement covered 700,000 participants, $20 billion in assets, and 600+ individual retirement plans, all moving from FIS OmniPlus to SS&C DST TRAC. The client had one 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 is what we learned.

Lesson 1: Know Every Custom Configuration

The standard data usually moves cleanly. The biggest risk in any platform migration is 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 every one of your customizations. 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 Platform Practitioners

The team that executes a migration needs to have actually operated both the source and target platforms. Having studied them is not enough.

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 is what separates a successful migration from a failed one.

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.

That means every participant record, every balance, every plan configuration, and 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.