License Mobility Rights

License mobility rights determine whether you can move software you already own onto cloud infrastructure without rebuying it, and Microsoft's 2022 outsourcing rules restricted bringing many Windows and SQL Server licenses to AWS, Google Cloud, Azure, and Alibaba, the four Listed Providers, unless the licenses were bought before October 2019 or run on dedicated hosts. The rules are technical, the exceptions are narrow, and the cost of getting them wrong is paying twice for software you thought you owned. Mobility has to be confirmed before a migration, not assumed during it.

What license mobility is

License mobility is the contractual right to apply an existing software license to infrastructure you do not own, typically a public cloud. Without it, a license bought for on-premise use stays on premise, and moving the workload to cloud means buying the software again through the cloud provider's license-included pricing. With it, you bring the license you already paid for and pay the cloud provider only for the infrastructure. The right is not automatic; it depends on the specific product, the specific license, the support or subscription status, and increasingly on which cloud you are moving to. The whole question is whether the right exists for your situation, because the default in many cases is that it does not.

Microsoft License Mobility through Software Assurance

Microsoft grants license mobility for many server products to customers with active Software Assurance, but the right is product-specific and conditional. The table sets out the common products and how mobility applies.

The pattern is that server applications with Software Assurance move relatively freely, while the operating systems carry the heaviest restrictions, which is the source of most of the confusion and most of the unexpected cost. How this plays out specifically on Microsoft's own cloud is covered in our Microsoft BYOL to Azure guide, and the SQL Server detail sits in SQL Server licensing.

The Listed Provider restriction

The change that caught the most buyers is Microsoft's designation of AWS, Microsoft Azure, Google Cloud, and Alibaba as Listed Providers, with tighter rules for bringing certain licenses to them. The effect is that licenses without the right vintage or the right infrastructure cannot move to the largest clouds without buying afresh, while Azure, Microsoft's own cloud, retains more favorable terms, which is itself a commercial nudge toward Azure. The two principal escape routes are a license bought before the October 2019 cutoff, which retains the older, broader rights, and a dedicated host, where you license a physical server in the cloud rather than a shared one. Both have cost and architectural consequences that have to be modeled before relying on them.

Oracle and IBM portability

The other major vendors have their own portability rules, and they do not match Microsoft's. Oracle permits bringing licenses to authorized clouds under its cloud licensing policy, with the count driven by the core-factor rules that apply to virtual cores on AWS and Azure, which can make the cloud count more or less favorable than on premise depending on the instance type. The detail and the core-factor math are covered in our Oracle AWS BYOL guide. IBM permits bringing eligible licenses to cloud under its Passport Advantage and sub-capacity terms, with the usual requirement that sub-capacity counting be supported by the right tooling. The common lesson is that each vendor's portability is its own contract question, and a multi-vendor migration has to answer it separately for each.

Cost modeling: BYOL versus license-included

Even where mobility exists, bringing your own license is not automatically cheaper. License-included pricing bundles the software into the hourly cloud rate, which is simpler and avoids the on-premise support fee that often continues in parallel under BYOL. Bring-your-own-license is cheaper when the existing licenses are paid for and the support cost is already sunk, and more expensive when continuing support plus the dedicated-host premium outweighs the bundled rate. The decision is a model that compares the all-in BYOL cost, including continuing support and any host premium, against the license-included rate over the workload's expected life. That model is the core of our BYOL cloud strategy guide.

Governing mobility over the migration

Mobility rights are a moving target because vendors revise the rules, so the position has to be confirmed at the point of migration and re-checked at renewal. Document which licenses carry mobility, which depend on a pre-cutoff vintage, and which rely on a dedicated host, because a routine license true-up or a support lapse can silently void a mobility right the migration depends on. Fold the mobility position into the contract review at every renewal so a vendor rule change is caught before it strands a workload. The negotiation strategy that protects these rights at the contract sits in our software contract negotiation guide.

Software Assurance as the price of mobility

For Microsoft products, mobility is largely a benefit of Software Assurance, the maintenance program that adds cost on top of the base license, which means mobility is not free even where it exists. A buyer weighing whether to maintain Software Assurance has to count mobility among the benefits it buys, alongside upgrade rights and other entitlements, because letting Software Assurance lapse can strand licenses on premise that the cloud roadmap depends on moving. The decision is a model: the cost of maintaining Software Assurance against the value of the mobility and other benefits it confers, set against the alternative of license-included cloud pricing. For an organization with a serious cloud migration ahead, the mobility benefit can justify Software Assurance on its own, while for a static estate it may not.

