The Database Migration Checklist Nobody Follows

There’s a specific kind of dread that shows up about two hours into a migration cutover window, when someone asks “wait, did we account for the linked server on the reporting box?” and the room goes quiet. Migrations rarely fail because the technology doesn’t work. They fail because somebody assumed a dependency didn’t exist, or nobody tested the rollback plan, or the “quick database move” turned out to have four applications quietly connecting to it that weren’t on anybody’s list.

This article is a practical, phase-by-phase checklist for planning a database/cloud migration — written with Azure SQL migrations specifically in mind (since that’s the world this whole series lives in), but the underlying discipline applies broadly to any serious migration. The goal isn’t to make migrations sound scarier than they are. It’s the opposite — a good checklist is what turns a migration from a nerve-wracking leap into a genuinely boring, well-rehearsed process. Boring is exactly what you want during a cutover.

Phase 1: Discovery

You should know What You’re Actually Moving

You cannot plan what you haven’t found. This phase is about building a complete, honest inventory before anyone starts talking timelines.

Inventory every database, its size, version, and edition
Run a discovery/assessment tool (Azure Migrate for a broad estate; it now covers VMware, Hyper-V, physical servers, and multi-cloud sources, and includes PostgreSQL discovery alongside SQL Server) to catalog what actually exists — don’t rely on a spreadsheet someone made two years ago
Map application-to-database dependencies — which apps connect to which databases, and which databases talk to each other via linked servers
Catalog SQL Agent jobs, SSIS packages, SSRS reports, CLR assemblies, and any cross-database references
Identify authentication methods in use (SQL logins vs. Windows Authentication vs. Entra ID) — this affects your target platform choice significantly
Note peak usage windows and realistic downtime tolerance for each workload
Flag anything undocumented — the old rule holds: if nobody can explain what a database does, that’s not a sign it’s safe to ignore, it’s a sign nobody’s found its dependency yet

Why this is important: the single most common cause of an unplanned outage during a migration wave isn’t a technical failure — it’s an undiscovered dependency. Application A quietly depending on a database in Server B, migrated three waves earlier, with nobody having updated the connection string. Tools like Azure Migrate’s dependency mapping exist specifically to catch this before it becomes a 2 AM incident.

Phase 2: Compatibility Assessment

Try to identify the Blockers Early

This is where you find out, ahead of time, what’s actually going to fight you.

Run Data Migration Assistant (DMA) or SQL Server Migration Assistant (SSMA) against every source database to detect compatibility issues, deprecated features, and breaking changes
Review flagged blocking issues — common ones include unsupported linked server types, FILESTREAM usage, Windows Authentication dependencies, and legacy CLR assemblies
Decide a remediation plan for each blocker: replace FILESTREAM with Azure Blob Storage, convert Windows Auth logins to Entra ID—based access, migrate SSRS reports to Power BI, review and modernize CLR assemblies
Confirm compatibility level requirements — some application code depends on legacy behavior tied to a specific database compatibility level
Test third-party tool and driver compatibility against the target platform

Point to remember: migration tooling itself keeps evolving — SSMA has been updated with a clearer, more current set of supported source and target platforms, and some of the Azure Data Studio–based migration extension tooling has shifted toward VS Code equivalents. If your migration plan or runbook was written more than a year ago, it’s worth a quick re-check against current tooling before you commit to a timeline — assuming last year’s tool list is this year’s tool list is an easy, avoidable mistake.

Phase 3: Choose Your Target Platform and Migration Method

Pick Target platform based on what you actually need

Not every database belongs on the same target, and not every migration should use the same method.

If you need…	Consider…
Minimal management overhead, single-database isolation, elastic scaling	Azure SQL Database
Near-full SQL Server surface area compatibility (SQL Agent, linked servers, cross-DB queries)	Azure SQL Managed Instance
Full OS-level control, or software that simply won’t run anywhere else	SQL Server on an Azure VM (IaaS)

Pick Migration method based on downtime tolerance and database size

