The short answer
To migrate a large data platform (a data warehouse, reporting database, data lake or high-volume operational database) without disrupting operations:
- Inventory everything that reads from or writes to the platform, not just the data itself.
- Choose a migration pattern that lets the old and new platforms run side by side for a period.
- Reconcile counts, totals and key reports between old and new before switching.
- Cut over in planned steps, with a tested rollback.
- Decommission deliberately, respecting retention and privacy obligations.
Organizations that skip the inventory and reconciliation steps are the ones that discover, after cutover, that a monthly report or a downstream system quietly stopped working.
Step 1: build an inventory
A useful inventory covers:
- Data sets: databases, schemas, tables and files, with size, growth rate and owner.
- Consumers: reports, dashboards, analytics notebooks, applications, exports and scheduled jobs that read the data.
- Producers: applications, integrations and extract-transform-load (ETL) jobs that write it.
- Sensitivity: which data sets contain personal, health, financial or confidential information.
- Retention: how long each data set must be kept, and why.
- Usage: which data and reports are actually used. Migrations are a good moment to retire what nobody needs.
Cloud providers offer discovery tools that help. AWS, for example, describes DMS Fleet Advisor as building an inventory of servers, databases and schemas that could be migrated (AWS documentation). Tools find databases; only conversations with the business find out which reports matter.
Step 2: choose a migration pattern
| Pattern | How it works | Suits |
|---|---|---|
| Big bang | Copy everything, switch everyone at once | Smaller platforms, tolerant users, a long quiet window |
| Phased by domain | Move one subject area (for example, finance data, then sales data) at a time | Large platforms with clear domains |
| Parallel run with ongoing replication | Keep old and new in sync while consumers move gradually | Platforms that cannot tolerate downtime |
Parallel running depends on replicating changes from source to target. Services such as AWS Database Migration Service support both one-time migrations and ongoing replication to keep sources and targets in sync (AWS documentation). Other cloud providers and database vendors offer comparable tools.
Step 3: decide what changes and what does not
A migration is tempting to combine with redesign: new data models, new tools, new naming. Every change added makes reconciliation harder, because differences can come from the redesign rather than from errors. A common approach is:
- migrate like for like first, prove it, then improve; or
- redesign one domain at a time, reconciling each against the old platform.
Either way, document every intended difference so that it is not mistaken for a defect.
Step 4: reconcile before you switch
Agree acceptance tests with the people who use the data:
- row counts per table and per load;
- totals of key amounts (revenue, claims, quantities) by period;
- a set of critical reports produced from both platforms and compared;
- spot checks of individual records chosen by business users;
- performance of the slowest important queries.
Automate these checks so they can run repeatedly during a parallel period.
Step 5: plan the cutover
A cutover plan lists every step, who does it, how long it takes, and how to reverse it. Include:
- a freeze on schema changes before cutover;
- the final synchronization and a last reconciliation;
- repointing of reports, applications and integrations;
- a communication plan for users;
- a rollback trigger (what result would make you switch back) and a tested rollback procedure.
Run at least one rehearsal on a copy of production data.
Privacy, residency and security
This is general information, not legal advice.
- Personal information remains subject to PIPEDA or applicable provincial laws throughout the migration, including in temporary copies and test environments (Office of the Privacy Commissioner).
- Cross-border processing is generally permitted under PIPEDA, but the organization remains accountable and should use contractual and other means to provide comparable protection, and be open with individuals about it (OPC guidelines).
- Canadian regions. AWS, Microsoft Azure and Google Cloud all operate Canadian regions. Choosing one supports data residency, but backups, replicas, logs and support access also need checking.
- Encryption and access. Encrypt data in transit and at rest, limit who can access migration tooling, and remove temporary copies when they are no longer needed.
Controlling cost
Large migrations can surprise finance teams. Watch for:
- the cost of running two platforms during a parallel period;
- data transfer (egress) charges when moving data out of an existing cloud or data centre;
- oversized target environments sized for peak rather than normal load;
- storage of data that should have been archived or deleted.
Set a planned end date for the parallel run and track it.
Hypothetical example. A group benefits provider runs an on-premises reporting database that feeds finance reports, sponsor statements and an analytics team. The hardware is ageing and nightly loads now overlap the start of the working day.
A low-risk plan: inventory every report and job; move the data to a managed database in a Canadian cloud region with ongoing replication from the old platform; repoint the analytics team first, then sponsor statements, then finance reports, reconciling each against the old platform; and switch off the old database only after a full month-end has run cleanly on the new one.
Cutover checklist
- Inventory of data sets, consumers, producers, sensitivity and retention is complete.
- Migration pattern chosen and agreed with business owners.
- Intended differences between old and new are documented.
- Automated reconciliation checks run successfully on production-sized data.
- Critical reports compared and signed off by their owners.
- Cutover rehearsed, with timings recorded.
- Rollback trigger and procedure agreed and tested.
- Privacy review completed for the target location and temporary copies.
- End date set for the parallel run and for decommissioning the old platform.
Limitations
Every migration has constraints this guide cannot cover: vendor licence terms, proprietary formats, application code tied to a specific database engine, or regulatory approvals. Some platforms cannot run in parallel at all, and then careful rehearsal matters even more.
Next step
Our cloud services and migration work covers planning, migration and validation. For analytics platforms, see data analytics and business intelligence, and for smaller system migrations, preparing your data for a CRM or ERP migration.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- What is AWS Database Migration Service?, Amazon Web Services
- Guidelines for processing personal data across borders, Office of the Privacy Commissioner of Canada
- PIPEDA in brief, Office of the Privacy Commissioner of Canada
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.