Architecture

How to Migrate SQL Server to Azure: Options, Steps and Tools

A practical guide to moving a SQL Server estate to Azure: choosing between Managed Instance, a virtual machine and Azure SQL Database, assessing compatibility, sizing the target, picking a cutover method and what to check afterwards. Written for organisations anywhere, with region notes for South Africa, the US and Europe.

Need a hand with this? Talk to a senior database DBA ↓

By RadixTrie5 September 20265 min read

Moving SQL Server to Azure is usually framed as a technical migration. It is really a decision about who does the work afterwards. The three realistic destinations differ far less in what the database can do than in who patches it, who restores it at two in the morning, and who is accountable when a query that ran in a second starts taking thirty. This guide walks through the migration in the order the work actually happens: choose the destination, assess, fix, size, rehearse, cut over, and then run it properly.

Step 1: Choose the destination

Almost every SQL Server estate ends up in one of three places. The names matter less than the division of labour each one creates.

Azure SQL Managed Instance. The platform-as-a-service option built for compatibility with the SQL Server engine. Microsoft patches the instance and takes automated backups. You stop operating servers and start operating databases. Most instance-level features survive the move.
SQL Server on an Azure virtual machine. Infrastructure-as-a-service. You keep the full instance and every feature you have today, and you also keep responsibility for the operating system, for SQL Server patching, and for backups unless you configure something to take them.
Stay where you are. Entirely legitimate. If the estate is stable, the hardware has life left and nobody is asking for elasticity, moving it achieves very little beyond changing the invoice.

There is a fourth option people reach for too early. Azure SQL Database is the single-database service, and it is excellent for applications designed around it. It is not a drop-in destination for an existing instance, because instance-scoped behaviour such as SQL Server Agent jobs and cross-database queries does not carry across unchanged. If an application assumes an instance, plan for Managed Instance or a virtual machine and treat Azure SQL Database as a redesign rather than a migration.

Step 2: Inventory the estate and assess compatibility

Before choosing tools, list every instance and database with its version, edition, compatibility level, size, growth rate and the applications that depend on it. Then run a compatibility assessment against the destination you are leaning towards. Azure Migrate includes SQL Server discovery and assessment, and Microsoft's migration tooling reports breaking changes, deprecated features and behaviour differences per database. The assessment is also where you find the features that decide the destination:

Instance-level features in use: SQL Server Agent jobs, linked servers, cross-database queries, CLR assemblies, Service Broker, FILESTREAM, Polybase, replication publications.
Operating system dependencies: file shares, xp_cmdshell, third-party agents, certificates and Windows logins that assume a domain.
Application vendor certification: a vendor who supports only a specific SQL Server version on a machine you control removes most of the choice.
Compatibility levels: databases still running at old compatibility levels will change plan behaviour when they move, and that needs testing rather than hope.
Recovery requirements: how long the business could be without each database, and how much data it could lose. Write both numbers down before looking at any service tier.

The feature inventory decides Managed Instance versus a virtual machine more than anything else. Do it before the business case, not after.

Step 3: Fix what the assessment finds

Every assessment produces a list. Work through it on the current platform where you can, because a change tested in the environment you already understand is cheaper than the same change discovered during cutover. Typical items: replacing deprecated data types and syntax, rewriting jobs that shell out to the operating system, moving file-based integrations to Azure storage or an integration service, and converting Windows-authenticated logins to a directory the target can use. Anything you cannot fix becomes a constraint on the destination or a reason to stay on a virtual machine.

Step 4: Size and cost the target

Size from measured usage, not from the current server's specification. Capture CPU, memory, storage throughput and peak concurrency over a representative period that includes month-end, then map that to a service tier or virtual machine size with headroom. Three decisions carry most of the cost:

Region. Pick the Azure region closest to the application, for example South Africa North, East US or West Europe. Putting the database in a distant region to save a little money is a decision you feel on every round trip between the application and the database.
Licensing. Azure Hybrid Benefit lets eligible existing licences with Software Assurance be applied to Azure. Terms change, so confirm the current position with your licensing partner rather than assuming.
Commitment. Reserved capacity lowers the hourly rate in exchange for a term. Commit once the workload has settled on the new platform, not before.

