Architecture

Moving SQL Server to Azure: Managed Instance, VM, or Stay Put

Three realistic destinations for a SQL Server estate, what each actually changes about who does the work, and the questions that decide which one fits. Written for South African organisations weighing the move.

By RadixTrie5 September 20263 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 article sets out the three options, what each genuinely changes, and the questions that decide which one fits.

The three destinations

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.
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.

What actually 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.

The questions that decide it

Rather than starting from the destination, start from these. The answers usually make the choice obvious.

How long could the business be without this database, and how much data could it afford to lose? Write both numbers down before looking at any service tier.
Which instance-level features are actually in use? Agent jobs, linked servers, cross-database queries, CLR, Service Broker, FILESTREAM. This inventory decides Managed Instance versus a virtual machine more than anything else.
Has the application vendor certified a target? A vendor who supports only a specific SQL Server version on a machine you control removes most of the choice.
Where do the users and the application sit? Azure has South Africa North and South Africa West regions, and putting the database in a distant region to save a little money is a decision you feel on every round trip.
What is the licensing position, and does Software Assurance apply? Azure Hybrid Benefit lets eligible existing licences be applied to Azure. Terms change, so confirm the current position rather than assuming.
Who will run it afterwards? If the answer is nobody in particular, a managed service buys you patching, not accountability.

How a migration actually goes

The technical work is well understood. The risk sits almost entirely in the preparation. A compatibility assessment of every database and the application code that touches it. A test environment on the target with production-like data. A query performance comparison, because plans change and a handful of queries always need attention afterwards. Agreement with application owners on the cutover window and, more importantly, on the rollback plan. Then a rehearsed migration that leaves the original instance intact and running until the new one has proven itself.

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, 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.

If you are moving because 2016 went out of support

This is the most common trigger we see, and 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 South African database specialist with senior engineers across Microsoft SQL Server, Oracle, PostgreSQL and MySQL/MariaDB, with offices in Randpark Ridge and Stellenbosch. We plan and run upgrades, platform migrations and cloud moves, 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. You can read more on our services page, and our note on what good SQL Server support looks like describes the operating model that applies wherever the instance ends up running.

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

TAGSSQL ServerAzureMigrationManaged DBASouth Africa