In previous SPLA-centric blogs, we discussed how Microsoft defines a service provider and what options are available to organizations that are hosting. These articles are great resources for companies interested in pursuing a hosted model, but we have also seen a trend where organizations are providing services and are unaware that they require SPLA licensing. Notwithstanding the potential compliance risk this poses, there are also several other factors which can be significantly disruptive to the business if SPLA becomes an unanticipated requirement. Today we will focus on scenarios that may require a traditional VL customer to use SPLA, and the challenges that SPLA may incur in those scenarios.
M&A, Franchises, Business Associations:
As mentioned in previous posts, Volume Licenses can only be used for internal employees, affiliated organizations, and onsite contractors.
According to the Microsoft Business Services Agreement (MBSA), affiliated organizations include, “any legal entity that a party owns, or is owned by, or that is under common ownership with that party. ‘Ownership’ means, for purposes of this definition, control of more than a 50% interest in an entity.”
Where this creates an issue is if IT services are being provided for any external user or non-affiliated organization (not greater than the 50% owned). If a company divests greater than 50% interest in a business unit but continues to provide IT services, they are no longer permitted to use their Volume Licenses to provide these services.
This equally applies to franchises or business associations where there are perhaps close working relationships, but not the level of ownership required by the affiliate definition. In order to service all of these organizations via single agreement on shared hardware, SPLA is the only option.
MSP’s, ISV’s, Evolving Business models:
MSP’s can encounter SPLA requirements when they:
- Provide any sort of service (monitoring, DB, DR, etc) in a multitenant datacenter environment which they own.
- When they are providing software as part of their services in a subscription based model.
The ISV scenario is specific to organizations who have sold an on-premises solution that they have developed, but now are looking to put it into the cloud
- SPLA is always going to be an option, but there may also be an additional option if your application is licensed through Volume Licensing called Self-Hosted for ISV.
- The Self-Hosted or HISV option has a specific set of parameter that you can view here.
The Unknown Requirement & The Handshake Agreement
The last group we encounter are companies that were not aware of SPLA, or have had some sort of communication whereby it was perceived that they did not require SPLA.
Most all of these companies have proceeded in good faith towards compliance, but if they are in any of the scenarios above or in previous posts, they still may have exposure to a Microsoft audit.
This is equally applicable to any agreements with publishers that are not documented in an official agreement with Microsoft.
SPLA provides flexibility and advantages to those knowingly entering the model. However, if an organization unexpectedly uncovers the requirement in their environment, they need to consider the following:
- SPLA & Volume Licensing require separate hardware: Not only are there potential hidden costs in additional hardware (or 3rd party hosted clouds like Azure) involved, but isolation of an application that is servicing both internal and 3rd party users may prove challenging to separate.
- OpEx vs. CapEx: There is not a programmatic means to recoup Volume License purchases to offset unanticipated SPLA licensing requirements. This also can affect how the services were cost-modeled originally.
- Multiple Agreements, Pricing, & Reporting: By nature, you would be adding another agreement, and since they are separate programs, there is not a means to aggregate your purchasing power to leverage additional discounts between SPLA and VL programs. Additionally, there is the monthly reporting requirement which may need additional resources to ensure accuracy and ongoing compliance.
The adoption of new services and evolution of business IT will also drive changes in licenses entitlements and use rights. The scenarios above are merely representative of trends we have recently noticed that are moving organizations into different programs as their business evolves. The right answers to how to use your licenses and licensing programs to your benefit only come from asking the right questions. I will reference those from our first post, but if you would like to have the conversation to discuss in further detail, click the banner below to schedule an appointment.
Related blog posts: