Large-scale database migration checklist — what to settle before you start
Large migrations rarely fail because they were technically impossible. They fail because work started before anyone decided what had to be verified.
This page is for whoever is planning a large database migration. What follows is a general set of checks, not a full account of what GIIP performed in any particular engagement. The items that actually apply differ by environment.
No agreed definition of "enough checking"
The list of things to verify has no end, so the decision to start never gets made.
No rollback procedure
Nobody has defined the trigger, or the steps, for going back if cutover day goes badly.
No owner after the migration
The moment the project closes, monitoring and incident response have no assignee.
Verification scope was never agreed
Without a definition of done, neither effort nor schedule can be fixed.
Business constraints were never translated
"We cannot go down" was never converted into a number of hours the business will accept.
The inventory is still manual
In a large estate, the list is never finished unless extraction is mechanical.
Not just list the checks, but define in advance the standard by which checking is complete.
Agree verification scope
Fix in writing, before work starts, what constitutes a completed migration.
Write down the rollback trigger
Decide in advance what has to happen for you to go back, and how long going back takes.
Assign post-migration operations
Decide at the outset whether GIIP continues monitoring, performance analysis and incident response, or hands over.
Settle these before you start
- Source and target products and versions
- Data volume and total number of tables and objects
- Differences in schema definitions, data types, character sets and collations
- Inventory of stored procedures, triggers and jobs
- Inventory of external integrations (files, database links, APIs)
- How accounts, logins and permissions carry over
- Backup and restore procedures, redefined for the target
- Tolerable downtime, agreed as a business constraint
- Cutover procedure, plus the rollback trigger and steps
- How counts and definitions are reconciled before and after
- What is monitored afterwards, and by whom
- The escalation path when a performance regression is detected
Scale GIIP has actually handled
The checklist above is general technical explanation. It does not mean every item was used in these engagements.
Frequently asked questions
Can we use this checklist as-is?
As a starting point, yes, but the items that matter depend on the source/target combination. Migrating between the same product and changing engine are different checklists.
Can it be done with zero downtime?
It depends on data volume, write rate and how the application switches over. We do not claim it is possible before checking.
How much verification is enough?
"Enough" is settled by agreement, not by technology. Whether full reconciliation of counts and definitions is required, or sampling suffices, has to be agreed with the business before work starts.
Can you also monitor it afterwards?
Yes. GIIP continues to monitor and operate cloud databases after migration.
How to migrate SQL Server to AWS, and what to check first
Check for free whether your database can be migrated Oracle to AWSHow to migrate Oracle to AWS, and how to choose the target
Check for free whether your database can be migrated TiDB to Aurora MySQLCompatibility and pitfalls when migrating from TiDB to Aurora MySQL
Check for free whether your database can be migratedFind the gaps in your migration plan
Tell us your current configuration and the target you are considering, and we will set out what still needs to be settled.