Microsoft SPLA to CSP Migration Transition Guide for Service Providers

This guide is part of the Microsoft Licensing Knowledge Hub. For SPLA foundations, see Microsoft SPLA Licensing Guide. For related guidance, see EA vs CSP Guide and EA to CSP/MCA Transition Checklist.

The SPLA-to-CSP migration is driven by a convergence of market forces, Microsoft's strategic direction, and the operational realities of running on-premise hosting infrastructure in an increasingly cloud-native world.

SPLA cost escalation. Microsoft has increased SPLA pricing consistently over recent years, with annual increases of 5 to 10% on key products (Windows Server, SQL Server, RDS). These increases compound: a product that cost $100/month per core five years ago may now cost $130 to $160. Meanwhile, CSP pricing for equivalent cloud services has remained competitive or decreased as Microsoft scales Azure infrastructure. The cost trajectory favours cloud delivery over on-premise hosting for an increasing proportion of workloads.

SPLA audit risk elimination. SPLA is one of the most frequently audited Microsoft programmes. Audit findings routinely reach hundreds of thousands to millions of dollars. Migrating workloads from SPLA-licensed on-premise infrastructure to CSP-delivered cloud services eliminates SPLA audit exposure for those workloads entirely. Usage under CSP is tracked automatically by Microsoft's cloud platform, removing the monthly reporting burden and the compliance risk that accompanies manual reporting of physical cores and subscriber access. See our SPLA Audit Defence Service.

Customer demand for cloud services. Enterprise customers increasingly require Microsoft 365 (rather than hosted Exchange/SharePoint), Azure-based infrastructure (rather than dedicated hosting), and cloud-native management tools. Service providers that deliver these through CSP retain customers and grow accounts. Those limited to SPLA-hosted on-premise services lose deals to cloud-capable competitors. The migration is not just a licensing optimisation. It is a business survival imperative for service providers in a cloud-first market.

Operational simplification. CSP eliminates the operational overhead of SPLA: monthly reporting, physical server management, hardware procurement and lifecycle, datacentre costs, and the infrastructure engineering required to maintain hosted environments. Under CSP, Microsoft manages the underlying infrastructure (for M365, Azure PaaS/SaaS services), and the service provider focuses on value-added management, configuration, security, and customer support. This operational shift improves margins for providers that successfully transition their service model.

Not every SPLA workload should migrate to CSP, and not every service provider is ready for the transition. A structured readiness assessment prevents costly false starts, customer disruptions, and compliance gaps during the migration.

Categorise every SPLA workload by migration suitability. Inventory every workload running under SPLA and classify it into one of four categories. Migrate: workloads with direct CSP/cloud equivalents (hosted Exchange to Microsoft 365, hosted SharePoint to SharePoint Online, basic Windows hosting to Azure VMs). Refactor: workloads that can move to cloud but require architectural changes (custom SQL Server applications to Azure SQL, RDS-hosted desktops to Azure Virtual Desktop). Retain on SPLA: workloads with no viable cloud equivalent or regulatory constraints requiring on-premise hosting (legacy applications, data sovereignty requirements, specialised hardware dependencies). Retire: workloads that are end-of-life and should be decommissioned rather than migrated.

Assess customer readiness and willingness. Every customer has different migration readiness. Assess each customer across three dimensions: technical readiness (network connectivity, identity infrastructure, application compatibility), commercial readiness (contract terms that permit service model changes, budget for potential cost differences), and organisational readiness (change management capacity, stakeholder buy-in). Prioritise willing, technically ready customers for early migration phases. They provide proof points and reference cases for later phases.

Evaluate internal capabilities and economics. The service provider must assess its own readiness: technical skills (does the team have Azure, M365, and CSP platform expertise?), commercial model (can the provider sustain margin under CSP pricing?), partner programme requirements (has the provider enrolled as a CSP direct-bill partner or indirect reseller?), and transition capacity (can the provider run SPLA and CSP in parallel without overwhelming operations?). Gaps in any dimension must be addressed before migration begins.

The migration is not a simple licence swap. It is a service model transformation. Each SPLA product maps to one or more CSP alternatives, but the delivery model, pricing structure, and customer experience change fundamentally.

