The fourth option is the one nobody asks about, because it does not look like a migration and migrations are what get funded. SQL Server enabled by Azure Arc leaves the server exactly where it is and moves the paperwork to Azure: an inventory that maintains itself, a licensing posture that becomes queryable metadata, extended security updates bought by the hour without a purchasing negotiation, and a free assessment that keeps telling you what the right Azure target would be. For a large number of estates it is the correct thing to do this year, precisely because it is not a decision about where the database ends up.
What this is, in one paragraph
Azure Arc projects a server that Azure does not host into Azure Resource Manager, and the Azure Arc series covers that machinery in full, including what installing the agent actually grants and why the resource group holding your Arc machines is a security boundary. Everything in this article sits one layer above it. Once a machine is Arc-connected, a further component called the Azure extension for SQL Server detects the SQL Server instances on it and projects each one as its own Azure resource. From that point the instance has a resource identity, appears in inventory, can be queried at scale, and can be given a licensing posture. If you have not onboarded servers to Arc yet, start with the onboarding article; this one assumes the machines are already there.
The first thing to know is that this happens whether or not you asked. Deployment of the SQL extension to Arc-connected machines running SQL Server is automatic by default. That is usually what you want, and it is occasionally not, so there is an opt-out: a tag applied at subscription, resource group, or machine scope that suppresses it. The tag’s behaviour has one detail that generates support calls, and the documentation is honest about it: changes to the tag value can take up to eight hours to take effect because the value is cached. If you set the exclusion tag and the extension appears anyway, you are almost certainly inside that window rather than looking at a fault.
Licensing posture as metadata
The most consequential property of an Arc-enabled SQL Server instance is its license type, and it is consequential in two directions at once: it decides what the instance costs, and it decides which features work at all.
There are four values. Paid means the instance is covered by licenses with Software Assurance or a subscription, and it is what automatic detection will set when Microsoft can see that entitlement. Pay-as-you-go means you are buying the license from Azure by the hour, with a recurring variant that is mandatory in the partner channel. License-only means you hold licenses without Software Assurance, and it exists to let you declare that honestly. There is one trap worth memorising because it catches experienced people: if you license by server and client access license rather than by core, you must set license-only even if you hold active Software Assurance. The documentation states that explicitly, and the intuition that Software Assurance always means Paid is simply wrong in that case.
Instances where entitlement cannot be detected can end up with no license type at all, and a fleet of those is a real and common condition. Microsoft documents a Resource Graph query for finding them, which is the right first move on any estate you have just onboarded. What Microsoft does not provide, contrary to what you might reasonably expect, is a built-in Azure Policy that sets license type; the documented way to remediate at scale is an open-source script sample. That is worth knowing before you promise a client a policy-driven solution.
The moment your licensing posture is a queryable property of every instance rather than a spreadsheet someone maintains, an audit stops being an archaeology project. That, more than any feature, is what this is for.
The pay-as-you-go meters, and why they match exactly
If you choose to buy the license from Azure, it bills hourly per operating system environment, with a four-core minimum, a partial hour counting as a full one, and a documented tolerance of thirty days of disconnection before billing behaviour changes. Standard is ten cents per core hour, which works out around seventy-three dollars per core per month. Enterprise is 37.5 cents, around two hundred and seventy-four dollars per core per month.
Those are exactly the rates Azure charges for a SQL Server license on an Azure virtual machine. Not approximately, exactly, across Standard, Enterprise and Web. That parity is not a coincidence and it is the most interesting commercial fact in this series. Microsoft has deliberately priced the license so that where the workload physically runs makes no difference to what the software costs. The consequence is that “move it to Azure to save on licensing” is not an argument any more. Whatever the case for migrating is, it is about platform capability, operational burden, and risk, and the licensing line is now flat. That clarifies a great many business cases, usually by removing a number somebody was relying on.
One caveat on the ceiling: Standard edition has a documented core cap under this model, and the newest release of SQL Server raises it. If a specific number matters to your sizing, check it against the version you are actually running rather than against the general statement.
What is free, what is gated, and what is still preview
The feature set divides along a line that is commercially deliberate, and understanding which side something sits on will save you an argument later.
Free, regardless of license type: inventory of every instance and database, the migration readiness assessment and the portal database migration experience built on it, Entra authentication for recent versions of SQL Server, Defender for SQL integration, Purview data map scanning, an availability group dashboard, failover cluster inventory, and the least-privilege configuration. That is a genuinely useful set to get for nothing, and it is why I recommend Arc-enabling estates that have made no decision at all about their future.
Gated behind Paid or pay-as-you-go: extended security updates, the best practices assessment, automated backups and point-in-time restore, automatic updates, the monitoring and performance dashboards, new-version upgrade rights, and unlimited virtualization. The pattern is the same one the Arc series describes for Windows Server, and it is coherent: the instances you are already paying to license properly are the ones that get managed at no additional cost.
Now the honest part, and the reason I called this a bridge rather than a destination. Several of the operational features are still preview, including the automated backups and point-in-time restore, and the monitoring dashboards. The monitoring documentation says in as many words that fees for the feature after general availability are to be determined, which is an unusually candid way of telling you not to build a cost model on it. Automatic updates are narrower than the name suggests: they cover important and critical updates only, and the documentation is explicit that you must still manually install other updates such as service packs and cumulative updates. If you were hoping Arc would take over cumulative update management for your SQL estate, it does not.
There are platform boundaries too. Instances must be SQL Server 2012 or later and 64-bit. Windows is the first-class host and the Linux extension carries real gaps. Windows Server 2012 R2 lacks the telemetry endpoint the dashboards and assessment depend on, so those simply do not work there, which is unfortunate given how much of the estate that needs this most is running exactly that. And there is a maintenance obligation on the management plane itself that catches people: only extension versions released within the last year are supported. The thing managing your patching needs patching.
The assessment is the reason to do this
If I had to justify Arc-enabling a SQL estate on one feature, it would be the migration assessment, and it is free at every license type. It runs automatically on a weekly cadence rather than waiting to be invoked. It reads up to thirty days of performance history and sizes at the ninety-fifth percentile, which is the difference between a target recommendation you can defend and a number somebody guessed. It reports migration readiness per database, and it carries toggles for hybrid benefit and reserved or savings-plan pricing so the estimate reflects your actual commercial position.
Two caveats keep it useful rather than oversold. It is Windows-only, does not cover failover cluster instances, and needs a host newer than Windows Server 2012 R2. And its price estimates are calculated on a fixed basis: one currency, one region, a fixed monthly hour count. Use it to compare options against each other, which it does very well, and do not paste its dollar figures into a budget without redoing them for your region and agreement.
What makes this compelling is the cadence rather than the output. A consultant’s assessment is true on the day it is written and decays from then on. This one refreshes every week, for free, forever, and it feeds the portal migration experience directly, so the assessment and the execution are the same surface rather than two disconnected projects. An estate that is Arc-enabled today has a continuously current migration plan whether or not anyone is working on one.
Extended security updates without the ceremony
The other genuinely strong reason, and it is timely. Extended security updates for SQL Server can be subscribed through Arc, billed hourly, and cancelled when the instance is decommissioned or migrated, without a volume licensing conversation. The Arc series covers the licensing mechanics for Windows Server and the same shape applies here.
Two things make this urgent rather than theoretical. SQL Server 2016 left extended support in July 2026 and its updates began billing immediately afterwards, and the old route of moving the workload onto an Azure virtual machine no longer earns them for free. And there is a backbilling behaviour that surprises people: subscribing late bills back to the start of the term, so waiting does not save money, it merely defers a larger invoice. If a 2016 instance is going to keep running into next year, the decision to subscribe is better made now than in six months, and the arithmetic is in the licensing article that follows this one.
Arc is a bridge with a good toll system. It is not somewhere to live, and the features that would make it somewhere to live are the ones still wearing preview labels.
An unadvertised effect on your security bill
One detail that almost nobody mentions and that occasionally pays for the whole exercise. Defender for SQL prices servers outside Azure that are not Arc-enabled on a per-vCore basis, and prices SQL Server on Azure virtual machines and Arc-enabled servers per instance. Onboarding a server to Arc therefore moves it from one billing unit to another. Depending on how many cores those machines have, that can be a material change in the direction you would want. It is worth modelling before you present Arc as a pure cost addition, because for core-heavy servers already covered by Defender it may not be one.
Who should do this, and when
Arc-enable the SQL estate if you have servers that are not moving this year, if you have any version at or before 2016 still in production, if you cannot currently produce an accurate list of your SQL Server instances and their editions, or if you are going to be asked to defend your licensing position to anyone. In every one of those cases the free tier alone justifies it, and the assessment turns an unplanned estate into a planned one without committing to anything.
Do not Arc-enable expecting it to replace your operational tooling. The backups are preview, the monitoring is preview with undetermined future pricing, and the automatic updates deliberately exclude the updates you most want automated. Treat those as previews you evaluate, not as a platform you migrate onto. The build sheet that follows deploys the extension, sets license type deliberately across a mixed estate, turns on the assessment and reads its output properly, subscribes extended security updates without triggering the backbilling surprise, and validates the whole thing with Resource Graph queries you can run against your own tenant.
Azure SQL
‹ Previous: [SQL 4.1] Build Sheet: Migrating to a SQL Server Azure VM
Next: [SQL 5.1] Build Sheet: Arc-Enabling the SQL Estate ›
