Microsoft licensing for cloud migration to Azure, AWS and Google Cloud. The errors that never trigger an alert.

Moving Windows Server and SQL Server to a hyperscale cloud changes the licensing arithmetic at every step, and the rules differ sharply across Azure, AWS and Google Cloud. A wrongly licensed machine runs exactly like a correct one, so the errors last.

Why do Microsoft licensing errors survive a cloud migration?

They survive because nothing breaks. A wrongly licensed virtual machine boots, runs, serves traffic and passes every health check exactly like a correctly licensed one. No alert fires, because from the platform's point of view nothing is wrong.

The only place the difference shows up is the invoice. The people who read it rarely set the license type on a virtual machine, so the error has no feedback loop and keeps accumulating. Three errors recur in migration reviews, and they point in different directions:

• A modeling error. The business case assumes Windows Server licenses can be brought to AWS on ordinary shared instances, which overstates the saving.
• An operational omission. Azure Hybrid Benefit is available and already paid for through Software Assurance, but it is not switched on.
• A design decision that aged badly. SQL Server Enterprise runs workloads that Standard would carry, so the entitlement itself costs more than it should.

All three are invisible in operation. An over specified SQL Server edition works perfectly, and the business case error surfaces only if someone reads the Product Terms instead of the slide. Licensing therefore needs a named owner and a recurring check after go live, because the business case treats it as a one time input.

Which Microsoft licensing rules apply on Azure, AWS and Google Cloud?

Two sets of rules decide almost everything: the outsourcing rules for Windows Server and License Mobility through Software Assurance for the server applications. The controlling document is the Microsoft Product Terms, read against when each license was bought and whether its Software Assurance is current.

Listed Providers and the October 2022 change

Microsoft defines four companies as Listed Providers: Amazon, Google, Alibaba and Microsoft itself. In October 2022 Microsoft introduced flexible outsourcing rights that let customers with Software Assurance or subscription licenses run their software on the shared servers of other outsourcers. Those rights do not apply to Listed Providers.

That single definition is what most cloud business cases miss. A hosting partner down the road can run your Windows Server licenses on shared hardware. AWS and Google Cloud cannot, under the same agreement.

Windows Server on AWS and Google Cloud

Windows Server licenses can go to AWS only on EC2 Dedicated Hosts. The licenses must have been bought before October 1, 2019, or added as a true up under an agreement already in force then, for a version released before that date.

On Google Cloud the dedicated equivalent is a sole tenant node. Licenses bought later have no BYOL route to either cloud, so you pay the provider's license included rate.

What License Mobility covers, and what it does not

License Mobility covers server applications, not the operating system. SQL Server, SharePoint Server, Exchange Server, Skype for Business, Project Server and BizTalk Server qualify through Software Assurance, and can run on shared instances at AWS and Google Cloud. Windows Server and Windows desktop do not qualify and follow the outsourcing rules instead.

Mobility carries an administrative step that migrations skip. Microsoft asks you to submit a License Mobility verification form within 10 days of deploying licenses with a mobility partner. The form is short, and a missing one is an easy audit finding.

Where Microsoft 365 fits

Microsoft 365 and Office 365 are SaaS subscriptions and do not change when your compute changes location. The migration questions sit with Windows Server, SQL Server and the other server applications. Seat counts for the productivity suite belong in the EA renewal discussion, where they are priced separately.

How much does Azure Hybrid Benefit save, and why is it left off?

Azure Hybrid Benefit cuts Windows Server cost by 30 to 45 percent and SQL Server Enterprise by up to 77 percent. It is the largest single saving available on Azure for Microsoft workloads. In our reviews it was switched off on 20 to 40 percent of eligible virtual machines.

It gets left off for mundane reasons. Templates and landing zone scripts are written without the licenseType setting, machines rebuilt from images lose it, and teams under migration deadlines accept the portal defaults. The benefit also only runs while Software Assurance or the subscription license term is active, so a lapsed agreement is a second way to lose it.

How to check which machines have it switched on

• Portal. Each virtual machine shows the Azure Hybrid Benefit setting under its Operating system page.
• PowerShell and CLI. Get-AzVM and az vm list both return the licenseType property. Windows_Server means the benefit is on, and None or an empty value means you pay the full Windows rate.
• Azure Resource Graph. One query across every subscription lists all virtual machines with their licenseType, which is the only practical way to sweep a large tenant.
• SQL Server virtual machines. The SQL virtual machine resource carries its own license type: pay as you go, Azure Hybrid Benefit, or HA/DR for passive replicas.

Match the sweep against your license count before you switch anything on. Azure counts a minimum of 8 core licenses per virtual machine, larger machines need one core license per core, and a processor license counts as 16 core licenses. Enabling the benefit on more cores than you own with Software Assurance creates a compliance gap instead of a saving.

A worked example of what the gap costs

Say you run 200 Windows virtual machines on Azure, all covered by Windows Server licenses with Software Assurance, and 60 of them have the benefit off. That is 30 percent of the fleet, inside the range we typically find. Suppose those 60 machines cost $600,000 a year at the full rate.

Check the last row before anything else. A 4 vCPU machine still consumes 8 core licenses because of the per machine minimum, so 60 small machines need 480 core licenses with active Software Assurance. Confirm you hold them before the switch goes on.

When should SQL Server move from Enterprise to Standard at migration?

Revisit the edition for every workload before migration. Enterprise running work that Standard would carry inflated cost by 2 to 4 times per core in the migrations we reviewed. The edition decision usually predates the cloud, made years ago on hardware you already owned, where the over specification was tolerable.

