CONSULT CIRCLE | CLOUD MIGRATION
The sequence that works, the risks worth planning for, and the checks that catch problems before your users do.
Database migrations fail differently from application migrations. An application that comes up wrong is obvious within minutes. A database that comes up wrong can look healthy for weeks, while a character set mismatch quietly corrupts a fraction of records or a missing index turns a report into a timeout.
That asymmetry is why database migration deserves its own plan rather than being treated as one task inside an application move. This guide sets out the sequence, a risk matrix you can work through with a DBA, and the post-migration checks that actually catch the silent failures.
What this guide covers
- Choosing the migration approach per database
- The step-by-step plan, in order
- A risk matrix to work through with a DBA
- The post-migration checklist that catches silent failures
Choose the migration approach first
| Approach | What it means | Best suited to | Main risk |
|---|---|---|---|
| Rehost - same engine, cloud VM | Same database engine on cloud infrastructure | Lowest-risk moves, unsupported versions, tight timelines | You inherit every existing operational burden |
| Managed service - same engine | Same engine as a managed platform service | Reducing operational overhead without changing the application | Feature and version gaps between self-managed and managed |
| Re-engine - different database | Migrating to a different engine entirely | Escaping licensing costs or reaching end of support | Highest effort and highest risk; SQL and behaviour differences surface late |
| Refactor - different data model | Redesigning the data layer, often to a different paradigm | Applications being rewritten anyway | Effectively a new build; do not attempt as part of a datacentre exit |
Table 1 - Database migration approaches.
The step-by-step plan
- Inventory every database, its version, size, growth rate, engine edition and licensing position. Include the ones nobody owns - they exist.
- Map dependencies: which applications connect, which scheduled jobs run, which reports and integrations read from it, and which other databases it links to.
- Capture a performance baseline before you touch anything. Query times, peak transactions, IOPS and connection counts. Without this you cannot prove the migration did not make things worse.
- Choose the approach per database using the table above, not one approach for all of them.
- Size the target against the baseline rather than against current provisioned hardware, which is usually oversized.
- Design connectivity, identity and encryption for the target, including how applications will authenticate.
- Build the target and restore a full copy for testing. Never test against a subset if you can avoid it.
- Run functional testing with the actual application, not just database-level checks.
- Run performance testing against the baseline, with production-like data volumes and concurrency.
- Set up replication or log shipping from source to target so the cutover window is short and the data is current.
- Rehearse the cutover end to end, including the rollback. A rehearsal that skips rollback is not a rehearsal.
- Cut over during an agreed window, with the rollback decision point and its deadline written down in advance.
- Run the post-migration checklist below before declaring success.
- Keep the source available and readable for an agreed period before decommissioning.
Risk matrix
| Risk | Impact | How to reduce it |
|---|---|---|
| Character set or collation mismatch | Silent data corruption on non-ASCII characters, found weeks later | Compare source and target settings explicitly; test with real data containing accented and special characters |
| Missing indexes or statistics after migration | Queries that ran in milliseconds take minutes | Verify index inventory post-migration and rebuild statistics before performance testing |
| Undocumented dependencies | An integration or overnight job breaks after cutover | Trace actual connections over a period long enough to capture monthly and quarterly cycles |
| Version or feature gaps in managed services | A stored procedure, agent job or extension does not exist on the target | Compatibility assessment before committing to the approach, not during build |
| Licensing changes on new infrastructure | Unexpected cost or non-compliance | Confirm licensing terms for the target model before design sign-off |
| Cutover window overrun | Business impact and pressure to proceed without rollback | Use replication so the final sync is short; rehearse with real data volumes |
| Insufficient rollback window | A problem found on day three has no route back | Keep the source readable and defined as authoritative for an agreed period |
| Performance regression | Users experience the migration as a downgrade | Baseline first, test against it, and hold cutover if the target does not meet it |
| Backup not re-established | The new database is unprotected and nobody notices | Verify a successful backup and a successful restore before the source is decommissioned |
Table 2 - Database migration risk matrix.
Post-migration checklist
Run all of these before the migration is signed off, and keep the evidence.
- Row counts reconciled between source and target for every significant table.
- Character set, collation and time zone settings compared and confirmed identical or deliberately different.
- Index inventory verified and statistics rebuilt.
- Query performance compared against the pre-migration baseline for the top queries by frequency and by duration.
- Every dependent application connects and completes a full transaction cycle.
- Scheduled jobs, agents and maintenance plans present, enabled and running on schedule.
- Reports and integrations verified, including monthly and quarterly ones that will not run during the window.
- Backup configured, a backup completed, and a restore tested. Not just configured.
- Monitoring and alerting attached to the new instance - see Monitoring as a Service.
- High availability and failover tested, not assumed.
- Security verified: encryption at rest and in transit, access controls, audit logging.
- Documentation and runbooks updated; the disaster recovery plan reflects the new location - see BC/DR Planning.
Where to go next
- Practical Cloud Migration Checklist: 10 Steps to Reduce Risk and Cost
- Choosing a cloud migration strategy per legacy application
- Hybrid cloud architecture decisions, for databases with heavy data gravity
- Disaster Recovery Services for protecting the database once it lands
Frequently Asked Questions
How long does a legacy database migration take?
For a single database with a straightforward rehost, four to eight weeks including testing and rehearsal. Re-engining to a different database engine typically takes months because the testing burden is far larger.
How do we minimise downtime during database migration?
Use replication or log shipping so the target is continuously current, leaving only a short final sync at cutover. The window is then determined by the final sync and validation, not by the size of the database.
Should we move to a managed database service?
It reduces operational overhead considerably, but check for version and feature gaps first. Agent jobs, extensions and administrative features available in a self-managed instance may not exist in the managed equivalent.
What is the most common cause of database migration failure?
Undocumented dependencies, followed by performance regressions from missing indexes or statistics. Both are avoidable with dependency tracing and a proper performance baseline.
How long should we keep the source database after migration?
Long enough to cover a full business cycle, which usually means at least one month-end. Keep it readable but clearly marked as non-authoritative so nobody writes to it by accident.
Talk to Consult Circle
We plan and deliver database migrations as part of wider cloud and datacentre exit programmes, including dependency tracing, rehearsal and post-migration validation. Book a free 30-minute call - 0203 916 5593 - info@consultcircle.com