Exchange to Microsoft 365: the easiest win. Hosted Exchange to Microsoft 365 is the most straightforward SPLA-to-CSP migration and typically the first workload to transition. Microsoft provides native migration tools (hybrid Exchange, cutover migration, staged migration) that handle mailbox, calendar, and contact migration with minimal downtime. The customer experience improves (better mobile apps, OneDrive integration, Teams collaboration), and the provider eliminates Exchange Server SPLA licensing, server management, patching, and backup responsibilities. Most MSPs complete Exchange migrations within 2 to 4 weeks per customer.

RDS to Azure Virtual Desktop: the complex migration. Remote Desktop Services hosted under SPLA represents the most technically complex migration. Azure Virtual Desktop provides equivalent remote desktop capabilities but requires rearchitecting: session host deployment in Azure, user profile management (FSLogix), application packaging, printing configuration, and network optimisation for latency-sensitive workloads. The migration timeline is typically 2 to 6 months per customer depending on application complexity. However, AVD eliminates RDS SAL licensing, physical server costs, and the per-core Windows Server SPLA burden on RDS hosts.

SQL Server to Azure SQL: multiple paths. SQL Server migrations offer multiple CSP destinations depending on the workload. Azure SQL Database (fully managed PaaS, best for modern applications). Azure SQL Managed Instance (near-100% SQL Server compatibility with managed infrastructure). SQL Server on Azure VMs (lift-and-shift with full SQL Server feature parity). The migration path depends on SQL Server features used, compatibility requirements, performance needs, and the customer's tolerance for application refactoring. Azure SQL Managed Instance is the most common destination for SPLA SQL Server workloads because it provides high compatibility with minimal application changes. See our SQL Server Licensing Guide.

No service provider completes an SPLA-to-CSP migration overnight. The transition period, typically 12 to 24 months, requires running both programmes simultaneously. Managing this hybrid phase is critical: the provider must maintain SPLA compliance for workloads that have not yet migrated, manage CSP subscriptions for migrated workloads, and avoid the double-licensing that occurs when both programmes cover the same service during the handover.

Maintain full SPLA compliance for remaining workloads. Every workload that remains on the provider's on-premise infrastructure under SPLA must continue to be accurately reported and licensed until it is fully decommissioned. The most dangerous period for SPLA compliance is during migration, when operational attention shifts to cloud deployment and SPLA reporting discipline deteriorates. Designate a team member specifically responsible for SPLA reporting continuity during the transition. Do not reduce SPLA reporting for a workload until the on-premise infrastructure is physically decommissioned. Not when the migration starts, but when it completes and the old environment is shut down.

Prevent double-licensing during handover. During the migration of each workload, there is a period where both the SPLA-licensed on-premise environment and the CSP-provisioned cloud environment are running simultaneously (for testing, data synchronisation, or gradual cutover). The provider is paying for both during this overlap. Minimise the overlap period for each workload by planning aggressive cutover timelines, and ensure that SPLA reporting is reduced in the month following complete decommissioning of the on-premise environment. Track double-licensing costs explicitly so they can be factored into migration ROI calculations.

Sequence migrations to maximise SPLA reduction. Prioritise migrations that eliminate the most expensive SPLA licensing first. A single physical server running SQL Server Enterprise on 32 cores may cost more in monthly SPLA fees than 50 customer Exchange mailboxes. Identify the SPLA products, servers, and customer deployments with the highest monthly licensing costs and target those for early migration. This front-loads the financial benefit and generates momentum for the remainder of the migration programme.

The financial case for SPLA-to-CSP migration is compelling for most service providers, but it is not uniformly positive across all workloads, all customers, or all time horizons. Rigorous financial modelling prevents unpleasant surprises and enables informed prioritisation.

Infrastructure cost elimination. The largest financial benefit is eliminating the costs of owning and operating physical infrastructure: server hardware (purchase/lease, depreciation), datacentre costs (power, cooling, space, connectivity), hardware maintenance and lifecycle management, and the engineering staff required to manage physical environments. For workloads migrating to Azure PaaS or M365 SaaS, these costs are entirely eliminated. For workloads migrating to Azure IaaS (VMs), the costs shift from capital to operational expenditure. Typical infrastructure cost reductions range from 15 to 40% depending on the workload mix and existing infrastructure efficiency.

