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 data protection obligations.
Organisations 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. Replication over the internet also depends on your connectivity, so a migration from an on-premises server needs a reliable link (ideally fibre with a second provider as backup) and steady power at the source site for the whole parallel period.
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 synchronisation 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.
Data protection, location and security
This is general information, not legal advice.
- Personal data remains subject to the Nigeria Data Protection Act 2023 (NDPA) throughout the migration, including in temporary copies and test environments. The Nigeria Data Protection Commission (NDPC) enforces it, and its General Application and Implementation Directive (GAID) 2025 sets out how the Act applies in practice. A large migration of personal data is often a good reason to carry out a data protection impact assessment.
- Transfers outside Nigeria are allowed under the NDPA only on a recognised basis, such as adequate protection in the destination or appropriate safeguards (for example, contractual clauses), and the organisation remains accountable for the data. Record the basis you rely on and be open with individuals about it.
- Where the data lands. There is no major public cloud region in Nigeria, so the choice is usually between a local data centre (in Lagos or Abuja, for example) and a cloud region abroad, with South Africa and Europe the nearest large options. Choose in line with NDPA transfer rules and any sector rules (for example, Central Bank of Nigeria requirements for banks or NITDA guidelines for public institutions). Backups, replicas, logs and support access also need checking, not just the primary copy.
- 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;
- exchange-rate movements on cloud services billed in US dollars.
Set a planned end date for the parallel run and track it.
Hypothetical example. A health maintenance organisation (HMO) runs an on-premises reporting database that feeds finance reports, employer 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; complete a data protection impact assessment and decide on the target location (a local data centre or a cloud region abroad with a documented transfer basis); move the data to a managed database with ongoing replication from the old platform; repoint the analytics team first, then employer 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.
- Data protection review completed for the target location, any transfer outside Nigeria 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
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.