If you search for how to migrate SQL Server to Azure, almost everything you find is wrong. Not subtly wrong, not out of date in the way documentation always is, but wrong in the sense that it tells you to install software that no longer exists. Four of the tools at the centre of every migration guide written between 2022 and 2024 have been retired, three of them inside the last eighteen months. This article is what replaced them, how to pick a destination on evidence rather than preference, and the one piece of cutover discipline that decides whether the database performs the same on the other side.
The toolchain collapsed, and nobody updated the internet
Start with the obituaries, because they are the reason this article exists. The Data Migration Assistant, the tool that every assessment guide opens with, was retired on 16 July 2025. Azure Data Studio, the client that hosted the Azure SQL Migration extension, was retired on 28 February 2026, and the extension went with it on the same date. The classic Database Migration Service retired its SQL scenarios on 15 March 2026. The Database Experimentation Assistant, the workload replay tool people reached for when they wanted evidence rather than opinion about a version change, went in December 2024, and its retirement notice suggests an open-source project as the way forward rather than a first-party successor.
Read that list again as a consultant rather than as a reader. The assessment tool, the client, the extension, and the execution service were four links of one chain, and all four broke within about twenty months. Anything written before mid-2025 describes a workflow that cannot be performed today, and that includes a great deal of material that still ranks well and still reads authoritatively. I have watched a competent team lose most of a week to this, downloading a retired installer, working around its refusal to run, and only then discovering that the thing they were being taught to do had no landing place at the far end.
When the tooling for a migration changes faster than the guidance about it, the first deliverable is not a plan. It is an accurate inventory of what still exists.
It gets one layer more awkward, and it is worth knowing before you go looking. Microsoft’s own current documentation has not fully caught up with Microsoft’s own current products. There are live pages carrying a 2026 revision date that still describe version support ranges retired products were built around, and at least one preparation page still wearing a preview banner for a capability that has since gone generally available. The release notes are more current than the conceptual pages. That is a normal condition for a platform moving this fast, and the practical rule it produces is simple: when two Microsoft pages disagree, believe the more recently revised one, and believe a release-notes entry over a conceptual overview.
What assessment looks like now
Three surfaces do assessment today, and they are genuinely different products for genuinely different situations, which is why picking one is an architectural decision rather than a matter of taste.
SQL Server Management Studio is the flagship client and the successor to the Data Migration Assistant’s role, but there is a version trap that will waste an afternoon if you do not know it. The Migrate SQL Server experience arrived in SSMS 22.5.0, in April 2026. SSMS 21 does not have it at all, and its documentation says so plainly. Nor do the earlier SSMS 22 builds. If someone tells you they have SSMS 22 and cannot find the migration option, that is the reason, and the fix is an upgrade rather than a support case. There is a second nuance in that tool worth carrying: when it recommends a target size for an instance that is not Arc-enabled, it is reasoning from metadata rather than from observed performance. A recommendation built from metadata is a starting point for a conversation, not a sizing decision.
The Arc migration assessment is the one I reach for on any estate I expect to spend more than a fortnight thinking about. It has been generally available since June 2025, it is free across every license type, and it refreshes itself weekly without anyone remembering to run it. It reads up to thirty days of performance history and sizes at the ninety-fifth percentile, which is the difference between a recommendation you can defend in a budget meeting and a guess. It carries toggles for hybrid benefit and for reserved or savings-plan pricing, so the estimate it produces reflects the commercial posture you actually have rather than list price. One honest caveat to keep in your head and out of your client’s spreadsheet: its price estimates are computed against a fixed basis, in United States dollars, at a fixed region and a fixed monthly hour count. It is excellent for comparing options against each other and poor as an absolute budget figure. Standing this up is the subject of its own build sheet, and it is the strongest argument in this series for Arc-enabling an estate you have not decided the future of yet.
Azure Migrate is the third surface, agentless and estate-wide, and the right choice when SQL is one workload among many in a datacentre exit rather than the point of the exercise. It has one default I would call a trap: unless you change it, it will size from a very short window of performance history. Right-sizing a production database from a day of observation is how you end up with a target that survives the demonstration and falls over at month end. Widen the window before you trust the output.
The portal experience, and what is actually underneath it
The newest surface, and the one with almost no community coverage, is the migration experience that lives in the Azure portal on the Arc-enabled SQL Server resource itself. Its name matters, because the name tells you where to find it: this is SQL Server migration enabled by Azure Arc, reached from the SQL Server resource blade rather than from a migration project. The Managed Instance target went generally available in October 2025 and the SQL Server on Azure VM target in June 2026, publicly announced a few weeks ago as I write this. It walks discovery, assessment, planning, and migration as one flow in one place, which is a real improvement over assembling four tools yourself.
Know what is running underneath it, because that is what determines the behaviour you will have to explain when something stalls. For the virtual machine target, the Database Migration Service is doing the work. For the Managed Instance target, it is not: that path uses the Managed Instance link or the Log Replay Service. The portal is a coherent front end over mechanisms that remain distinct, and their limits are still theirs. This matters the first time a migration behaves in a way the portal does not explain, because the answer is in the documentation for the underlying mechanism, not for the portal.
The Database Migration Service in its current form deserves one paragraph of plain speech, because a single line in its capability matrix shapes this entire series. It runs online or offline migrations to Managed Instance and to a SQL Server virtual machine. To Azure SQL Database it runs offline only. There is no online path into the database-scoped service, and no amount of planning produces one. It also does not assess, does not recommend a size, does not migrate logins, and does not handle databases encrypted with transparent data encryption. It is an execution engine, not a migration programme, and treating it as the latter is how projects discover in week six that nobody owns the logins.
Choosing the target on evidence
The destination is decided by two questions, and preference is not one of them. The first is what the database depends on outside itself. If it uses Agent jobs, cross-database queries, linked servers, the common language runtime, Service Broker, or Windows authentication, then Azure SQL Database is not a lift target and pretending otherwise converts a migration into a redevelopment project with a migration’s budget. Those dependencies point at Managed Instance, which exists precisely to preserve instance semantics, or at a virtual machine when something genuinely requires the whole product. Reporting Services, Analysis Services, an unusual feature, or a vendor who certifies against a specific build all point at the virtual machine, and there is no shame in that answer.
The second question is how much downtime the business will actually tolerate, asked properly rather than answered reflexively with zero. Near-zero cutover into Managed Instance means the Managed Instance link, and the link has a version floor: SQL Server 2016 with Service Pack 3 and the Azure Connect feature pack at the earliest, with specific cumulative update floors above that for later versions and for the two-way behaviour. It is also the only genuinely online path into the Business Critical tier. Near-zero cutover onto a virtual machine means a distributed availability group, which needs SQL Server 2017 or later for a standalone source and Enterprise edition at both ends. If the source is older than those floors, and a surprising amount of the estate that most needs to move is, then the honest answer is a controlled outage: a native restore, the Log Replay Service with its thirty-day job window, or an offline run of the migration service. Say that early. An outage agreed in week one is a maintenance window, and the same outage discovered in week nine is an incident.
The estate does not tell you where it wants to go. It tells you where it can go, and the difference between those two sentences is the whole of migration planning.
Everything that is not the database
A backup file carries the database. It does not carry the instance, and the instance is where migrations go wrong. Logins live at the server, and moving them means scripting them and repairing the orphaned security identifiers on the other side; Windows logins do not survive the trip to Azure SQL Database at all and must be re-founded on Entra identities. Agent jobs move to the Agent on a Managed Instance or a virtual machine and must be rebuilt as elastic jobs on Azure SQL Database. Server-level triggers, credentials, and deliberate instance configuration are all yours to carry. If the database is encrypted, the certificate has to arrive before the data does, and that ordering is not negotiable.
Two adjacent products need a decision rather than an assumption. Integration Services packages redeploy onto the Azure-SSIS integration runtime in Data Factory, which remains a supported and undeprecated destination, so that is a rehost rather than a rewrite. Reporting Services is a different conversation, and it is the one people avoid. There will be no Reporting Services in SQL Server 2025. The existing 2022 server is supported into January 2033, so there is no emergency, but there is a direction, and the direction is Power BI Report Server, whose report definitions are compatible with what you already have. Plan the report estate deliberately during the database migration, because that is the only time anyone will fund looking at it.
Cut over at the old compatibility level
Here is the discipline that separates a migration that lands from one that gets rolled back, and it rests on a piece of engine behaviour worth understanding precisely. When a database moves to a newer version, its internal version is upgraded and that upgrade is irreversible. Its compatibility level, however, is preserved. A database that has been running at compatibility level 110 since 2012 arrives on a 2022 or 2025 target still at 110 and stays there until somebody deliberately changes it. That is not an oversight. It is the safety mechanism, and it is the most useful property the platform gives you during a migration.
Use it. Cut over at the old level, so that the only variable you have changed is the platform. Let the workload run and capture a real baseline in Query Store. Then raise the compatibility level as a separate, scheduled, individually reversible change, and deal with what moves. The cardinality estimator is where the trouble usually lives: query plans that were stable for a decade get re-costed, and a handful get materially worse. Because you have a before and an after in Query Store, you can see exactly which ones, and you can force the previous plan while the query is fixed properly. The Query Tuning Assistant exists to drive that loop and remains the documented tool for it.
Doing it the other way round, moving the platform and raising the compatibility level in the same window, is the single most common self-inflicted migration failure I see. When performance changes, and it always changes somewhere, nobody can say whether the cause was the hardware, the storage, the service tier, or the optimiser, because all of them moved at once. The rollback conversation starts, and it starts without evidence.
Where this goes next
That is the doctrine: assess with a tool that still exists, choose the destination from dependencies and downtime rather than from preference, move the instance and not just the database, and hold the compatibility level until you have a baseline worth comparing against. What remains is execution, and execution differs enough per destination that it belongs in its own articles. Three build sheets follow this one, one for each destination, each written to be reproducible from the text: a first Azure SQL Database with a real offline migration behind it, the lift into a Managed Instance by native restore or by link, and a SQL Server virtual machine built through the current portal experience with the manual equivalent alongside it. If the estate is not moving this year, the fourth build sheet is the one to read instead, because Arc-enabling it costs nothing and produces the assessment that makes this decision on evidence when the time comes.
Azure SQL
‹ Previous: [SQL 6] Licensing and Cost: AHB, ESUs, and Where the Money Goes
Next: [SQL 8] The Decision: Which SQL Goes Where ›
