Everything in this series has been building toward one question asked per workload: where does this database belong, and can I defend the answer to whoever signs for it. What makes that hard is not a shortage of options but the order in which people evaluate them. Cost gets asked first and settles nothing. Preference gets asked second and should not be asked at all. This article puts the four questions in the order that actually resolves a target, and then says which estates should not move this year, because that is a legitimate answer and almost nobody writes it down.
First question: what does it depend on outside itself
This one is first because it eliminates options rather than ranking them, and elimination is cheaper than comparison. Look at what the database uses that is not the database: scheduled jobs in the Agent, queries that reach across databases, linked servers, the common language runtime, Service Broker, Database Mail, Windows authentication, and anything that reads or writes the file system.
A single hit removes Azure SQL Database from consideration as a lift target, permanently and regardless of enthusiasm. It does not remove it as a re-platform target, and that distinction is the one worth holding: if somebody is willing to fund rebuilding the scheduled work as elastic jobs and re-founding authentication on Entra identities, the destination is available and often excellent. What is not available is arriving there without doing that work. Projects that skip this question do not discover the problem in the proof of concept, because a proof of concept restores one database and runs one query. They discover it in month three.
If the dependencies exist and nobody is funding a rewrite, the destination is Managed Instance, which exists precisely to let those dependencies keep being true. And if the workload needs Reporting Services, Analysis Services, a feature the managed services do not implement, or a vendor certification naming a specific build, the destination is a virtual machine and the discussion is over. That is not a consolation prize. It is the correct architecture for a real and common set of requirements.
Ask what the database depends on before you ask what anyone wants. The estate has already decided most of this; the job is to find out what it decided.
Second question: how much downtime is genuinely available
Asked properly, this question has a number in it. Asked lazily it produces the answer “none”, which is never true and which quietly forces every subsequent decision.
The reason it matters this early is that the near-zero-downtime paths have version floors, and the estate that most needs to move is usually the estate that cannot reach them. Getting into a managed instance with almost no downtime means the Managed Instance link, which needs SQL Server 2016 with the right service pack at the very oldest and specific cumulative updates above that. Getting onto a virtual machine with almost no downtime means a distributed availability group, which needs a newer source than that and Enterprise edition at both ends. Below those floors the honest options are a native restore, log replay, or an offline run of the migration service, all of which mean a maintenance window.
So the sequence matters. Establish the tolerable outage first, then check whether the source version can reach a path that fits inside it, and if it cannot, say so in week one. A four-hour outage agreed at the start of a project is a maintenance window. The same four hours discovered in week nine is an incident with a steering committee attached.
Third question: what does the licensing posture tilt toward
By this point the field is usually down to two options, and licensing decides between them more often than performance does.
If the organisation holds Enterprise licenses with active Software Assurance, hybrid benefit converts each core into four vCores of General Purpose but only one of Business Critical. That four-to-one multiplier is large enough that General Purpose becomes the default and Business Critical needs a performance case strong enough to justify surrendering it. If the organisation holds Standard, the tier choice is close to licensing-neutral and can be made on merit alone. If the organisation holds nothing with Software Assurance, then the hourly meters apply everywhere, the platform services stop being obviously more expensive than a virtual machine, and the comparison gets genuinely close.
Two asymmetries are worth carrying into the meeting. Hybrid benefit does not reach serverless or current Hyperscale at all, so an estate rich in licenses gets no credit on the tier Microsoft now recommends by default, and the comparison has to be run on total cost rather than on the assumption that owning licenses always wins. And on a virtual machine the license is the majority of the bill on Standard and several times the machine on Enterprise, with a four-core floor that makes small instances disproportionately expensive. If there is a fleet of two-core database servers anywhere in the estate, consolidating them is usually a larger saving than the entire migration produces.
Fourth question: what availability are you actually promising
This one rarely changes the destination and frequently changes the design, and it is the question most often answered dishonestly in documents I am asked to review.
On the platform services you are buying a commitment on the database. Read the current consolidated agreement rather than a remembered figure, because the numbers and their structure have both moved recently, and the retired per-service pages are not merely out of date, they are gone. The shape today is that zone-redundant deployments carry a higher commitment than single-zone ones across the tiers rather than only on the expensive one, which is the opposite of the rule of thumb many people are still carrying. Note also that the next-generation General Purpose tier on Managed Instance cannot be zone-redundant at all, so choosing it forecloses the higher figure, and that the Managed Instance commitment is conditioned on maintaining a compliant network configuration, which a well-meaning security hardening exercise can silently break.
On a virtual machine you are buying a commitment on the machine, and Microsoft states plainly that it does not cover the SQL Server process and that building a supported high availability configuration earns you no additional commitment. You can build something excellent there, and many organisations should. But you are building it, testing it, and answering for it, and a design document that prints an availability percentage next to a virtual machine architecture is making a promise the platform did not make.
Write down who is accountable when the failover is tested for real. If the answer is you, the number in the design is an aspiration, not a service level.
The estates that should not move yet
Not moving is a decision, and made deliberately it is often the right one. Four situations qualify.
The estate nobody can describe. If you cannot produce an accurate list of instances, editions, versions and dependencies, then any target selection is a guess dressed as a plan. Arc-enable it, let the free assessment run for a month, and make the decision with thirty days of real performance data behind it. This costs nothing and converts an unplanned estate into a planned one without committing to anything.
The estate whose application is being replaced in eighteen months. Migrating a database that is scheduled for retirement is work performed twice. Keep it running, keep it patched, subscribe the extended updates if it needs them, and spend the migration budget on the thing that replaces it.
The estate with a hard vendor dependency and no upgrade path. If the vendor certifies a specific build and has no plans beyond it, moving to a platform service is not available and moving to a virtual machine is a relocation rather than an improvement. Sometimes the honest recommendation is to keep it where it is, isolate it properly, and put the vendor conversation on the risk register where it belongs.
And the estate in the middle of something else. Migration competes for the same people who run the databases. An organisation already absorbing a major change usually cannot absorb this one well, and a badly-run migration is worse than a deferred one.
What none of these justify is inaction on the versions that are out of support. SQL Server 2012 cannot be patched at any price now. SQL Server 2016 left support in July 2026 and the old trick of moving it to an Azure virtual machine for free updates no longer works. Deferring migration is defensible. Deferring the decision about how an unsupported instance stays patched is not, and that decision is available independently of any migration.
The shape of a plan that survives contact
A multi-year plan for a SQL estate has three phases and the first one is much shorter than people expect.
Phase one is visibility and licensing hygiene, and it should take weeks. Arc-enable everything, resolve the instances with no license type, let the assessment build a performance history, and get the extended-update position right for anything unsupported. None of this commits you to a destination, all of it is cheap or free, and it produces the evidence every later argument depends on.
Phase two is the workloads with a clear answer. Every estate has some: the database with no instance dependencies that has wanted to be a platform database for years, the ancient box whose application is still important, the pair of servers whose licensing is obviously wrong. Do those, learn on them, and let the migration pattern get boring before you point it at anything frightening.
Phase three is the difficult remainder, and its defining characteristic is that the difficulty is rarely technical. It is a vendor who will not certify, an application nobody understands, a compliance regime that makes change expensive, a team that is already at capacity. Naming those honestly in the plan, as constraints rather than as failures, is what keeps the plan credible when it inevitably takes longer than the slide said.
Build one more thing into it: an assumption that the platform will move underneath you. In the eighteen months before I wrote this, four migration tools were retired, the recommended default tier changed, a new Managed Instance tier arrived without zone redundancy, the availability commitments were restructured, and the free-updates-in-Azure argument was withdrawn for everything from 2016 onward. Several of Microsoft’s own pages still have not caught up with several of those. A plan that assumes today’s facts hold for three years is not a plan, it is a snapshot. Re-verify the load-bearing ones each time you act on them, prefer the most recently revised source when two disagree, and keep the decisions separable enough that one of them changing does not invalidate the rest.
Where this sits
This series has a sibling. The Azure Arc capstone asks the same kind of question about servers rather than databases: what moves onto the management plane, what stays on the domain, and how you tell the difference. The two decisions are related more closely than they look, because the same estate is usually facing both, and because Arc has quietly become a prerequisite for capabilities in the newest SQL Server release rather than only a management surface for machines outside Azure.
If you take one thing from all of this, take the ordering. Dependencies eliminate. Downtime tolerance constrains. Licensing tilts. Availability shapes the design and the honesty of the document. Cost, the question everybody opens with, is the output of those four rather than an input to any of them, and a migration argued the other way round is a migration that gets rebuilt in year two.
Azure SQL
‹ Previous: [SQL 7] The Migration: Assess, Choose, Cut Over
