Migrations
The warehouse migration checklist we actually use
Forty items compressed to the twelve that prevent disasters. Inventory, parallel running, cutover criteria and the decommission list nobody writes.
The Cloud Practice1 min readMigrations
Warehouse migrations fail in predictable places, so the checklist concentrates there. This is the working version from our assessments, trimmed to what prevents disasters rather than what fills slides.
before anything moves
Inventory workloads by consumer, not by table: who reads each output, how often, and what breaks if it is a day late. Capture a cost and performance baseline on the current platform, or you will never be able to prove the migration helped. Pick the target with the current platform field in view, but weight your own workload profile over any ranking.
during
Migrate by consumer group, not by layer. Moving all staging tables first feels tidy and proves nothing; moving one dashboard's full lineage end to end proves the pattern. Run old and new in parallel with automated reconciliation on row counts and key aggregates, and publish the diffs where stakeholders can see them shrinking. Write cutover criteria before the parallel run starts: reconciliation tolerance, performance thresholds, sign-off owners. Criteria written during the run get negotiated by fatigue.
after
The decommission list is the checklist item most often skipped, which is why so many companies pay for two warehouses years after "finishing" a migration. Every source-side job, extract and permission gets an explicit end date, and the old platform's bill is tracked to zero.
A migration is finished when the old system is off, not when the new one is on. If you want a second set of eyes on scope before you commit, that is exactly what the assessment exists for.