This database migration checklist splits 13 checks into those before cutover and those after it. Also, each comes with the evidence to ask for and an owner. Also, two verdicts come out of it. One covers switching to the new database, while the other covers retiring the old copy.
Last reviewed 2026-11-14 by Manish Sharma.
A managed database is one the cloud provider runs, patches and backs up for you. For example, the managed database services on AWS and Azure. Also, this guide covers the database itself: schema, data, users, jobs, connections, replication and the switch. However, files and application records sit outside it.
Database Migration Checklist: Scoring the Switch and Retirement
Scoring here means marking each check, but with no points and no totals. First, mark every check with one of three words. The marks then decide a verdict before the switch and another before retirement.
| Mark | What counts as evidence | Meaning |
|---|---|---|
| Evidenced | Done on this database, result kept | Shown |
| Booked | A dated slot and a named owner, not yet done | Planned |
| Unbooked | Nothing set, or no owner named | Missing |
Next, the switch verdict reads groups 1 and 2, nine checks in all. “Cut over now” needs no Unbooked mark and checks 5, 6, 7 and 9 Evidenced. “Retest first” has no Unbooked mark, but one of 5, 6, 7 or 9 carries only a Booked mark. If any Unbooked mark sits in groups 1 or 2, the verdict is “Delay the move”.
Then the retire verdict reads group 3, four checks. Then “Retire the old copy” needs all four Evidenced. “Keep it read-only” has no Unbooked mark, but at least one check carries a Booked mark. If any Unbooked mark appears, the verdict is “Keep it live”.
The switch verdict reads groups 1 and 2, while the retire verdict reads group 3.
Signisys working view: checks 5, 6, 7 and 9 decide the switch as they show the data, the applications, the way back and the restore on the new service. The other checks matter, but a failover test can wait for a date after a safe switch. Also, treat the rule as a starting point and adjust it with your own database lead, in writing.
Key Takeaway Checks 5, 6, 7 and 9 decide the switch, but every check still needs a mark.
Database Migration Checklist: Proof to Request Before and After Cutover
Then three groups follow the life of the move: groundwork, testing on a copy, and the days after users arrive. Then mark each group in order, and ask for the named evidence rather than a yes.
When the owner says yes, ask to see the record before you mark the check.
Use this database migration checklist one database at a time, as a shared mark hides the weak one.
Groundwork for the Move
| Check | Evidence to ask for | Owner |
|---|---|---|
| 1. Every database listed | The list, with owner, version and size | IT head |
| 2. Target chosen | A feature match note per database, from provider documentation | Database lead |
| 3. Engine change assessed | The assessment, or a recorded decision to keep the engine | Database lead |
| 4. Access and encryption set | Settings and an access review | Security lead |
First, check 1 finds the databases nobody remembers, and nobody moves or retires an unlisted one. Also, check 2 stops a surprise on the new service, such as a feature the target lacks. Then check 3 makes the engine question a decision with a name on it. Check 4 comes before the data arrives, so nothing sits open in the meantime.
Database Migration Testing on a Rehearsal Copy
| Check | Evidence to ask for | Owner |
|---|---|---|
| 5. Data matches | Comparison output with row counts and samples | Database lead |
| 6. Applications connect | A test run for each application, with queries | Application owner |
| 7. Restore works | A dated restore of a backup on the target | Platform lead |
| 8. Failover works | A dated failover run | Platform lead |
| 9. Rollback rehearsed | A timed rehearsal record | IT head |
Failover means the database switches to a standby copy when the main one stops. Check 5 pairs counts with samples, as counts alone can match while values differ. Also, check 6 runs the real queries each application sends. Check 7 shows a backup can come back, while check 8 shows the standby takes over. Check 9 times the way back, so the decision to return to the old copy has a known cost in hours.
Once Users Are on the New Database
| Check | Evidence to ask for | Owner |
|---|---|---|
| 10. Data compared again | A post-switch comparison | Database lead |
| 11. Monitoring live | Alert list, plus one alert fired as a test | Platform lead |
| 12. First backup restored | A dated restore of the first backup on the new service | Platform lead |
| 13. Sign-off per database | A signed record | Application owner |
Check 10 catches changes made while the switch ran. Also, check 11 shows an alert reaches a person, not only that a rule exists. Next, check 12 differs from check 7, as it restores a backup the new service made on its own schedule. Check 13 puts one name against each database, and the old copy stays until that name signs.
Database Migration Checklist: A Worked Move for One Orders Database
First, the orders case below is a sketch for reading the rules, not work Signisys has done. Also, an orders database moves to a managed service, and the team marks all 13 checks on cutover day.
| Group | Checks | Mark |
|---|---|---|
| 1. Groundwork | 1, 2, 3, 4 | All Evidenced (3: no engine change, decision recorded) |
| 2. Testing | 5, 6, 7, 9 | Evidenced |
| 2. Testing | 8 | Booked |
| 3. After the switch | 10, 11 | Evidenced |
| 3. After the switch | 12, 13 | Booked |
First, for the switch, groups 1 and 2 have no Unbooked mark, and checks 5, 6, 7 and 9 carry Evidenced marks. The failover test in check 8 carries only a Booked mark, but it does not gate the switch. Then the verdict is “Cut over now”. Also, the failover date stays in the plan.
For retirement, group 3 has no Unbooked mark, but checks 12 and 13 carry only Booked marks. Then the verdict is “Keep it read-only”. The old copy stays in place for reading until both checks carry an Evidenced mark. At that point all four carry Evidenced marks, and the verdict moves to “Retire the old copy”.
Key Takeaway A Booked failover test does not gate the switch, but Booked checks 12 and 13 keep the old copy read-only.
Database Migration Checklist: Acting on Each Verdict
Each verdict maps to one next step. Then mark again after each step, as the verdict can change in a day.
“Delay the move” means close the Unbooked checks, with group 1 first, as later checks lean on it. “Retest first”, however, means rerun the Booked checks among 5, 6, 7 and 9. “Cut over now” means cut over, then start group 3 at once.
After the switch, “Keep it live” means fix the Unbooked check, while the old copy stays as the working one. “Keep it read-only”, however, means set a dated close for each Booked check. However, “Retire the old copy” ends the old copy’s life. Also, the record of that decision belongs with the sign-off in check 13.
Signisys working view: a cloud database migration checklist works best as a living page that the owner of each check updates, not a document filed at kickoff. The basis is the two verdicts above, which change as soon as one mark changes.
Guides to Read Beside This One
Also, each guide below covers a different question, and this guide repeats none of their lists.
- what running your own database costs the team in upkeep covers the burden of self-managed databases.
- the order for each move step covers the steps in sequence.
- the host checks for Windows Server workloads covers servers, including those running Windows Server.
- application-level checks for a cloud move covers the checks around applications.
However, backup checks in general sit in a separate backup checklist. Also, the choice between managed and self-managed databases is set out in a plain way to decide who should run the database. Prices are out of scope here. Next, for a short list of data checks, see the AWS data migration checklist for small firms. As read on 14 November 2026 (the page carries the date 20 October 2025), it targets small and medium businesses. Also, it covers dry runs, rollback playbooks and data validation.
Signisys does this work. For examples, see how Signisys handles cloud database migration to AWS and Azure, our cloud migration and modernization solution and cloud computing and platform engineering support. Then a working session reads your marks next to your own evidence, but offers no pledge about what it will find. No charge, with a fixed scope.
Database Migration Checklist FAQ
How many checks need evidence before cutover?
Can data match on row counts and still be wrong?
When is the old copy safe to retire?
What verdict does a database with no named owner get?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.