On-Prem SQL Server to Azure/Cloud: A Migration Playbook

By Clayton Severson, Principal Consultant · Published August 18, 2026

Pick the target before the tool. Azure SQL Managed Instance is the default for lifting an existing application, and the Managed Instance link is the lowest-downtime path into it. Then plan for what no migration tool carries: logins, SQL Agent jobs, and server-level objects.

SQL Server migrations fail in a predictable way. The data moves fine. What breaks is everything around the data — the Agent job that feeds a nightly report, the linked server nobody documented, the login whose SID no longer matches its database user, the application connection string with a hard-coded instance name. The database was never the hard part.

There is also a 2026-specific trap: most of the migration walkthroughs currently on the internet tell you to download tools that Microsoft has retired. Start there, because it will save you an afternoon.

The tooling in most tutorials no longer exists

Microsoft consolidated its SQL migration tooling and retired the previous generation across 2025 and 2026. If a guide opens with "first, install the Data Migration Assistant," it is out of date.

Tool	Status	What to use instead
Data Migration Assistant (DMA)	Retired July 16, 2025 — no longer downloadable	Azure Arc-enabled SQL Server migration assessment
Azure SQL Migration extension for Azure Data Studio	Retired February 28, 2026	Azure Database Migration Service in the Azure portal
Azure Database Migration Service (classic), SQL scenarios	Retired March 15, 2026	Current Azure DMS via portal, PowerShell, or Azure CLI
SQL Server Management Studio	Current — and the tool for the Managed Instance link	Use the latest SSMS; it has the link wizards

The practical consequence is that assessment and migration are now separate tools rather than one wizard. Assessment moved to the Azure Arc-enabled SQL Server path; execution lives in Azure DMS or, for the lowest-downtime route, in SSMS driving the Managed Instance link.

Which Azure target should you choose?

This decision determines everything downstream — tooling, timeline, and how much application rework you sign up for. Choose it before anyone opens a migration wizard.

Target	Choose when	Main constraint
Azure SQL Managed Instance	Lifting an existing application with instance-level dependencies — SQL Agent, cross-database queries, service broker	Not 100% surface-compatible; some features still differ from boxed SQL Server
Azure SQL Database	New builds, or single-database applications you are willing to adapt	No SQL Agent, no cross-database queries, most instance-level features absent
SQL Server on an Azure VM	You need OS access, an unsupported feature, or third-party software on the host	You still patch, back up, and manage it. This is rehosting, not modernizing

The honest default for most on-prem estates is Managed Instance. It exists precisely to absorb applications written against a real SQL Server instance, and it is the only one of the three that will not force you to rewrite the parts of your system that were never really "the database." Reserve the VM for genuine blockers, and treat Azure SQL Database as the target you migrate to later, after the application has been modernized — not as the destination of a lift-and-shift.

What does Azure Database Migration Service actually do?

Less than the name suggests, and Microsoft is refreshingly direct about it. Their own feature comparison for the portal-based service lists these as not supported:

• Assessment — it will not tell you whether your source is compatible. That is a separate exercise.
• SKU recommendation — it will not size the target for you.
• Migrate logins — logins are your problem. This one bites hardest.
• TDE support — databases encrypted with Transparent Data Encryption are not handled by the service.

What it does do is migrate schemas and data, online or offline, to Managed Instance and to SQL Server on Azure VMs, and offline to Azure SQL Database — with private endpoint support and PowerShell and Azure CLI automation. That is genuinely useful. It is just not a migration program, and planning as though it were is how the "we'll use the Microsoft tool" estimate turns out to be a third of the real work.

How do you migrate with minimal downtime?

For Managed Instance targets, the answer is the Managed Instance link, and it is a materially different mechanism from a backup-and-restore migration.

Because it is continuous replication, the shape of the project changes. You establish the link weeks before cutover, let it seed and stay current, run your validation against a live target, and take the outage only for the failover itself. Compared to "restore a 4 TB backup during a maintenance window and pray," it removes the part of the plan that was always the risk.

The link is also not only a migration tool. Microsoft positions it for disaster recovery, offloading read-only workloads to Azure, and using Azure services against on-prem data without migrating at all — and you can run it for months or years. That makes it a reasonable first step even for organizations that have not decided to migrate: establish the link, get a warm replica in Azure, decide later.