Mobility and audit exposure

Bringing your own license to cloud creates its own compliance surface, because the rules on which licenses may move, to which clouds, and under what conditions are exactly the kind of detail an audit examines. A license moved to a Listed Provider without the right vintage or the right host, or a sub-capacity claim on cloud without the tooling to support it, is a finding waiting to happen. The protection is documentation: a clear record of which licenses carry mobility, the basis for each, and the infrastructure they run on, maintained as part of the broader compliance position. That standing record is covered in our software license management guide, and it is what turns a mobility decision into a defensible one rather than an assumption the next audit tests.

Building mobility into the migration plan

The buyers who avoid rebuying software are the ones who put mobility into the migration plan from the start rather than discovering the rules midway. Before a workload is scheduled to move, the plan should confirm whether its licenses can move with it, whether a dedicated host is needed and whether it will be dense enough to pay, and whether license-included pricing is simply the better deal for that workload. Sequencing the migration so that workloads with clean mobility move first, and workloads that need re-licensing are planned deliberately, prevents the scramble that produces double payment. The full bring-your-own-license decision across vendors and clouds is set out in our BYOL cloud strategy guide.

The Windows Server and desktop OS exception

The operating system layer is where mobility breaks down most often, and it deserves its own attention because the rules differ sharply from the application layer. Windows Server licenses face the tightest Listed Provider restrictions, which is why so many cloud migrations end up using the cloud provider's license-included Windows rather than bringing existing licenses. The Windows desktop operating system is generally not mobile at all, so virtual desktop deployments on cloud typically license the desktop OS through the provider rather than through existing entitlements. The practical consequence is that the operating system cost of a cloud migration is frequently a fresh purchase even when the application licenses move cleanly, and that cost has to be in the migration model from the start. Treating the OS layer as automatically portable is one of the most common and most expensive mobility mistakes, and confirming its treatment per workload is part of the disciplined plan covered in our BYOL cloud strategy guide.

Negotiating mobility into the agreement

Mobility rights are not purely a matter of reading the standard terms; for a large buyer they are negotiable, and the time to negotiate them is before a migration depends on them. A buyer planning a significant cloud move can press for explicit mobility commitments, for clarity on how cloud cores are counted, and for protection against mid-term rule changes that would otherwise strand workloads. Vendors revise mobility rules to steer customers toward their own clouds, so a buyer who secures the mobility terms in writing, rather than relying on policy that can change, protects the migration plan from a unilateral shift. The work is to identify which workloads depend on mobility, quantify what a rule change would cost, and convert that into specific contractual protection during the negotiation. Mobility left to standard policy is a risk the vendor controls; mobility negotiated into the agreement is a right the buyer holds, and securing it is part of the broader strategy in our software contract negotiation guide.

SQL Server: the product where mobility pays most

SQL Server is the product where license mobility delivers the clearest return, because its license cost is high and its mobility rights, with active Software Assurance, are relatively broad. A buyer with paid-up SQL Server licenses and Software Assurance can bring them to most clouds and avoid the substantial cost of license-included SQL, which on a large database estate is real money every month. The conditions matter: the License Mobility benefit has to be active, the deployment has to meet the counting rules, and the on-premise support cost continues in parallel, so the model still has to compare the all-in bring-your-own-license cost against the license-included rate. But for a stable SQL estate already carrying Software Assurance, mobility is frequently the cheaper path by a wide margin, which is why the SQL layer deserves its own analysis in any migration. The detailed SQL rules sit in our SQL Server licensing guide, and the cross-vendor decision in our BYOL cloud strategy guide.

The buyer's takeaway

License mobility decides whether a cloud migration reuses software you own or rebuys it, and the rules are vendor-specific, conditional, and subject to change. Confirm mobility for each product before you migrate, know whether your Microsoft licenses clear the Listed Provider rules through vintage or a dedicated host, check Oracle and IBM portability separately, and model bring-your-own-license against license-included pricing including continuing support. Re-check the position at every renewal. We test mobility and negotiate the terms through our cloud contract negotiation and software licensing advisory practices. The license you can move is an asset; the one you assumed you could move is a second invoice.