What migrating off an on-premises warehouse actually looks like

When a client asks for a warehouse migration, they usually mean: move our data from an on-premises SQL Server box to Azure, Databricks, or Fabric. That part is mechanical — extract, land, transform, load, repeat. The part that actually determines whether the project succeeds is something else entirely: keeping every existing report correct throughout.

The pattern I use on almost every migration is to run the old and new platforms in parallel for a defined period, reconciling output at the row level, not just the total level. Totals matching is not the same as rows matching — I've seen platforms pass a total-revenue check while a whole customer segment was silently missing, offset by a rounding difference elsewhere. Row-level reconciliation catches that; total-level reconciliation doesn't.

The second pattern is to migrate by subject area, not by source system. Cutting over 'all of finance' at once, tested and reconciled, is safer than cutting over 'all of SAP' — because a subject area has a bounded, known set of reports depending on it, and you can tell the business exactly when their reports are safe to trust on the new platform.

The unglamorous truth is that a migration project is mostly a testing and change-management project wearing a technical-architecture hat. Budget your timeline accordingly — the pipelines are the easy part.