The migration from Microsoft’s Services Provider Licence Agreement (SPLA) to the Cloud Solution Provider (CSP) programme is one of the most consequential business transformations a service provider can undertake. It changes how Microsoft software is licensed, how services are delivered, how customers are billed, and how the provider’s entire operational model functions. Done well, the migration reduces infrastructure costs, eliminates SPLA audit risk, and positions the provider for growth in a cloud-first market. Done poorly, it destroys margin, creates compliance gaps during the transition, and alienates customers who depended on the provider’s on-premise hosting capabilities. This guide provides a complete framework for assessing migration readiness, mapping SPLA workloads to CSP equivalents, designing hybrid architectures for the transition period, modelling the financial impact, managing customer relationships through the change, and maintaining compliance throughout every phase of the migration.
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. Understanding these drivers is essential for building a migration business case and setting realistic expectations for the transition.
Microsoft is actively steering service providers towards CSP. The company has incrementally increased SPLA pricing, reduced the product catalogue available under SPLA, and invested heavily in CSP partner incentives that reward cloud service delivery. Microsoft’s long-term strategy is clear: SPLA serves a shrinking segment of on-premise hosting, while CSP aligns with Microsoft’s cloud-first commercial model. Service providers that delay migration risk finding themselves on an increasingly expensive, increasingly constrained licensing programme.
At the same time, customers are demanding cloud-delivered services. The enterprise market has shifted decisively towards SaaS productivity (Microsoft 365 replacing hosted Exchange and SharePoint), cloud infrastructure (Azure replacing dedicated hosting), and managed cloud services (Azure-based platforms replacing SPLA-hosted environments). Service providers that cannot deliver these cloud services through CSP are losing customers to competitors that can.
Microsoft has increased SPLA pricing consistently over recent years, with annual increases of 5–10% on key products (Windows Server, SQL Server, RDS). These increases compound: a product that cost USD 100/month per core five years ago may now cost USD 130–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 is one of the most frequently audited Microsoft programmes, and 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.
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.
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.
Inventory every workload running under SPLA and classify it into one of four categories. Migrate: workloads with direct CSP/cloud equivalents (hosted Exchange → Microsoft 365, hosted SharePoint → SharePoint Online, basic Windows hosting → Azure VMs). Refactor: workloads that can move to cloud but require architectural changes (custom SQL Server applications → Azure SQL, RDS-hosted desktops → 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.
Every customer has different migration readiness. Some are actively requesting cloud services and will welcome the transition. Others are satisfied with on-premise hosting and may resist change. 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.
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 where revenue per customer may decrease but operational costs also decrease?), 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 during the migration 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. Understanding these mappings is the foundation of migration planning.
| SPLA Product | CSP Equivalent | Migration Complexity | Key Considerations |
|---|---|---|---|
| Hosted Exchange Server | Microsoft 365 (Exchange Online) | Low–Medium | Mailbox migration, DNS cutover, archive/retention policies, third-party integrations |
| Hosted SharePoint Server | SharePoint Online (via M365) | Medium | Custom workflows, InfoPath forms, on-prem integrations, large file libraries |
| Remote Desktop Services (RDS) | Azure Virtual Desktop (AVD) or Windows 365 | Medium–High | Application compatibility, user profile migration, printing, peripheral support |
| Windows Server (IaaS hosting) | Azure VMs (IaaS) via CSP | Medium | VM sizing, networking, storage performance, hybrid connectivity |
| SQL Server (hosted databases) | Azure SQL Database, Azure SQL MI, or SQL on Azure VMs | Medium–High | Compatibility level, features used, performance tier, data residency |
| System Center | Azure Arc, Azure Monitor, Microsoft Intune | High | Management tooling replacement, monitoring migration, policy reconfiguration |
| Skype for Business Server | Microsoft Teams (via M365) | Medium | Voice/telephony migration, PSTN connectivity, meeting room devices |
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–4 weeks per customer.
Remote Desktop Services hosted under SPLA represents the most technically complex migration. Azure Virtual Desktop (AVD) 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–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 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), or 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.
No service provider completes an SPLA-to-CSP migration overnight. The transition period — typically 12–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.
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.
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.
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 — both financially and organisationally — for the remainder of the migration programme.
During the hybrid phase, the provider effectively operates two businesses: an on-premise hosting business (SPLA-licensed) and a cloud services business (CSP-delivered). Each requires its own operational processes, billing systems, support workflows, and compliance management. Attempting to manage both through a single undifferentiated operations team creates confusion, compliance errors, and customer service failures. Establish clear ownership for each stream, with defined handover processes for workloads transitioning from SPLA to CSP.
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.
The largest financial benefit of migration 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–40% depending on the workload mix and existing infrastructure efficiency.
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 + SharePoint SPLA licensing depending on the M365 plan selected. Azure VM costs may be higher or lower than SPLA + 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.
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.
The migration itself requires investment: technical staff time for planning and execution, potential Azure consumption during testing and parallel running, customer communication and change management, training for operations teams on cloud platforms, and possible short-term double-licensing costs. Model these migration costs explicitly and calculate the payback period — the point at which cumulative cost savings from eliminated SPLA and infrastructure costs exceed the migration investment. Typical payback periods range from 6–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 through this transition determines whether customers embrace the migration or use it as an opportunity to evaluate competitors.
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 vs 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. The customer narrative should be about service improvement, not provider operational changes.
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. Build migration schedules collaboratively with each customer, respecting their change management processes and business cycles.
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 (enhanced features, improved SLA, reduced risk). 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 — pricing discussions should be completed and agreed well before the technical migration begins.
The transition period between SPLA and CSP creates specific compliance risks that do not exist when operating purely under either programme. Understanding and managing these risks is essential for avoiding audit exposure during the migration.
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.
Some SPLA-licensed products have licence mobility rights that may apply during migration. However, SPLA licences are fundamentally different from volume licences — they are monthly rental licences, not perpetual entitlements. SPLA licences cannot be “moved” to Azure via Bring Your Own Licence (BYOL) in the same way that EA or volume licences can. The CSP subscription replaces the SPLA licence entirely; it does not convert or transfer. Ensure that every workload migrated to Azure or M365 is properly covered by the appropriate CSP subscription from the moment it goes live in the cloud environment.
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. Do not assume that aggregate SPLA quantities translate directly to CSP quantities — the migration is an opportunity to right-size each customer’s licensing based on actual usage rather than historical SPLA allocations.
When the provider is ready to terminate the SPLA agreement (after all workloads have migrated), review the SPLA 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. Additionally, some SPLA contracts include minimum commitment clauses or wind-down provisions. Review the contract with legal counsel before initiating termination to avoid unexpected obligations.
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. The following framework is designed for service providers with 50+ customers and mixed workload portfolios.
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 described in Section 2 to categorise every SPLA workload. Build the financial model for each workload and customer. Identify 3–5 pilot customers for initial migration. No customer migrations occur in this phase — it is entirely preparation and capability building.
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.
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. Continue SPLA reporting with full accuracy for all remaining workloads.
Migrate remaining workloads, including the most complex and resistant customers. For workloads that cannot migrate (legacy applications, regulatory constraints), 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.
A mid-size MSP with 120 customers, 85 hosted Exchange deployments, 45 hosted SQL Server databases, 30 RDS environments, and 200+ Windows Server instances under SPLA executed a phased migration over 20 months. Phase 1 (3 months): CSP enrolment, team training, workload assessment. Phase 2 (3 months): 8 pilot customers migrated (Exchange to M365). Phase 3 (12 months): 95 Exchange migrations, 35 SQL Server migrations to Azure SQL MI, 20 RDS-to-AVD migrations. Phase 4 (2 months): remaining 12 Exchange, 10 SQL Server, 10 RDS migrations; 5 customers with legacy applications retained on minimal SPLA infrastructure.
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.
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.
Under CSP, licence management shifts from monthly SPLA reporting to ongoing subscription optimisation. Monitor M365 licence utilisation monthly: identify unused licences (users who haven’t 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.
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–50% margins compared to 5–15% on CSP resale.
Even after SPLA termination, Microsoft’s audit rights may extend for a period (typically 12–24 months after the agreement ends, depending on contract terms). 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. Complete, accurate records demonstrate compliance throughout the transition.
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 — reducing migration risk, optimising financial outcomes, and maintaining compliance throughout the transition.
Redress Compliance conducts comprehensive SPLA-to-CSP readiness assessments: workload categorisation, product mapping, customer readiness evaluation, and detailed financial modelling that compares SPLA + 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. The financial model provides the data needed for migration business case approval and investment prioritisation.
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 that could surface in retrospective audits.
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 — eliminating SPLA audit exposure, reducing infrastructure costs by 15–40%, and positioning themselves for growth in a cloud-first market.”
Redress Compliance delivers independent advisory for service providers navigating the SPLA-to-CSP transition — workload assessment, financial modelling, migration planning, compliance management during the hybrid phase, SPLA audit defence, and strategic guidance on the optimal licensing structure for your hosting business. Complete vendor independence.