SPLA licence cost replacement. SPLA licensing costs are replaced by CSP subscription costs. The per-unit economics vary by product. Microsoft 365 subscriptions may cost more or less per user than the equivalent hosted Exchange plus SharePoint SPLA licensing depending on the M365 plan selected. Azure VM costs may be higher or lower than SPLA plus infrastructure costs depending on VM sizing, reserved instance pricing, and utilisation patterns. Model each workload individually rather than assuming a uniform cost reduction. Some workloads will be cheaper under CSP. Others may cost more on a pure licensing basis but deliver savings through infrastructure elimination.

Margin impact and revenue model changes. The migration fundamentally changes the provider's revenue model. Under SPLA, the provider controlled pricing by marking up SPLA costs plus infrastructure and management fees. Under CSP, the provider resells Microsoft services at Microsoft's pricing (with a modest partner margin) and adds value through management, support, and professional services. Per-customer revenue may decrease, but per-customer costs decrease more, improving margin percentage even if absolute revenue per customer drops. Model both revenue and margin, not just cost, to understand the true financial impact.

Migration investment and payback period. The migration itself requires investment: technical staff time for planning and execution, Azure consumption during testing and parallel running, customer communication and change management, training for operations teams on cloud platforms, and short-term double-licensing costs. Model these migration costs explicitly and calculate the payback period. Typical payback periods range from 6 to 18 months depending on migration scope and existing infrastructure costs.

The SPLA-to-CSP migration directly affects customers. Their services change, their interfaces may change, and their billing certainly changes. How the provider manages customer communication determines whether customers embrace the migration or use it as an opportunity to evaluate competitors.

Frame the migration as a customer benefit. Customers do not care about the provider's licensing programme. They care about their services. Frame the migration in terms of customer outcomes: improved reliability (Microsoft's global infrastructure versus a single datacentre), enhanced features (M365's collaboration tools, Azure's scalability), better security (Microsoft's security investment), and compliance improvements (Azure's regulatory certifications). Avoid leading with licensing terminology, cost savings for the provider, or technical migration details.

Give customers adequate notice and choice. Communicate migration timelines at least 6 months before the planned transition for each customer. Provide options where possible. Some customers may prefer to migrate sooner, others may need more time for internal preparation. Never force a compressed migration timeline on a customer unless there is a genuine technical or contractual deadline. Customers who feel rushed or coerced will look for alternative providers.

Manage pricing transitions transparently. If the migration changes the customer's monthly cost (up or down), communicate this clearly and early. If costs increase for the customer, explain the additional value they receive. If costs decrease, the provider can either pass the savings through (strengthening the customer relationship) or reinvest the margin in additional services. Never surprise a customer with a pricing change at migration time.

The transition period between SPLA and CSP creates specific compliance risks that do not exist when operating purely under either programme.

SPLA reporting must continue until decommissioning. The most common transition compliance failure is reducing SPLA reporting before the on-premise infrastructure is fully decommissioned. If a server is still running, even if it is only serving as a migration source, running in read-only mode, or maintaining a backup copy of data, it requires SPLA licensing. SPLA reporting must continue at full accuracy until the physical or virtual server is shut down and removed from the environment. "We're migrating that workload" is not a valid reason to stop reporting it under SPLA.

SPLA licences cannot transfer to Azure (BYOL). SPLA licences are monthly rental licences, not perpetual entitlements. They cannot be transferred to Azure via Bring Your Own Licence (BYOL). BYOL is available only for perpetual licences purchased under volume licensing programmes (EA, Select, Open) with active Software Assurance. When migrating from SPLA to CSP/Azure, the CSP subscription replaces the SPLA licence entirely. Each migrated workload must be covered by a new CSP subscription from the moment it goes live in the cloud environment.

Customer licence separation. Under SPLA, the service provider holds the licences on behalf of all customers. Under CSP, licences may be assigned at the customer tenant level. During migration, ensure clear separation: each customer's CSP subscriptions must be provisioned in their own tenant (or the provider's multi-tenant CSP structure), with quantities matching their actual requirements. The migration is an opportunity to right-size each customer's licensing based on actual usage rather than historical SPLA allocations.