Downtime Tolerance	Recommended Approach
Near-zero downtime required	Online migration via Azure Database Migration Service (DMS), or Managed Instance link for continuous replication with a fast cutover
Some downtime acceptable (a maintenance window works)	Offline DMS migration, or classic backup/restore
Very large databases (tens of terabytes+) with limited network bandwidth	Physical transfer via Azure Data Box, often paired with a shorter online catch-up phase for the final delta

Confirm which migration method fits each database’s size and downtime tolerance — don’t default to one method for the whole estate
For DMS online migrations, confirm continuous replication is actually keeping pace with your source system’s change rate during a test run, not just in theory
For Data Box, remember the practical crossover point is commonly cited around 10 TB or more, where network transfer would simply take too long to be practical

Phase 4: Security and Compliance Planning

This is the phase where “we’ll figure out security after we move it” turns into a real problem, so don’t leave it for later.

Plan the authentication model for the target: SQL logins as a narrow exception, Microsoft Entra ID authentication as the default for human users, managed identity for application-to-database connections
Confirm Transparent Data Encryption (TDE) will be enabled on the target — it’s on by default for most Azure SQL offerings, but confirm rather than assume, especially for customer-managed key requirements
Identify columns that may need Always Encrypted (with or without secure enclaves) for sensitive data subject to strict internal access limits
Re-map RBAC roles and database permissions — this is a good moment to actually clean up years of accumulated db_owner grants rather than copying them forward unchanged
Confirm network security requirements: private endpoints, VPN or ExpressRoute connectivity, firewall rules
Check regulatory requirements relevant to your industry (HIPAA, PCI-DSS, SOC 2, FedRAMP, GDPR) against the target platform’s compliance posture and your own configuration choices
Plan your Extended Events monitoring sessions for the new environment ahead of go-live, not as an afterthought once something’s already gone wrong

Migrating is genuinely one of the best opportunities you’ll get to fix long-standing security debt, overly broad permissions, ancient SQL logins nobody remembers creating, missing encryption on sensitive columns. It’s far easier to build it right on a fresh target than to retrofit it later once the business has settled back into “don’t touch it, it works.”

Phase 5: Cost and Sizing

Use assessment tool sizing recommendations based on actual utilization data (ideally two or more weeks of real usage, not guesswork) rather than simply matching on-premises specs one-for-one
Resist the urge to lift-and-shift on-premises sizing directly — over-provisioning based on old on-prem sizing is one of the most common and avoidable sources of cloud bill overruns
Evaluate Azure Hybrid Benefit if you have existing Windows Server/SQL Server licenses under Software Assurance — this can meaningfully reduce compute costs
Model Reserved Instance or reserved capacity pricing for predictable, steady-state workloads once right-sizing is settled
Build a realistic TCO comparison, not just a sticker-price comparison — factor in reduced patching/maintenance labor, backup costs, and licensing changes

Phase 6: Testing & Rollback Plan

This is the phase people skip and latter regret skipping

Restore a full copy of the source database onto the target platform in a non-production environment
Run the application’s actual query workload against the restored copy. It should not a synthetic “SELECT 1” smoke test
Validate performance against a real baseline, not a gut feeling (“it feels about the same” is not a test result)
Test every integration point: reporting tools, ETL jobs, scheduled tasks, third-party connectors
Explicitly test the rollback plan. If cutover goes wrong, does your team actually know, step by step, how to reverse it, or is that assumption untested?
Run a full rehearsal of the cutover sequence at least once before the real one, ideally with the same people who’ll be executing it live

A rollback plan you’ve never rehearsed is a rollback plan you don’t actually have. This is the step most likely to get compressed under deadline pressure, and it’s also the step whose absence is most likely to turn a bad night into a genuinely bad week.

Phase 7: Cutover Planning

Set a specific cutover window, communicated clearly to every affected team, with a defined start and a hard decision point for “are we going or rolling back”
Assign clear roles: who executes the migration, who validates it, who has the authority to call a rollback
Prepare updated connection strings and configuration changes in advance, ready to deploy rather than written live during the window
Plan the exact sequence: final delta sync (for online methods), application pause/quiesce if needed, DNS or connection string cutover, validation checks, application resume
Define go/no-go validation criteria in advance ” what specifically needs to be true before you declare success”, should be decided calmly beforehand rather than negotiated under pressure during the window
Have a communication plan ready for stakeholders regardless of outcome. “it succeeded” and “we’re rolling back” both need a clear, fast message out

