Checklist: migrate SQL Server to a managed database

Who this is for

This guide is for founders, CTOs, IT managers and operations leads who run SQL Server on their own hardware or a cloud virtual machine and want to move it to a managed service. The target may be Azure SQL Database, Azure SQL Managed Instance, Amazon RDS for SQL Server or Cloud SQL for SQL Server.

The move is not a backup and restore with a new connection string. A managed database takes away the operating system, server level controls and some SQL Server features. It adds automated backups, patching, high availability options and a different billing model. You need to know which features your applications use before you pick the target.

Read this if a failed move would stop order processing, payroll, reporting or a customer portal. It is also for teams that found the application depends on a linked server, a SQL Agent job or a cross database query. Those are normal findings, not reasons to stop.

Before you begin

Start with an inventory that comes from the server, not from memory. For each database record the version and edition, compatibility level, collation, recovery model, size, growth rate and whether Transparent Data Encryption is on. Record server level objects: logins, linked servers, SQL Agent jobs, credentials, proxies, maintenance plans, alerts and operators.

List dependencies outside the database engine. SSIS packages, SSRS reports, SSAS cubes, CLR assemblies, PowerShell scripts and connection strings all matter. Check for cross database queries, three part and four part names, distributed transactions, replication, log shipping and Service Broker.

Capture a performance baseline before you change anything. Enable Query Store if the version supports it, or collect wait stats, top queries by CPU and duration, and disk latency. You need this to compare after migration and to size the target. A target sized only by data volume will often be wrong.

Choose the target service and the migration method together. A service that supports SQL Agent and cross database queries may need fewer code changes. Write down the decision and the reasons. You will need them when someone asks why the team is not using the cheapest option.

The checklist

Work in order. Each item produces an artifact: an inventory sheet, an assessment report, a test result or a runbook. If an item cannot be completed, record the gap and the owner. A restore proves the backup works, not that the application works.

Use a staging copy of the target service that matches production in size and configuration. A small test instance will hide query plan changes, connection pool issues and storage throughput limits. Load a full copy of the largest database when you test the cutover.

Run the checklist once for a pilot database and again for the full estate. The second pass is faster because the runbook and validation scripts already exist. Keep a decision log for feature gaps and performance differences.

• Confirm that every database, not just the main one, is supported by the target service.
• Inventory logins, roles, permissions, SQL Agent jobs, linked servers and credentials, then assign an owner.
• Run Microsoft Data Migration Assistant or the provider assessment tool and record every blocking issue with a fix.
• Size the target by CPU, memory, storage throughput and tempdb needs using the production baseline, with headroom for batch jobs.
• Decide whether to use backup and restore, log shipping, a migration service or an export and import tool, and write down why.
• Create the private network path, set firewall rules, and test name resolution from every application server.
• Convert SQL Server logins to contained users or map them to the target identity system, then test each application account.
• Rewrite or replace unsupported features such as cross database queries, SQL Agent for Azure SQL Database, CLR and linked servers.
• Validate data with row counts, checksums, identity seed values, index counts and a sample of business critical reports.
• Test the application with a production sized load and compare query plans, wait stats and response times against the baseline.
• Rehearse the cutover at least twice, including the write freeze, final backup, restore, validation and application start.
• Write a rollback plan that names the trigger, the owner, the steps and the time limit, then test it.
• Configure automated backups, point in time restore, alerts, patching windows and maintenance jobs on the first day.
• Update connection strings, DNS records, monitoring and runbooks, then run a post cutover review.

What good looks like

A good migration has evidence, not assurances. The application connects through the same name or a controlled DNS change, uses the new identity model, and completes its main workflows. Batch jobs run on schedule. Reports return the same totals.

Alerts cover CPU, storage, deadlocks, failed jobs, backup failures and connection errors. You know who receives each alert and what that person does first. The team has a runbook for failover, restore and scale up or down.

Performance is close to the baseline or the difference is understood. Some queries will change plan and some will need an index or a rewrite. A good cutover review lists those changes and assigns follow up.

The source server stays available in read only mode for a defined period. You have a date to decommission it and a list of checks before that happens.

What to do next

Assign one owner for the migration and one technical lead for the database. Book a short weekly review with application owners. The first deliverable is the inventory and the feature gap list, not a target purchase.

Pick one database as a pilot. Run the full checklist on it, including a timed cutover rehearsal. Use the results to estimate the work for the rest of the estate. Do not multiply a single database result by the number of databases without checking shared dependencies.

If you want a structured start, the Cloudverg Discovery and roadmap sprint is a two week fixed price engagement at $9,500. It covers stakeholder interviews, current state review, target architecture, a phased roadmap with risks and dependencies, and a fixed price quote for phase one. You can also use your own team, a database consultant or the cloud provider migration service.

Start with the inventory this week. A clear target decision and one tested pilot database are more useful than a long list of assumptions.

Frequently asked questions