Who this is for
The Checklist: migrate a data warehouse to the cloud is for founders, CTOs, data leads and finance or operations managers who already run a warehouse and need to move it without breaking reporting. You have nightly loads, a semantic layer and dashboards that people trust. That is the hard part, not copying the bytes.
This is not the same as moving an application database. A warehouse holds history, wide tables, batch jobs and reports that finance closes the month with. A missed join or a changed date key can show up as a wrong margin number weeks later.
Use this checklist when the target is a cloud warehouse or a data platform that runs on cloud object storage and compute. If you are still choosing a platform, finish that decision first. The steps below assume you have a target and a pilot scope.
Before you begin
Start with a measured baseline. Pull row counts, table sizes, daily growth, retention rules and the longest running queries from the current system. Write down the load window, peak reporting hours and every downstream tool that reads the warehouse.
Choose a migration pattern and write it down. Lift and shift copies schemas and jobs with small changes, which is faster but may keep bad models. Re-platform moves to a new engine with rewritten SQL and tuning. Rebuild redesigns marts and pipelines, which takes longer and gives the cleanest result.
Agree on what done means before anyone copies data. Pick one finance mart and one operations mart as pilots. Name the report owners who will sign off. Confirm identity, network, secrets, logging and budget guardrails are in place. Freeze schema changes in the old warehouse during the pilot, or you will chase a moving target.
The checklist
Work through the list in order, but expect loops. A sizing check may send you back to the query inventory. A failed acceptance test may change the cutover plan.
Keep one owner for the migration and one owner for each mart. The data team can move tables, yet finance has to confirm that the numbers still mean the same thing. Record exceptions in one place, with a name and a date.
- List every source system, feed, table and file that lands in the warehouse, with a business owner for each one.
- Record row counts, daily growth, retention rules and the largest tables before you choose a target platform.
- Capture the top queries, dashboards and scheduled reports with their run times and peak hours.
- Map every ETL or ELT job, including dependencies, retries, alerts and the person who fixes failures.
- Decide which marts move first and which reports can be retired instead of migrated.
- Write acceptance tests that compare row counts, key totals and a sample of business metrics between old and new.
- Size compute and storage from measured workloads, then set budgets, quotas and alerts before loading production data.
- Move identity, roles and data access rules first so testers see the same permissions as production users.
- Test the network path and transfer method with a full size copy of the largest table, not a small sample.
- Rebuild the semantic layer and BI connections against the new warehouse, then get each dashboard owner to sign off.
- Run old and new loads in parallel long enough to cover month end, late files and a failed job.
- Plan the cutover window, the rollback point and the read only period for report users.
- Schedule decommissioning only after you archive code, job history and access records.
What good looks like
A good migration leaves the business with the same trusted numbers and a simpler operating model. Finance can close the month on the new warehouse without a spreadsheet fix. Report owners know where their data comes from.
Loads finish inside the agreed window, and failed jobs raise alerts that someone answers. Access follows the same rules as before, with no shared admin account left behind. The cost model is visible by team or workload, so a runaway query has an owner.
Documentation is short and current: a data flow diagram, a runbook for each load, a list of known exceptions and a rollback plan. The old warehouse stays read only for an agreed period, then gets turned off. You keep the history you need for audit and support, not every temporary table.
What to do next
Pick the pilot mart and book the validation sessions now. A migration plan without report owner time is a copy project, not a warehouse move. Give each owner the acceptance tests before the first load.
Write a one page decision record for the migration pattern, target platform and cutover date. Add the risks you accept and the ones you will not. Review it with finance and operations, not only with engineering.
If you want a structured start, the Discovery and roadmap sprint from Cloudverg is a fixed price $9,500 two week engagement that ends with a target architecture, a phased roadmap and a fixed price for phase one. It is one option among others. You can also run the pilot with your own team, hire a data engineer, or use a platform vendor migration service. Keep the checklist as the control, whoever does the work.
Frequently asked questions
How long does a data warehouse migration take?
It depends on how many marts you move, how messy the ETL jobs are and how much history you keep. A pilot mart can move in a few weeks, while a full warehouse with finance reporting usually needs a staged plan over several months. Build the schedule from acceptance tests and report owner availability, not from the copy speed.
Should we lift and shift or rebuild the warehouse?
Lift and shift gets you off the old system fast, but it carries old schemas and tuning problems into the new platform. Rebuilding takes more design time and can give you cleaner models and lower run costs. Pick lift and shift for a short exit, and rebuild when the warehouse has outgrown its design.
What should we validate before cutover?
Validate row counts, key totals, join results and a fixed set of business metrics that finance and operations already trust. Test permissions, load windows, failure alerts and the rollback steps too. Get sign off from report owners, not only from the data team.