The Managed Instance link has a version cliff

This is the single most important compatibility fact in the article, and it is binary.

SQL Server version	What the link supports	Consequence
2022 and 2025	Two-way replication, failover and failback	Full flexibility; you can migrate and come back
2016, 2017, 2019	One-way replication to Managed Instance only	Failing over breaks the link; failback is not supported
2014 and earlier	Not supported at all	Distributed availability groups did not exist before 2016

Read the middle row carefully, because it is where migrations get uncomfortable. On SQL Server 2016 through 2019, the link is a one-way door. You can fail over to Azure, but the link breaks when you do and there is no supported path back through it — recovery to SQL Server means transactional replication or a bacpac export. If your rollback plan for cutover weekend was "fail back if it goes badly," that plan does not exist on those versions. Either upgrade the source to 2022 first, or accept that cutover is one-directional and build your rollback out of a pre-cutover backup instead.

A few other prerequisites that catch people: the link requires network connectivity via VPN or ExpressRoute and can only be established to the VNet-local endpoint — public and private endpoints will not work. Authentication is certificate-based only; Windows authentication cannot establish the link. It is one database per link, up to 100 links on General Purpose and Business Critical instances. And you cannot combine it with failover groups on the same instance.

What no migration tool brings across

Here is the list that turns a smooth technical migration into a bad Monday. The Managed Instance link replicates user databases. It does not replicate:

• System databases — master, msdb, and everything living in them
• SQL Agent jobs — every scheduled job, every step, every schedule
• Server-level objects — linked servers, server triggers, credentials, audit specifications
• Logins — and Azure DMS does not migrate them either

None of that is a defect; it is inherent to replicating databases rather than instances. But it means a parallel workstream exists whether you planned one or not: script every login with its SID so database users still map, script every Agent job, inventory every linked server and decide what replaces it, and re-point every credential. Do this early and it is a tedious afternoon. Do it during cutover and it is the reason the rollback gets called.

What else commonly breaks?

Assessment findings cluster into a short list, and most of them influence target choice rather than being fixed after the fact — which is why assessment belongs at the start, not the middle.

• Linked servers and distributed transactions. Managed Instance supports distributed transactions only between managed instances, not back to your SQL Server. If your application relies on DTC spanning the boundary, that architecture does not survive the move.
• TDE. Neither the DMS path nor the link handles it transparently. With the link, you must export the database encryption key from SQL Server into Azure Key Vault and configure BYOK TDE on the managed instance before creating the link.
• FILESTREAM and FileTable. Unsupported on Managed Instance, so those databases cannot replicate through the link at all. This is a target-choice determinant.
• In-Memory OLTP. Replicates only to the Business Critical tier — General Purpose does not support it.
• Multiple log files. Managed Instance supports one, so a database with several cannot be replicated until it is consolidated.
• Collation and hard-coded names. The quiet ones. A collation mismatch produces subtly wrong sort orders and comparison results rather than errors, and hard-coded server or instance names in stored procedures and application config surface only under real traffic.

How do you validate before cutover?

With a parallel run, and with checks that compare results rather than structure. Schema equivalence proves nothing about whether the application still returns the same numbers.

1. Row counts and checksums per table between source and target, run repeatedly as replication catches up — not once.
2. Replay real queries. Take your slowest and most business-critical queries from production, run them against both, and compare results, durations, and execution plans. Cloud storage and CPU characteristics differ from your on-prem hardware; a query that was fine can regress.
3. Reconcile a full business day. Run a complete close on both systems and compare the outputs the business actually looks at. This catches collation and rounding issues that row counts never will.
4. Test the failover itself, in a rehearsal, with the clock running. Knowing the cutover takes eleven minutes is worth more than believing it takes "a few."
5. Verify the parallel workstream — logins mapped, Agent jobs present and scheduled, linked servers replaced, connection strings updated.

This is the same discipline that applies to any platform migration; the pattern of parallel-run validation and staged cutover is covered from the warehouse side in the Teradata to Databricks migration article, where the tooling differs and the failure modes rhyme.

Frequently asked questions