Microsoft's own list prices show the gap. SQL Server 2022 Enterprise lists at $15,123 per 2 core pack against $3,945 for Standard. Billed pay as you go, Enterprise is $274 per core per month and Standard $73, a ratio of close to four to one.

A worked example at pay as you go list prices

Say you migrate 20 SQL Server virtual machines of 8 vCores each, 160 cores in total, all on Enterprise today. A workload review shows 12 of them use no Enterprise features and fit within Standard's limits.

What justifies keeping Enterprise

Keep Enterprise where a workload uses features or scale that Standard does not offer: large memory footprints, readable secondary replicas for reporting, online index rebuilds, or unlimited virtualization on a licensed host. Check each against the current SQL Server edition comparison and the database's actual use today.

For the full per core rules on physical and virtual machines, see our SQL Server licensing guide for 2026.

What does the dedicated host requirement do to an AWS business case?

It adds cost the business case did not model. In about 6 of 10 business cases we reviewed, Windows Server BYOL was assumed portable to AWS on shared instances. The dedicated host requirement then added 15 to 30 percent to the modeled compute bill, and that part of the saving disappeared.

Take a hypothetical AWS case modeled at $1,000,000 a year of compute on shared tenancy. Adding the dedicated host requirement puts $150,000 to $300,000 back on the bill. Licenses bought after October 2019 cannot even take that route, so their Windows cost shifts to the license included rate instead.

Why we do not start from "bring your own licenses wherever you go"

The standard advice on a cloud move is to reuse every license you already own. For the server applications that holds, because License Mobility makes SQL Server portable. For Windows Server on a Listed Provider other than Microsoft, it often fails, because dedicated hosts are sized, reserved and paid whether you fill them or not.

We price both routes for each workload group: BYOL on dedicated hosts with prior rights, and license included on shared instances. Whichever is cheaper at the real level of use wins, and the answer often differs between a dense database cluster and a scattered fleet of small application servers.

Two companies running identical workloads can face completely different rules, depending on when their licenses were bought and whether Software Assurance is current.

How the answer changes with size and license history

• A 500 user company with a recent agreement. Most Windows Server licenses postdate October 2019, so AWS means license included. Azure Hybrid Benefit is often the biggest difference between the clouds.
• A 20,000 user company with an older Enterprise Agreement. A share of licenses may carry prior rights, which makes dedicated hosts viable for dense clusters. Establish which licenses have those rights before the architecture is fixed.
• A mixed cloud plan. SQL Server can follow the workload through License Mobility, while Windows Server follows different rules on each provider. Model the two products separately.

What have we seen in Microsoft cloud migration reviews in 2024 and 2025?

Across roughly 35 to 45 Microsoft customers we benchmarked for hyperscale migration between 2024 and 2025, the original cloud business case understated the licensing line more often than not. The three patterns described above recurred:

• AWS modeled on shared tenancy. The Windows Server line was priced as BYOL on ordinary instances, and no one had checked license purchase dates.
• Hybrid Benefit missing after cutover. Machines built from older templates or rebuilt from images ran at the full Windows rate.
• Enterprise carried over by default. The edition on each migrated database matched the on premises install, with no review of the features in use.

None of these were hidden in obscure clauses. Each was visible in the Product Terms, the portal or the edition comparison, and each persisted because no process owned it after the migration went live.

What will the Microsoft account team say, and how should you answer?

Expect the account team to frame licensing in whatever way supports the Azure commitment it is working on. The lines below are common, and each has a precise reply.

• "Your licenses only work properly on Azure." True for Windows Server on shared instances. SQL Server with Software Assurance is portable to AWS and Google Cloud through License Mobility, so ask for the comparison workload by workload.
• "Renew Software Assurance on everything before you move." You need it on the licenses you will run with Hybrid Benefit or License Mobility. Servers that retire during the migration do not need renewing.
• "Keep Enterprise for headroom in the cloud." In the cloud you add capacity by resizing the virtual machine, which Standard handles up to its own core and memory limits. License each database for the features it uses today.
• "The migration assessment already includes Hybrid Benefit." An assessment assumption is a pricing input. The saving exists only where licenseType is set on each deployed virtual machine or SQL resource and you hold the core licenses, so ask for the licenseType report across your subscriptions and check it against your entitlement.

For the pricing side of the same conversation, our note on using Azure and AWS price comparisons in a Microsoft negotiation covers how to present the alternative credibly.

When should each licensing check happen during a migration?

Put the checks on the migration calendar, with the licensing owner named against each. The order matters, because the early checks decide whether the business case holds.

Hybrid Benefit gives 180 days in which the same Windows Server Standard and SQL Server licenses can run on premises and in Azure while servers move. After that, each of those licenses must sit in one place. Windows Server Datacenter licenses applied to individual Azure virtual machines may keep running on premises as well, with no time limit.

The detailed Azure mechanics are in our Azure Hybrid Benefit guide, and you can test your own numbers in the license optimization calculator.

What to do next

1. Name an owner. Give the licensing position a named operational owner, because a wrongly licensed machine runs identically to a correct one and no alert will tell you.
2. Establish vintage first. List license purchase dates and Software Assurance status per product, and read them against the Product Terms rather than a vendor slide.
3. Sweep for Hybrid Benefit. Run a Resource Graph query for licenseType across every subscription and switch the benefit on where you hold the core licenses.
4. Price the dedicated host. Confirm the Windows Server route on AWS or Google Cloud before the figure goes into a board paper.
5. Review SQL Server edition. Move each workload that uses no Enterprise features to Standard during the migration, while the database is being rebuilt anyway.
6. File the paperwork. Send License Mobility verification forms within the deadline and record which licenses run where.
7. Get a second view. Our Microsoft practice runs this check with you against your own license records.

Frequently asked questions