Why Cloud Migration Licensing Is Not What You Think
Most enterprise IT teams approach cloud migration with a workload-first mindset: lift the server, rehost the application, validate performance. Licensing is often treated as an afterthought, a box to tick before go-live. This is exactly the approach Microsoft counts on. The licensing rules governing cloud migration are not neutral — they are designed to steer workloads toward Azure and to extract additional commercial value when customers choose AWS or Google Cloud Platform (GCP) instead.
Understanding these rules before you commit to a migration architecture is not optional. Get it wrong, and you face one of two outcomes: double-paying for software you already own, or running non-compliant workloads that expose you to audit risk at your next True-Up or Enterprise Agreement renewal. Both outcomes are avoidable with the right knowledge.
This guide breaks down the specific licensing implications for each of the three major cloud platforms, covering Windows Server, SQL Server, and Microsoft 365 workloads, and shows where your real leverage lies in negotiation.
Azure: The Most Favourable Migration Destination — By Design
Microsoft has deliberately made Azure the most licensing-friendly destination for workloads running on Microsoft products. This is not altruism; it is commercial strategy. Azure revenue benefits directly from enterprises consuming compute, storage, and managed services at scale. The licensing incentives are built to pull workloads onto Azure infrastructure rather than compete with AWS or GCP on neutral terms.
Azure Hybrid Benefit for Windows Server
If you hold Windows Server Datacenter or Standard licences with active Software Assurance (SA), you qualify for the Azure Hybrid Benefit (AHB). This benefit allows you to apply your existing on-premises licences to Azure virtual machines, eliminating the embedded Windows licence cost that Microsoft would otherwise charge as part of the VM price. For Datacenter licence holders, the savings are significant: Azure VMs running Windows Server are typically priced 40–60% higher than equivalent Linux instances because of the embedded OS licence. AHB removes that premium entirely.
Critically, AHB includes a 180-day dual-use right. During a migration, you can run the same licence simultaneously on your on-premises server and on an Azure VM. This migration window exists nowhere else — not on AWS, not on GCP. It gives your team a genuine grace period to validate cloud performance before decommissioning on-premises infrastructure without any licensing gap.
Azure Hybrid Benefit for SQL Server
SQL Server licences with active Software Assurance carry an equally valuable Azure Hybrid Benefit. Applying SQL Server Enterprise licences via AHB to Azure SQL Database, SQL Managed Instance, or SQL Server in Azure VMs can reduce the effective SQL licence cost in Azure by 30–50% compared to the pay-as-you-go licence-included pricing. For organisations running a significant SQL Server estate — which describes the majority of large enterprises on Microsoft EAs — this translates to material annual savings that should be factored into any cloud business case.
The nuance here is that AHB for SQL Server must be actively assigned. Microsoft does not automatically apply your benefit; your team or your Microsoft licensing specialist must configure it correctly within the Azure portal. Forgetting to apply AHB — or applying it to the wrong resource type — means you silently pay the full included licence price while your on-premises SQL licences sit unused. We see this on nearly every cloud cost review we conduct.
Windows Server 2025: Pay-as-You-Go via Azure Arc
Windows Server 2025 introduces a new pay-as-you-go licensing model for organisations using Azure Arc. Arc-connected on-premises servers can now be billed at a per-core monthly rate of approximately $33.58 per core, providing an alternative for organisations that want predictable cloud-like billing for on-premises infrastructure. For customers without unlimited virtualisation rights — those on Standard rather than Datacenter editions — this model can be more cost-effective than purchasing additional perpetual core licences for workload growth. It is a mechanism worth evaluating in any hybrid architecture, though the cumulative cost must be modelled over a multi-year horizon before committing.
AWS: BYOL Restrictions Have Materially Tightened
Amazon Web Services has historically been the preferred destination for enterprises seeking to avoid Microsoft's Azure pull, but Microsoft has systematically tightened its Bring Your Own Licence (BYOL) policies for AWS over the past three years. The 2022 licensing changes fundamentally altered the BYOL calculus for Windows Server on AWS, and those changes are now fully in effect.
Windows Server 2022 and Later: No BYOL on AWS
The Flexible Virtualization Benefit (FVB), which allows BYOL for Windows Server on third-party clouds, explicitly excludes AWS, Google, and Alibaba. This is not an oversight — it is a deliberate commercial restriction. For Windows Server 2019 and earlier, organisations can still BYOL on AWS using the Licence Mobility via Software Assurance pathway, provided they have active SA and the cloud provider is an Authorized Mobility Partner. AWS maintains this status, so older workloads remain portable.
However, organisations upgrading to Windows Server 2022 or Windows Server 2025 lose this BYOL pathway for AWS entirely. New-version Windows Server workloads on AWS must use Amazon's licence-included pricing — meaning you pay Amazon for a Windows Server licence you may already own on-premises. This effectively creates double-licensing costs for any organisation that both runs active Microsoft SA and moves new-build Windows Server workloads to AWS.
The financial impact is substantial. A mid-size estate of 50 Windows Server VMs on AWS, running Standard 8-core instances, carries an embedded Windows licence cost of approximately $500–$800 per VM per month, depending on instance type. Multiply that by 50 VMs and you are paying $25,000–$40,000 per month purely in embedded Windows licence charges — while simultaneously paying for active Software Assurance on licences you cannot use on that platform. This is the double-licensing trap, and it catches migration teams who do not check the current BYOL rules before selecting AWS as their target platform.
SQL Server BYOL on AWS: Still Possible, With Conditions
SQL Server BYOL on AWS remains available under the Licence Mobility via Software Assurance programme, as long as the following conditions are met: licences must be fully paid and perpetual (not subscription-based), Software Assurance must be active, AWS must be confirmed as an Authorised Mobility Partner at the time of deployment, and Microsoft must be notified via the formal Licence Mobility Verification process. Skipping any of these steps — particularly the notification — leaves you technically non-compliant even if you believe you have the right to BYOL. We have seen Microsoft raise this in EA audit discussions; the paperwork matters.
GCP: Similar Restrictions, Different Partner Ecosystem
Google Cloud Platform faces the same core restriction as AWS: Windows Server 2022 and later cannot be BYOL-deployed under the Flexible Virtualization Benefit exclusion. Organisations running GCP workloads on Windows Server must use Google's licence-included pricing for newer OS versions.
For SQL Server on GCP, the Licence Mobility via Software Assurance pathway theoretically applies, but GCP has historically had fewer Authorised Mobility Partners than AWS, and the verification process can be slower. The practical advice for SQL Server migrations to GCP is to confirm Mobility Partner status with your Microsoft licensing specialist before committing to architecture, and to build 4–6 weeks into the project plan for Microsoft notification and verification processing.
The Flexible Virtualization Benefit Partial Solution
Microsoft introduced the Flexible Virtualization Benefit to partially address BYOL complexity for third-party clouds, but its applicability is narrower than the name suggests. The FVB allows BYOL deployment in dedicated hosting environments — scenarios where the physical hardware is dedicated to your organisation — with certain Microsoft products. However, for standard shared-infrastructure AWS or GCP deployments (the typical cloud model), the dedicated hosting requirement means FVB rarely applies in practice. Only organisations using AWS Dedicated Hosts or GCP Sole-Tenant Nodes can take advantage of FVB, and those dedicated hosting models carry significant cost premiums that often eliminate any licensing savings achieved.
Microsoft 365 Workloads: Cloud Migration Is Simpler, but Not Risk-Free
Microsoft 365 cloud workloads — Exchange Online, SharePoint Online, Teams — are licensed on a per-user subscription basis and do not carry the same BYOL complexity as server products. When you migrate on-premises Exchange or SharePoint to Microsoft 365, you are effectively replacing perpetual server licences with subscription CAL suite equivalents, and the licensing transition is managed through your EA or NCE agreement.
The risk during M365 migrations is not BYOL compliance — it is over-provisioning during the migration window. Organisations frequently run parallel on-premises and cloud environments for 3–6 months during migration, paying both the on-premises CAL and Server costs and the cloud subscription simultaneously. This parallel-run cost is a real budget impact that rarely appears in initial migration business cases. It should. For a 5,000-user organisation migrating from E3 on-premises to E3 cloud, the parallel-run cost at standard EA rates can exceed £150,000 during a four-month cutover period.
The mitigation is to negotiate with your Microsoft account team for a migration window credit or a phased subscription activation that aligns cloud seat activation with actual user cutover dates rather than project kickoff. This negotiation is easier during the April–June Q4 window, when Microsoft field reps are under maximum pressure to close and retain enterprise accounts before the June 30 fiscal year end.
SKU Considerations: E3, E5, E7 and the Cloud Architecture Decision
For organisations negotiating or renewing their Microsoft 365 EA in the context of a cloud migration, the current SKU stack matters. The M365 suite now runs E1 → E3 → E5 → E7, with E7 as the top tier introduced above E5. E7 bundles advanced AI features, Microsoft 365 Copilot, and security capabilities that were previously add-ons to E5. Microsoft field teams are actively moving E5 customers to E7 at renewal, positioning Copilot inclusion as the commercial justification.
For cloud migration planning, the relevant implication is that if your migration to Azure or M365 cloud coincides with an EA renewal, you have a meaningful negotiation window. A migration commitment — Azure consumption commitment, cloud seat expansion — gives your procurement team a lever to push back on E5-to-E7 upsell pricing. Microsoft's field incentives reward new cloud commit, and a well-timed negotiation can secure E7 at pricing that makes the upgrade genuinely cost-effective rather than a straight price increase. Do not allow the migration timeline to be decoupled from the commercial negotiation; the two should run in parallel.
Not sure which cloud migration path minimises your Microsoft licensing exposure?
Our Microsoft EA advisory specialists have reviewed 200+ cloud migrations across EMEA and North America.Key Rules to Check Before Any Cloud Migration Commits
Before your architecture team finalises a cloud target, your licensing function needs to confirm the following for each Microsoft workload in scope:
- Windows Server version: Is this 2019 or earlier (Licence Mobility possible for AWS/GCP) or 2022/2025 (BYOL blocked on AWS/GCP)? The answer changes the cost model substantially.
- Software Assurance status: Are active SA rights in place? Without SA, Azure Hybrid Benefit and Licence Mobility are both unavailable. Check SA expiry against migration timeline.
- SQL Server edition: Enterprise versus Standard, and whether AHB has been correctly applied in the target environment.
- Dedicated hosting requirement: If deploying to AWS or GCP and seeking FVB coverage, confirm whether Dedicated Hosts or Sole-Tenant Nodes are in scope and whether the cost premium is justified.
- EA True-Up date: Cloud migrations that run across a True-Up date can create an inflated True-Up bill if cloud seats are counted before on-premises decommission is complete. Map your migration phases against your EA anniversary date.
- NCE versus EA for cloud seats: New Commerce Experience (NCE) monthly commitments carry no discount; annual NCE commitments carry up to 5% off list. If your cloud migration creates new seat subscriptions, ensure they land in the right commitment model from day one.
Negotiation Timing: Q4 Is Your Window
Microsoft's fiscal year ends June 30. The Q4 window — April through June — is when Microsoft field account managers face maximum quota pressure and have maximum authority to offer migration incentives, Azure consumption credits, and SKU transition flexibility. If your cloud migration is in planning and your EA renewal or expansion falls within 12 months, structuring commercial discussions to land in Q4 is worth the planning effort. The leverage differential between a Q4 discussion and a Q2 (October–December) discussion is measurable: in our experience, customers who negotiate in Q4 achieve discounts 5–10 percentage points higher than equivalent deal terms in Microsoft's Q1 or Q2.
Current EA discounts sit at 10–20% off list price, down from the historical 15–25% that was achievable before 2022. Monthly NCE commitments carry zero discount. Annual NCE commitments yield up to 5%. The EA structure remains the most commercially effective vehicle for large-scale cloud migrations if your organisation has the user count and commitment to qualify. For organisations being pushed toward MCA (Microsoft Customer Agreement) by their Microsoft account team, be aware that MCA reduces your negotiation leverage relative to a traditional EA negotiation — it is Microsoft's preferred motion precisely because the commercial terms are less favourable to the buyer.