SQL Server to Azure Migration

The target decision nobody leads with

Microsoft documents the three targets thoroughly, but the guidance is scattered across product pages and every commercial migration provider skips straight to their delivery methodology. The awkward truth is that the target decision drives everything downstream: licensing, cost, downtime, feature compatibility, and how much administration you still own afterwards. Getting it wrong per workload is how organisations end up paying Managed Instance prices for databases that would have run happily in a £300-a-month elastic pool, or discovering post-migration that a cross-database dependency does not work on the target they chose.

Which Azure target fits which workload

Target	Best for	Watch for
SQL Server on Azure VM	Lift-and-shift, full instance features, SSRS or SSAS on the box, third-party software with strict version requirements	You still own patching, backups and HA; the cloud bill without the cloud benefit if it becomes the default
Azure SQL Managed Instance	Instance-scoped estates: cross-database queries, SQL Agent, CLR, linked servers, minimal application change	Cost at small scale; sizing and reserved capacity decisions carry real money
Azure SQL Database	Single databases, new development, variable workloads suited to elastic pools and serverless	No instance-level features; agent jobs and cross-database logic need redesign
Microsoft Fabric	The analytical estate: warehouses, data marts, reporting databases	Not an OLTP target; covered fully on the Fabric migration page

That fourth row is the one no competitor prints. Treating Azure as the only destination sends the analytical estate to an expensive transactional target by default. One assessment across both destinations avoids paying twice.

The end-of-support clock and the ESU trap

SQL Server 2014 left extended support in July 2024, and SQL Server 2016 followed on 14 July 2026, this month; anything on those versions is unpatched today unless you are paying for Extended Security Updates. 2017 ends in October 2027 and 2019 in January 2030, both inside a sensible planning horizon. The default response, buying ESUs, is a trap with a ratchet: ESU pricing escalates each year, and it buys security patches only, not features, not performance, not support. Running end-of-support SQL Server on an Azure VM does earn free ESUs, which is occasionally the right bridge, and Azure Hybrid Benefit lets existing licences with Software Assurance offset a substantial share of the Azure cost. The assessment models both against your actual licensing position rather than quoting list prices.

What the assessment actually delivers

The output is a working document your team can execute, not a proposal for more of us. It contains the full estate inventory with owners, consumers and last meaningful use per database; the target map assigning every workload to VM, Managed Instance, SQL Database, Fabric, stay or retire, with the reasoning written down; and the dependency register covering what breaks migrations in practice: linked servers, cross-database queries, agent job chains, applications with hard-coded connection strings, and the vendor system whose support contract specifies a SQL Server version.

The commercial half models the Azure running cost per workload at the recommended size, applies Azure Hybrid Benefit against your actual licensing position, prices reserved capacity where the workload profile justifies it, and states the ESU cost of delay per end-of-support instance. The plan closes with wave sequencing, effort estimates and the delivery cost at the published day rate, so the whole exercise converts into a budget paper without another engagement. The document is portable by design: deliver it in-house, with us, or with anyone else, and it reads the same.

Costing the move honestly

Azure migration business cases fail in predictable ways, usually because the comparison is dishonest in one direction or the other. The pro-cloud version compares Azure list price against hardware depreciation and forgets the licences, the backup storage, the outbound bandwidth and the engineer time that does not disappear. The anti-cloud version prices the on-premises estate as free because the servers are paid for, ignoring the refresh cycle two years out, the ESU bill climbing annually, and the cost of the weekend the SAN fails.

The assessment prices both sides with the assumptions stated: right-sized targets rather than like-for-like sizing, Hybrid Benefit applied where you actually hold Software Assurance, reserved pricing only where workloads run steadily enough to earn it, and the do-nothing scenario costed properly including ESUs and refresh. Sometimes the honest answer is that a workload should stay on-premises until its natural refresh point. A plan that admits that is a plan you can trust on the workloads it says should move.

How the migration runs

Assess

Estate inventory, real usage capture, compatibility analysis per target, and the workload map: VM, Managed Instance, SQL Database, Fabric, stay or retire. Costed, sequenced, and written to be delivered by any competent team, including your own.

Prove

One representative workload migrates end to end first, surfacing the estate-specific issues (collation conflicts, orphaned logins, the linked server nobody admitted to) while they are cheap. The proof run also validates the downtime approach: for most estates that means log shipping or the Azure migration tooling, with near-zero-downtime cutover reserved for the workloads that genuinely justify it.

Migrate

Waves ordered by risk and dependency, delivered alongside your team at the published day rate. End-of-support workloads go first. Each wave ends with the workload monitored, right-sized against real consumption, and handed over, not parked on a retainer.

Operate

Post-migration review at 30 days: performance against baseline, cost against model, and the tuning that only shows up under production load. Ongoing cover, where wanted, is the fractional DBA service, which is optional by design.

Why not a managed service provider

Most UK Azure migration providers are managed service businesses, and the migration is structured as the front door to a support contract. That shapes the advice: targets that maximise the ongoing management surface, handovers that keep the knowledge on their side, and a commercial incentive against ever making your team self-sufficient. This practice is built the other way. A named Microsoft Data Platform MVP and Microsoft Certified Trainer does the work, your team is trained to keep the capability, and support afterwards is available but never structural. The measure of success is that you do not need us in six months.

Frequently asked questions