Phase 8: Post-Migration

Monitor performance closely for the first days/weeks. Extended Events sessions for slow queries, blocking, and waits are exactly the right tool here, and having them already configured before go-live (from Phase 4) pays off immediately
Validate backup and restore procedures actually work on the new target. Please don’t assume, test a real restore
Confirm PITR, geo-restore, and any LTR policies are configured to your compliance requirements on the new platform, not left at defaults
Decommission the old environment only after a defined, deliberate retention period. Don’t rush this; a “we can always turn it back on” safety net is worth keeping around for a while
Document should be created for what was learned. Every migration surfaces at least one thing nobody anticipated, and that’s genuinely useful information for the next try or migration
Establish an ongoing operating model: who owns cost governance, incident response, and security operations for the new environment going forward

A Real-World Walkthrough

A mid-sized insurance company plans to migrate its claims processing database from an aging on-premises SQL Server instance to Azure SQL Managed Instance. Discovery turns up something nobody expected: a legacy reporting server has a linked server connection into the claims database that isn’t documented anywhere, feeding a nightly regulatory report nobody on the current team even knew existed. Because that got caught during Phase 1 discovery — not during cutover weekend — the team has time to plan around it instead of discovering it via an angry compliance officer on a Monday morning.

The DMA compatibility scan flags two blockers: a handful of CLR assemblies used for custom string formatting, and heavy reliance on SQL Server Agent jobs. Because Managed Instance supports Agent jobs natively (unlike Azure SQL Database), that concern resolves itself simply by choosing the right target platform — one more reason Phase 3’s platform decision needs to happen with real information in hand, not as a default choice made on day one.

Given the claims database’s size and the business’s genuine near-zero downtime requirement (claims processing can’t just stop for an afternoon), the team chooses DMS online migration with continuous replication, tests the full cutover sequence twice in a staging environment, and executes the real cutover at 2 AM on a low-traffic Sunday, with a clearly defined 30-minute go/no-go decision point. Because the rollback plan was actually rehearsed in Phase 6, when the initial performance check post-cutover looked marginally slower than baseline, the team confidently diagnosed it as a stale query plan cache rather than panicking — a problem solved with a plan refresh, not a rollback.

None of this was dramatic. That’s the point. A well-planned migration is supposed to be uneventful.

Key Takeaways

Migrations fail from unmapped dependencies and untested assumptions far more often than from the underlying technology not working — discovery and testing are where the real risk lives, not the cutover itself.
Run a compatibility assessment (DMA/SSMA) early enough that blockers become a planning input, not a cutover-weekend surprise.
Match your target platform and migration method to actual requirements — downtime tolerance, database size, and feature dependencies — rather than defaulting to one approach for an entire estate.
Treat migration as a genuine opportunity to fix accumulated security debt (broad permissions, legacy SQL logins, missing encryption) rather than carrying it forward unchanged.
Rehearse the rollback plan before you need it — an untested rollback plan is, in practice, no rollback plan at all.
The best cutover is the boring one: clear roles, pre-defined go/no-go criteria, and a sequence the team has already run through at least once before it counts.

Read more articles on SQL server & Azure SQL

Top 50 On-Premise to Azure SQL Migration Interview Questions and Answers (Beginner to Advanced)

Azure SQL Migration Methods: The Complete Step-by-Step Guide for Seamless Database Modernization

Azure Database Migration Service: Seamless Cloud Migration Guide

Migration and Mapping Strategies: A Detailed Guide for Data Professionals

Migrating SQL Database To Azure SQL Instance using Microsoft Database Migration Assistant (DMA) Tool

SQL Server Execution Plans Explained: A Beginner’s Guide for DBAs and Developers

Top 50 Azure SQL Execution Plan Interview Questions and Answers (Beginner to Advanced)

For Interview Questions on SQL SQL Server, Azure SQL, Performance Tuning, Security, and DBA, click the link below:-