SPLA and BYOL answer the same question — how is Microsoft software licensed when it runs in a hosted environment — but they put the compliance risk in opposite places. Under the Services Provider License Agreement (SPLA) the service provider licenses the software and reports usage monthly. Under bring-your-own-license (BYOL), the end customer supplies licenses they already own, typically with active Software Assurance and License Mobility. Choosing between them is a decision about cost, control, and who is liable when an auditor disagrees with the numbers. This guide sits under our Microsoft SPLA licensing guide and focuses on the buyer-side trade-off.
The instinct of many hosting businesses is to default everything to SPLA because it is simple: nothing is required of the customer and cost scales with usage. That instinct is usually right, but not always. For a subset of large customers — those who already own the relevant Microsoft licenses with Software Assurance — paying again through SPLA is paying twice for the same right. Knowing where that line falls is what separates a competitive hosting price from a needlessly inflated one.
Who holds the risk under each model
Under SPLA, the provider signs the agreement, reads the Product Terms each month, counts usage, and carries the audit exposure. If a report is wrong, Microsoft bills the provider. Under BYOL, the customer owns the licenses and the Software Assurance that makes them portable; the customer carries the compliance obligation for those licenses, and the provider's responsibility narrows to running the workload on infrastructure that meets the eligibility rules — most importantly, the rules on dedicated hardware described in our shared vs dedicated hardware guide.
This split matters commercially. A provider that hosts a customer's BYOL workload removes the Microsoft license cost from its own books, which can sharpen pricing — but it also inherits a dependency on the customer keeping Software Assurance current. If the customer lets Software Assurance lapse, License Mobility evaporates and the workload can fall out of compliance overnight, often without the provider knowing. Good BYOL arrangements put that obligation in writing.
Cost: when each model wins
| Factor | SPLA | BYOL (License Mobility) |
|---|---|---|
| Who licenses | Service provider | End customer |
| Who carries audit risk | Provider | Customer (for their licenses) |
| Cost behaviour | Monthly, scales with usage | Sunk in customer's existing SA |
| Hardware requirement | Shared or dedicated | Often dedicated; SA + License Mobility required |
| Best fit | Multi-tenant, variable usage, no customer SA | Large customer with existing SA-backed licenses |
SPLA wins on multi-tenant estates with variable or unpredictable usage, on customers who own no relevant licenses, and wherever consolidation onto shared hardware is the priority. BYOL wins when a customer already owns licenses with Software Assurance, when the workload is large and stable enough to justify dedicated hardware, and when the customer would rather use an asset they have already paid for than rent it back through the provider.
The products where the choice is sharpest
The two products where SPLA-versus-BYOL economics diverge most are Windows Server and SQL Server, both licensed per core. For a large, stable SQL Server estate owned by a customer with Software Assurance, BYOL can remove a substantial recurring line from the provider's SPLA report. The per-core mechanics that make this material are covered in Windows Server SPLA licensing and SQL Server SPLA licensing. For access-based products licensed by Subscriber Access License, BYOL is rarely worth the complexity and SPLA almost always wins.
The double-pay trap: the most common avoidable cost in hosted Microsoft estates is a provider reporting a workload under SPLA while the customer is simultaneously paying Software Assurance on licenses that already cover it. Neither party notices because the costs sit on different invoices. A simple annual cross-check between the SPLA report and large customers' license positions usually pays for itself many times over.
How to decide in practice
The workable rule is to default to SPLA and carve out BYOL by exception. For each large customer, ask three questions: do they own the relevant Microsoft licenses, is their Software Assurance current, and can the workload run on hardware dedicated to them? Three yeses make BYOL worth modelling. Any no, and SPLA is almost certainly the cleaner answer. Infrastructure providers running rented virtual machines face a more layered version of this question, which we address in Microsoft licensing for IaaS providers.
Whichever model you choose, document the basis for it. In an audit, the provider must be able to show why a given workload was reported under SPLA or excluded as BYOL, and must hold the evidence — for BYOL, typically the customer's License Mobility verification and proof of active Software Assurance. A clean decision with no paper trail is indistinguishable, to an auditor, from no decision at all. Our advisors build that decision record as part of Microsoft audit defense, and the underlying program rules are summarised in the SPLA licensing guide.
Common mistakes when choosing between SPLA and BYOL
The first mistake is treating the choice as permanent. A customer who has no Software Assurance today may acquire it at their next Enterprise Agreement renewal, at which point a workload that was correctly on SPLA becomes a candidate for BYOL. Providers who review the model only at onboarding miss these transitions and leave money on the table for years. A light annual review of large customers' license positions is enough to catch them.
The second mistake is accepting a BYOL claim without verification. When a customer asks the provider to exclude a workload from SPLA because they will license it themselves, the provider is the one an auditor will bill if the claim turns out to be unfounded. License Mobility verification and proof of active Software Assurance must be collected and retained before the workload is excluded, not promised and forgotten. An undocumented BYOL exclusion is the easiest finding an auditor can make.
The third mistake is ignoring the operational dependency BYOL creates. Once a workload depends on the customer's Software Assurance, the provider needs a way to know if that Software Assurance lapses, because the moment it does, the workload is out of compliance and the provider is exposed. Building a renewal-date check into the customer record turns an invisible risk into a managed one.
A short decision sequence
For each candidate workload, walk a simple sequence. Confirm whether the customer owns the relevant licenses; if not, it is SPLA. If they do, confirm Software Assurance is current and will stay current; if not, it is SPLA. If both hold, confirm the workload can run on hardware dedicated to that customer; if not, it is usually SPLA. Only when all three conditions hold does BYOL become the cleaner, cheaper answer — and even then, document the basis and keep the evidence. This sequence keeps the default simple while capturing the exceptions that genuinely pay.