The Legacy Data Migration Playbook

Most legacy migrations don't fail because the new technology is wrong. They fail because the old system encoded twenty years of business rules that nobody documented, and the migration plan assumed the documentation was the system.

After running migrations at Vivint (SQL Server to Snowflake), Ancestry (SQL Server to MPP), and across consulting clients, we've converged on a playbook that makes migrations boring. Boring is the goal. Here it is.

1. Do archaeology before architecture

Before designing anything new, map what actually runs: every scheduled job, stored procedure, report, and the spreadsheet workflows hanging off them. The dependency graph you produce will contradict the official architecture diagram — trust the graph. Budget real time for this; it is the highest-leverage work in the entire program.

The deliverable is a verified inventory with owners and consumers for every data flow. Anything with no identifiable consumer is a candidate to not migrate at all — typically 20–40% of a legacy estate is dead weight, and the cheapest record to migrate is the one you delete.

2. Migrate by subject area, highest pain first

Big-bang migrations concentrate all risk on one date. Instead, slice the estate into subject areas and migrate them one at a time, starting where the business hurts most. Each slice delivers value on its own, builds trust with stakeholders, and teaches you about the estate before the stakes rise.

3. Parallel-run until the evidence says cut over

Run the old and new pipelines side by side, and build automated reconciliation that compares outputs — not eyeball checks, row-level comparison with tolerances you've agreed with the business. Publish the reconciliation report daily where stakeholders can see it.

Cut over a subject area only after reconciliation holds clean for a full business cycle — typically two weekly cycles or one monthly close. The calendar doesn't decide the cutover; the evidence does. And every cutover ships with a rehearsed, scripted rollback.

4. Make the old system read-only, then keep it that way

The migration isn't done when the new system works; it's done when the old one is decommissioned. Set a read-only date, hold it, and bank the savings. Estates that keep the legacy system 'just in case' end up running two platforms forever — the most expensive possible outcome.

If your team is staring at a migration like this, a two-to-three week diagnostic is usually enough to produce the dependency map and a costed, phased plan. That's exactly the kind of engagement we run — and the plan is yours whether or not we execute it.