SPLA contract obligations at termination. When the provider is ready to terminate the SPLA agreement, review the contract for termination provisions. The standard SPLA contract requires 30 days' notice before the anniversary date. Failure to provide timely notice may result in automatic renewal for another year. Some SPLA contracts include minimum commitment clauses or wind-down provisions. Review the contract with legal counsel before initiating termination.

The SPLA-to-CSP migration should follow a structured, phased approach that builds capability and confidence progressively. Attempting to migrate all workloads simultaneously creates unmanageable risk.

Phase 1: Foundation (Months 1 to 3). Establish CSP programme enrolment (direct-bill partner or indirect reseller). Deploy the CSP management platform and billing integration. Train technical and operations teams on Azure, M365 administration, and CSP provisioning. Conduct the workload assessment to categorise every SPLA workload. Build the financial model for each workload and customer. Identify 3 to 5 pilot customers for initial migration. No customer migrations occur in this phase. It is entirely preparation and capability building.

Phase 2: Pilot Migrations (Months 3 to 6). Migrate the pilot customers, starting with the lowest-complexity workloads (typically hosted Exchange to M365). Document the migration process, timing, issues encountered, and customer feedback. Refine migration runbooks based on pilot experience. Begin communicating migration plans to the broader customer base using the pilot customers as reference cases. Verify that SPLA reporting correctly reflects the decommissioned pilot infrastructure. Calculate actual migration costs and compare against the financial model. Adjust projections for subsequent phases based on real data.

Phase 3: Accelerated Migration (Months 6 to 18). Execute migrations in priority order: highest SPLA cost workloads first, followed by willing customers, followed by lower-priority workloads. Run parallel migration streams for different workload types (Exchange migrations running concurrently with SQL Server migrations and RDS-to-AVD transitions). Monitor SPLA costs monthly. They should be declining steadily as workloads migrate. Decommission physical infrastructure as servers are emptied. Renegotiate datacentre commitments if infrastructure footprint is shrinking.

Phase 4: Completion and SPLA Wind-Down (Months 18 to 24). Migrate remaining workloads, including the most complex and resistant customers. For workloads that cannot migrate, decide whether to retain minimal SPLA infrastructure or transition those customers to alternative providers. When all workloads have migrated or been transitioned, decommission all remaining SPLA-licensed infrastructure. Provide SPLA termination notice per the contract terms. Conduct a final SPLA compliance review covering the entire transition period to ensure no reporting gaps exist that could surface in a retrospective audit.

SPLA-to-CSP migrations fail for predictable reasons. Understanding these pitfalls before the migration begins allows the provider to build preventive measures into the migration plan.

Underestimating RDS migration complexity. RDS-to-AVD migrations are significantly more complex than Exchange-to-M365 migrations. Legacy applications, printer mappings, USB device redirection, user profile configurations, and network latency requirements all create migration barriers. Budget 3 to 5 times more time for RDS migrations than Exchange migrations. Conduct thorough application compatibility testing before committing to AVD for each customer.

Dropping SPLA reporting prematurely. Service providers stop reporting SPLA usage for workloads "in migration" before the on-premise infrastructure is decommissioned. Microsoft's SPLA audit rights extend for the duration of the agreement plus a period after termination. Any gap in reporting during the transition is audit exposure. Maintain full SPLA reporting discipline until each server is shut down.

Failing to right-size CSP subscriptions. Providers migrate historical SPLA quantities to CSP without analysing actual usage. A customer with 50 Exchange SALs under SPLA may only need 35 M365 licences based on actual active users. The migration is the ideal moment to right-size, but only if usage analysis is conducted before CSP subscriptions are provisioned. Over-provisioning CSP subscriptions recreates the shelfware problem in a new programme.

Ignoring the margin impact of CSP pricing. CSP partner margins (typically 5 to 15% on M365 subscriptions) are significantly lower than the margins providers earned on SPLA-hosted services (where the provider controlled pricing). If the provider's business model depends on high per-user margins, the migration to CSP requires restructuring the revenue model to include managed services, security add-ons, and professional services that generate margin above the CSP subscription resale.