Step 5: Build the target and migrate a copy first

Stand up the destination and load a recent copy of production before anyone talks about a cutover date. Run the real application against it. Compare query performance to the baseline you captured on the source; the Query Store is the easiest place to hold that baseline for SQL Server 2016 and later. Plans change between versions and platforms, and a handful of queries always need attention afterwards. Finding them now, with no users waiting, is the whole point of the rehearsal.

Two things are worth insisting on. First, restore-test the new environment before cutover, not after: an automated backup you have never restored is a setting, not a recovery plan. Second, test the failure paths on the target, including a failover if you have configured one, because high availability that has only ever been configured is a hypothesis.

Step 6: Choose the cutover method

How you move the data is dictated by how long the business can pause writes.

Backup and restore. Back up to Azure Blob Storage with BACKUP TO URL and restore on the target; Managed Instance restores native backups from URL directly. Simple and reliable, with downtime equal to the backup, copy and restore time. Right for most small and medium databases and for any window you can afford.
Log shipping or a distributed availability group to a virtual machine. Keep the target in step with the source for days or weeks, then cut over in minutes. The standard low-downtime path when the destination is a VM.
Azure Database Migration Service. Microsoft's managed service for offline and online migrations to Managed Instance and Azure SQL Database, keeping the target synchronised until you choose to switch.
Transactional replication. Useful when only part of an instance moves or when the source must stay live for a long overlap, at the cost of more setup and monitoring.

Step 7: Cut over and validate

Agree the window and, more importantly, the rollback plan with application owners before the night. On the night: stop writes on the source, take the final synchronisation, confirm row counts and checksums on the tables that matter, repoint connection strings or DNS, run the application smoke tests the business signed off, and only then release users. Keep the old instance available and unmodified for long enough to fall back to it. Migrations that go wrong rarely go wrong on the night; they go wrong at month-end two weeks later, and the fallback has to still be there.

After the move: what changes, and what does not

The most common disappointment after a cloud move is discovering which problems came along for the ride. Moving to a managed service removes server administration. It does not remove database judgement.

Handled for you on a managed service: operating system patching, SQL Server patching, hardware failure, and automated backups with point-in-time restore.
Still yours, everywhere: schema and index design, query performance, statistics, capacity planning, security model, and knowing whether the recovery point you are configured for is the one the business actually needs.
New and often underestimated: network design and latency between the application and the database, cost control, and the fact that a slow query now has a monthly price attached to it.

A badly indexed query does not get faster in Azure. It gets more expensive, because you are now paying by the hour for the compute it wastes.

If you are moving because 2016 or 2017 is out of support

This is the most common trigger we see. SQL Server 2016 left Microsoft's extended support in July 2026 and SQL Server 2017 follows in October 2027. It is worth separating two decisions that often get merged. Getting off an unsupported version is urgent. Changing your hosting model is not. You can upgrade in place, on hardware you already own, and treat the cloud question as a separate piece of work with its own business case. Merging them doubles the risk of a project that was already overdue. Our note on SQL Server 2016 leaving extended support ranks the options for that decision on its own terms.

How RadixTrie helps

RadixTrie is a database specialist with senior engineers across Microsoft SQL Server, Oracle and PostgreSQL, based in South Africa and working with organisations in the US, UK, Europe and beyond through our remote DBA services. We run the assessment, the rehearsals and the cutover described above, and then keep the estate healthy afterwards under managed DBA services. The model is direct access to senior database experts, with no service desk and no escalation loops. Our SQL Server support services page describes the operating model that applies wherever the instance ends up running, and our note on what good SQL Server support looks like explains how to judge it.

Weighing up a move to Azure? Let's work through the options for your estate.

Need a hand with this?

Tell us what you run today and when it has to move. A senior database DBA will reply directly, usually within one working day. Prefer email or phone? Write to expert@radixtrie.com or call +27 10 143 0304, or use the contact page to book a 30-minute call.

TAGSSQL ServerAzureMigrationManaged DBASouth Africa