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 stays subject to the laws that apply to it throughout the migration, including in temporary copies and test environments. Depending on the data, that can mean HIPAA for health information (HHS), the GLBA Safeguards Rule for financial institutions, FERPA for student records, state breach notification laws and state comprehensive privacy laws. The FTC also expects businesses to keep the personal data they hold reasonably secure (FTC).
- Service providers and cross-border processing. The US has no single federal rule that forbids processing data abroad, but contracts, sector rules and customer commitments often limit where data may go. Make sure every migration vendor is covered by a written agreement (for example a business associate agreement where HIPAA applies) and that you are open with individuals about how their data is handled.
- US cloud regions. AWS (for example US East in N. Virginia and Ohio, US West in Oregon), Microsoft Azure (for example East US, Central US and South Central US in Texas) and Google Cloud (for example us-central1 in Iowa and us-south1 in Dallas) all operate US 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 center;
- 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 US 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 license 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
- Data security guidance for businesses, Federal Trade Commission
- HIPAA Security Rule, U.S. Department of Health and Human Services
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.