Neglecting customer communication. Providers execute the technical migration without adequate customer communication, resulting in confusion, support ticket spikes, and customer dissatisfaction. Every customer should receive a migration plan, timeline, expected changes to their experience, and a dedicated contact for migration-related questions.

Attempting to migrate everything at once. Providers set aggressive timelines to eliminate SPLA costs quickly and attempt to migrate all customers and workloads simultaneously. This overwhelms the technical team, degrades migration quality, increases the risk of data loss or service disruption, and creates customer dissatisfaction. The phased approach is slower but dramatically safer and more successful.

Completing the migration is not the end. It is the beginning of a fundamentally different operating model. Service providers that successfully transition from SPLA to CSP must adapt their operations, commercial approach, and value proposition for the cloud-first world.

Continuous licence optimisation. Under CSP, licence management shifts from monthly SPLA reporting to ongoing subscription optimisation. Monitor M365 licence utilisation monthly: identify unused licences (users who have not logged in), over-licensed users (E5 licences for E3-level usage), and opportunities to right-size across the customer base. CSP's flexibility allows monthly adjustments. Use this flexibility actively to keep customer costs optimised and demonstrate ongoing value. Quarterly licence reviews should become a standard part of the managed service offering. See our M365 Licence Optimisation Guide.

Build margin through managed services. CSP subscription resale alone does not generate sufficient margin for a sustainable service provider business. The post-migration revenue model must include managed services layered on top of CSP subscriptions: security management (Defender for Endpoint, Conditional Access, DLP), compliance management (retention policies, eDiscovery), identity management (Entra ID configuration, MFA), backup and disaster recovery (Azure Backup, third-party tools), and ongoing optimisation advisory. These managed services generate 30 to 50% margins compared to 5 to 15% on CSP resale.

Maintain SPLA compliance records. Even after SPLA termination, Microsoft's audit rights may extend for 12 to 24 months. Retain all SPLA reporting records, server inventories, decommissioning documentation, and customer deployment records for at least three years after SPLA termination. These records are the provider's defence if Microsoft initiates a retrospective SPLA audit covering the pre-migration period.

Expand the CSP practice. With SPLA eliminated and cloud operations established, expand the CSP practice to include Azure infrastructure services, Dynamics 365 resale and management, Power Platform solutions, Copilot adoption services, and cross-vendor cloud management. The migration from SPLA to CSP is not an endpoint. It is the foundation for a cloud-first service provider business that grows with customer demand for cloud services.

The SPLA-to-CSP migration sits at the intersection of licensing complexity, operational transformation, and commercial restructuring. Independent advisory provides the expertise to navigate all three dimensions simultaneously.

Migration planning and financial modelling. Redress Compliance conducts comprehensive SPLA-to-CSP readiness assessments: workload categorisation, product mapping, customer readiness evaluation, and detailed financial modelling that compares SPLA plus infrastructure costs against CSP subscription costs for every workload. Our analysis identifies which workloads to migrate first (highest financial impact), which to retain on SPLA (no viable cloud equivalent), and which to retire.

Compliance management during transition. The hybrid SPLA/CSP phase is the highest-risk period for licensing compliance. We manage SPLA reporting accuracy throughout the transition, ensure CSP subscriptions are correctly provisioned for migrated workloads, prevent double-licensing waste, and maintain audit-ready documentation for the entire migration period. Our compliance oversight ensures that the provider does not trade SPLA audit exposure for transition-period compliance gaps.

Complete vendor independence. Redress Compliance has no CSP resale revenue, no Microsoft partner incentives tied to cloud migration, and no commercial interest in whether the provider migrates to CSP, retains SPLA, or adopts a hybrid model. Our recommendations are based entirely on the provider's financial interests and operational requirements. This independence is critical for SPLA-to-CSP decisions, where Microsoft's partner programme and account teams are heavily incentivised to drive cloud migration regardless of whether it serves the provider's interests in every case.

"The SPLA-to-CSP migration is not a licensing swap. It is a fundamental business transformation. Service providers that approach it as a technical exercise underestimate the financial modelling, customer communication, and compliance management required to execute successfully. Those that invest in structured planning, phased implementation, and independent advisory convert the migration from a risk into a competitive advantage."

Related Resources