A primer on SQL server failover licensing

The SQL server ‘passive failover rule’  available under Volume Licensing, would commonly support situations when a primary server suffers a hardware or software failure (or is taken offline for routine maintenance or patch management) and requires the secondary ‘passive’ server to take over completely for ‘temporary’ support, but importantly, without requiring an additional licenses to be assigned to the secondary ‘passive’ server.

For example, common fail-over are included with SQL server, with support for basic high availability with 2 node fail-over clustering and a non-readable secondary instance,  database backup log shopping, or database mirroring.

Under the legacy product-specific licensing terms for SQL server 2008, a standby server that is considered ‘passive’ (and not running any active workloads or reports) would generally not require an additional license to be assigned under Microsoft licensing (this includes back-up and restore related tasks under the passive designation), and would be covered under the licensed ‘active’ primary server.

Similarly, a secondary server, that would be utilized solely to maintain a copy of the database and will never take over from the primary does also fall under the ‘passive’ designation. However, the passive failover server rule will only support a single designated passive server under the allowance for each primary licensed server.

The SQL server ‘passive failover rule’ is an important licensing exception, and a principle driver of cost reduction in SQL licensing, but as Microsoft have sought to evolve their commercial licensing model to drive revenue growth, and incentivise customer purchasing behaviours to secure ongoing predictable revenue through their ‘Software Assurance’ maintenance model, the licensing has evolved incrementally since 2008 to curtail this licensing exception. This article charts the evolution of Software Assurance (SA) and the curtailment of the failover benefit to drive that revenue growth, and respond to emerging technologies.

The Product Use Rights for SQL Server 2008

As an extract below, from the Product Use Rights (published in July 2010, Page 63 of 136) (the first PUR document after SQL server 2008 R2 general availability) explained the passive failover licensing exception as follows:

“Fail-over Servers. For any operating system environment in which you run instances of the server software, you may run up to the same number of passive fail-over instances in a separate operating system environment for temporary support […]  You may run the passive fail-over instances on a server other than the licensed server.”).

Similarly, illustrated in an extract below, (published in January 2012, Page 58 of 147) the last archived product use rights document for SQL server 2008 R2 before general availability (GA) of SQL server 2012, used almost identical wording and explains the exception as follows:

“For any OSE in which you run instances of the server software, you may run up to the same number of passive fail-over instances in a separate OSE for temporary support […] You may run the passive fail-over instances on a server other than the licensed server.”

The principle licensing tenet established that a licensed primary instance could be supported by an unlicensed passive instance.

This approach was similarly maintained upon general availability of SQL server 2012, and did not appear to explicitly indicate a change in the passive failover server rule.

“Fail-Over Rights […] For any OSE in which you use Running Instances of the server software, you may use up to the same number of passive fail-over Running Instances in a separate OSE on any Server for temporary support.“

[Ref: Product Use Rights, January 2014, Page 37]

Microsoft Published Guidance for SQL Server 2008

Microsoft provided a guidance document, originally published way back in July 2008,  that provided a good insight into the principle logic of server ‘failover rights’, with an extract here as follows:

“When doing failover support, a server is designated as the passive server. The purpose of the passive server is to absorb the data and information held in another server that fails. A passive server does not need a license, provided that the number of processors in the passive server is equal or less than those of the active server. The passive server can take the duties of the active server for 30 days. Afterward, it must be licensed accordingly

[Ref: SQL Server 2008 Pricing and Licensing, July 2008, Page 2 of 5]

The wording of the Product Use Rights and prior published guidance, (published in July 2008),  support interpretation of  the passive failover server rule as actually two separate but ultimately connected allowances under the primary perpetual license.

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. The passive instances can be used ‘for temporary support’, (with restrictions)

Operational Logic for SQL Server 2008

Accordingly, the following general principles were established when assessing licensing requirements for passive failover:

  1. There can only one unlicensed passive SQL server for every active SQL server,
  2. The licenses assigned to the primary must be sufficient to cover the secondary,
  3. Passive servers do not require licenses to be assigned, but are unable to run any production workloads, but backup and restore related tasks are an important exception.
  4. When database mirroring, the secondary server cannot provide reporting functions.
  5. The backup server can take over during a failure or system maintenance, i.e. hardware or software failure, or routine system maintenance.
  6. The duration of the failover event is for ‘temporary support’, this is commonly interpreted as 30 days.
  7. The server cannot be sequestered for short-term transaction load-balancing.
  8. The passive node must takeover completely, no production workloads must remain, (so all databases must move together for database mirroring or log shipping), both active and passive nodes cannot be in an active production capacity.

The incremental expansion of Software Assurance for SQL Server 2012

Microsoft Volume Licensing eventually communicated a change of how the operational logic of a failover event is conceptually approached, this was later addressed in non-binding advisory guidance 16 months after general availability, this was first presented via the popular TechNet  blog; under the following statement:

“[…] You do not require SA for SQL Server Fail-over Rights, but once you activate the Passive Fail-Over server in a DR then that Passive Fail-over becomes the active server (during a fail-over event) and it must be fully licensed for SQL Server.  You can accomplish this by assigning new licenses to the (now active) passive server, or by reassigning existing licenses from the primary server to the backup server once the instances of SQL Server on the primary server are inactive and no longer performing SQL Server workloads.”

[Ref: This was originally published on the TechNet website, formerly available at: https://blogs.technet.microsoft.com/b/volume-licensing/archive/2013/08/22/licensing-how-to-sql-server-fail-over-vs-cold-disaster-recovery-rights.aspx]

Wherein, Microsoft once admitted “What this means is that your SQL Server 2012 licenses without SA may only be reassigned once every 90 days.  This may not fit your fail-over strategy very well.”

The non-binding advisory content published by Microsoft on the TechNet blog, indicated that under the software use terms for SQL server 2012, during a failover event the primary licensed server would need to have the license reassigned to the passive server at point of failover. The legacy approach, to license only the ‘active’ node of an active-passive SQL server cluster seems to have been curtailed as an extended use right, and would markedly depart from the license precedent of product-specific licensing terms for SQL server 2008 and 2008 R2.

The change in precedent was not explicitly referenced in the first non-binding advisory licensing guide document published two months after general availability in June 2012, and matched the operating logic of former releases:

“The secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups being made from secondary servers, then it must be licensed for SQL Server”.

“Primary server licenses include support for one secondary server only, and any additional secondary servers must be licensed for SQL Server. Note: The rights to run a passive instance of SQL Server for temporary support are not transferable to other licensed servers for purposes of providing multiple passive secondary servers to a single primary server.”

“When licensing SQL Server 2012 under the Per Core model, the number of core licenses must be based on the server that requires the higher number of licenses. This way, when the failover server takes over, it is adequately licensed. For a passive instance of SQL Server to be properly licensed, it cannot require more core licenses than the licensed primary system”

[Ref: SQL Server Licensing Guide, June 2012, Page 14 of 25]

To explore this nuanced change in wording a little further, in the non-binding published literature I have included the later amended SQL Licensing Guide, published in  March 1st 2013, with the Page 15 extract in full, which formally cemented the expansion of Software Assurance for SQL server 2012:

“Failover Basics / For each properly licensed instance of SQL Server, customers can run a supporting passive instance in a separate OSE for temporary support—that is, to synchronize with the primary server and otherwise maintain the passive database instance in a warm standby state in order to minimize downtime due to hardware or software failure.

A passive SQL Server instance is one that is not serving SQL Server data to clients or running active SQL Server workloads. This passive failover instance can run on a server other than the licensed server.

The secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups being made from secondary servers, then it must be licensed for SQL Server.

Primary server licenses include support for one secondary server only, and any additional secondary servers must be licensed for SQL Server.

•Note: The rights to run a passive instance of SQL Server for temporary support are not transferable to other licensed servers for purposes of providing multiple passive secondary servers to a single primary server.

•When licensing SQL Server 2012 under the Per Core model, the number of core licenses must be based on the server that requires the higher number of licenses. This way, when the failover server takes over, it is adequately licensed. For a passive instance of SQL Server to be properly licensed, it cannot require more core licenses than the licensed primary system.

•In the event that a passive instance of SQL Server becomes active for any reason, then it must be fully licensed accordingly. This can be accomplished by assigning new licenses to the (now active) secondary server, or by reassigning existing licenses from the primary server (once the primary instances are inactive and no longer performing SQL Server workloads). License Mobility, a Software Assurance (SA) benefit, may allow for more flexibility with license reassignment. For details on reassignment considerations without SA, refer to the Licensing SQL Server for Application Mobility section of this guide.”

[Ref: SQL Server 2012 Licensing Reference Guide, March 1st 2013, Page 15]

The evolution of Software Assurance

Any conflict in interpretation, and likely the crux of the matter, could likely be dependent on interpretation of  the latter evolution of “fail-over rights” for SQL server 2012 as the following core operational logic delineated as follows:

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. The passive instances can be used ‘for temporary support’ i.e. 30 days (with restrictions).
  3. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server.

The emergence of the new wording would interpret the passive failover server rule as limited to an allowance under the primary licensed server to run a secondary passive failover server under the ‘passive’ designation, but importantly, at point of failover and the secondary passive failover taking over completely, the license on the assigned primary licensed server is required to be re-assigned.

This much later non-binding interpretation of fail-over rights in the published content, would later have a real impact for  organisations that adopt a 30 day patching cycle and would underwrite an even stronger case for maintaining active Software Assurance (SA) for organisations seeking to enable ‘license mobility within server farms’ to allow re-assignment of SQL Licenses ‘as often as needed’ outside of the restrictive ‘90 rule’.

“Customer may reassign a License to another device or user, but not less than 90 days since the last reassignment of that same License, unless the reassignment is due to (i) permanent hardware failure or loss”.

[Ref: Microsoft Product Terms, April 2019, Page 7 of 115]

The ’90 day rule’ is a license re-assignment restriction that will limit re-assignment of a server license under Volume Licensing more than once in a 90 day period. This will apply to Windows Server, but also will apply to SQL server. The operational logic of affecting license re-assignment at point-of-failover, was to orchestrate the application of the ’90 day rule’ to the passive ‘fail-over right’ for SQL server, and curtail customer’s from electing to have SA lapse, or omit SA at time of purchase.

This was compounded by the previous curtailment of SQL Enterprise Edition ‘license mobility’ in the updated 2012 licensing schema as requiring active Software Assurance to support dynamic re-assignment of a license, rather than enshrined within the perpetual license itself. The evolution of Software Assurance for SQL server as critical for dynamic high availability environments, and the evolution in the operational logic of the passive fail-over rule has had a material impact in creating customer ‘lock in’.

Cementing the role of Software Assurance with SQL Server 2014

Formerly, the SQL server license was assigned to the primary active server, and the primary instance would failover from the active to the passive secondary server for ‘temporary support’, without re-assigning the license from the active to the passive secondary server. Once the failed active server was restored,  the operating logic would support the customer to  switch back from the secondary to the restored active server at any time. It emerged, incrementally with SQL server 2012, that a customer would not need another license for the passive server, however under the 90 day re-assignment rule, the customer was not free to switch from the active primary to the passive sever, and back the restored primary within 90 days. It established the operating logic that a license is re-assigned at point of failover and that without active SA, it would limit ‘license mobility’ to re-assign the license again within 90 days and support dynamic virtual environments.

Later with the release of SQL server 2014, the curtailment of perpetual license rights to install and run the passive SQL server was granted through the new ‘Fail-over Server’ Software Assurance benefit.

Under the SQL server 2014 Product Use Rights, in order to utilize this benefit, you must comply with the following terms:

“Maintain Software Assurance coverage on the server licenses and core licenses under which you run your licensed software and for all CALs under which you access your licensed software.

Your right to run the passive fail-over instances ends when your Software Assurance coverage ends.

Fail-over server rights do not apply in the case of software moved to shared third party servers under License Mobility through Software Assurance.”

[Ref: Microsoft Product Use Rights, April 2014, Page 73]

This incremental evolution in wording was important, in that it enshrined the failover right as a benefit of Software Assurance and not of the perpetual license, with the following update to the operational logic:

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server.
  3. The passive instance is a benefit of Software Assurance.

SQL server 2014 also later established passive failover within the public cloud as a Software Assurance benefit.

Notably, it was later in December 2015, published in the Microsoft Product Terms, that Microsoft introduced fail-over rights for use on shared third party servers.”For Products that are also granted Fail-Over Rights, Customer may run passive fail-over Instances on the qualifying shared servers in anticipation of a fail-over event. The number of licenses that otherwise would be required to run the passive fail-over Instances must not exceed the number of licenses required to run the corresponding production Instances on the same partner’s shared servers“. [Ref: Microsoft Product Terms, December 2015, Page 82 of 91]. This wording would indicate that, if the licensed primary active instance is on  shared tenancy servers, the passive instance is also required to run on shared tenancy servers with he same provider. Similarly, If the licensed primary active instance is on a dedicated host, the passive instance is also required to run on dedicated hardware. Please be aware that Microsoft does not intend the failover use right to be used for on-premises to 3rdparty shared tenancy failover.

Microsoft positioned the licensing changes for SQL server 2014 as a positive evolution in the licensing model, combining it with ‘License Mobility within a Server Farm’ Software Assurance benefit, to enable their customers address the ‘big gap’ customers had with the 90 day license reassignment rule, wherein they had to maintain the secondary server for 90 days, before they could fail back to the primary active server after a failover event. However, as illustrated in this article, it is a fascinating orchestrated evolution of the commercial model over many years, underwriting double-digit growth and setting the foundation for Azure.

Setting the stage for Azure

The binding failover definition of the Product Terms does initially appear to provide Microsoft with a strong curtailment of the benefit for shared server environments:

Fail-Over Rights:  An SA benefit that allows Customer to run passive fail-over Instances of the Product in conjunction with software running on the Licensed Server, in anticipation of a fail-over event. Passive fail-over Instances may be run in either a separate OSE on the Licensed Server or on a different Server dedicated to Customer’s use. Fail-Over Rights apply only if the number of licenses that otherwise would be required to run the passive fail-over Instances does not exceed the number of licenses required to run the corresponding production Instances. This SA benefit requires SA for the License Server and access license, if any. [Ref: Microsoft Product Terms, April 2019, Page 71]

Microsoft did not limit the fail-over use right to only dedicated hardware alone, and ensured the failover benefit was also additive to the Azure Hybrid Benefit for SQL Server,  similar wording was maintained inclusive of ‘shared servers’, as illustrated below, and taken from the same document:

“For Products that are also granted Fail-Over Rights, Customer may run passive fail-over Instances on the qualifying shared servers in anticipation of a fail-over event. The number of licenses that otherwise would be required to run the passive fail-over Instances must not exceed the number of licenses required to run the corresponding production Instances on the same partner’s shared servers.” [Ref: Microsoft Product Terms, April 2019, Page 88]

This was echoed, in the SQL Server 2016 Licensing Guide, June 2016,

primary database running on shared hardware in the cloud, you may run the same number of passive SQL Server instances in a seperate OSE running in the cloud on shared hardware to support failover events” [Ref: SQL Server 2016 Licensing Guide, June 2016, Page 22 of 31].

This extends the operational logic for cloud hosting scenarios, with the following principles:

  • Microsoft confer that , without Software Assurance, both active and passive servers within the cloud environment are licensed.
  • If Software Assurance is maintained, and the active primary is on dedicated hardware, the passive is required to be on dedicated hardware with the same partner.
  • Similarly, if the active primary is on shared tenancy servers in a public cloud environment, the passive failover server is also required to be on shared tenancy servers with the same partner.
  • Microsoft curtail using your third-party cloud  provider as the fail-over destination from on-premises.  You are restricted from deploying SQL Server with active SA on-premises to extend the passive fail-over to a third-party data center. Setting the stage for Azure, aligned with the Azure Hybrid Benefit.

Fail-over under SPLA

A key consideration for this extended use right under SPLA, is also on the interpretation of “fail-over right”as only a limited allowance under the primary licensed server, to run a secondary passive failover server under the ‘passive’ designation “in anticipation of a fail-over event”.

Fail-Over Rights: Permits Customer to run passive fail-over Instances of the Product in conjunction with software running on the Licensed Server, in anticipation of a fail-over event. Passive fail-over Instances may be run in either a separate OSE on the Licensed Server or on a different Server dedicated to Customer’s use. Fail-Over Rights apply only if the number of Licenses that otherwise would be required to run the passive fail-over Instances does not exceed the number of Licenses required to run the corresponding production Instances.”

[Ref: Service Provider Use Rights, April 2019, Page 31 of 33]

(Note: under the Service Provider Licensing Agreement, Microsoft confirm that “Customer” means the SPLA Provider, the entity that entered into the SPLA agreement with Microsoft.)

Importantly, at point-of-failover should the secondary passive failover takeover, the license on the assigned primary licensed server is required to be re-assigned, or a new license assigned to the secondary server.

The Service Provider or Data Center Provider, is free to switch from the active primary to the passive sever, and back the restored primary “within the same calendar month”under SPLA, subject to the “License Mobility” eligibility for SQL Server in the Service Provider Use Rights.

License Assignment and Reassignment

Before Customer uses software under a License, it must assign that License to a device or user, as appropriate. Customer may reassign a License to another device or user, but not during the same calendar month, unless the reassignment is due to (i) permanent hardware failure or loss, or (ii) temporary reallocation of SALs to cover a user’s absence or the unavailability of a device that is out of service. Customer must remove the software or block access from the former device or to the former user.

[Ref: Service Provider Use Rights, April 2019, Page 5 of 33]

License Mobility: Permits License reassignment from one of Customer’s Servers to another one of Customer’s Servers in the same Server Farm during the same calendar month.

[Ref: Service Provider Use Rights, April 2019, Page 31 of 33]

License Mobility (within Server Farms) is a an extended use right available under the Service Provider Use Rights to re-assign licenses for eligible server products without being bound by the general re-assignment restriction in the Universal License Terms.

The author highlights that this should be distinguished from “License Mobility through SA” available under Volume Licensing that enables end-customers to ‘bring their own licensing’ to third-party shared server environments.

Accordingly, the operational logic for fail-over under SPLA is as follows,

  1. Confirm that the secondary instance meets the requirements of “running instance”, or,
  2. Under the “Fail-Over Right” running instances are classified as passive instances, in a separate server, or in a different OSE on the same physical server.
  3. The passive instances are for use only ‘in anticipation of a fail-over event’
  4. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server, or a new license assigned.
  5. License Mobility (within Server Farms) enables specific products licenses to be re-assigned within the calendar month. This does apply to SQL Server Core Editions under the Service Provider Use Rights.
  6. The general license re-assignment restriction under the Universal License Terms,  also does not apply for “permanent hardware failure, or loss”

SQL Server Failover Checklist

  1. A server is designated ‘active’, for implementations including a (readable) read-write database or instance, or primary replica.
  2. A server is designated ‘passive’ for the write-only database or instance, marked as non-readable secondary replica.
  3. The required SQL server core licenses are assigned to the individual VM, or individual container and “are considered the same from a licensing perspective”
  4. There can only one unlicensed passive SQL server, for every active SQL server,
  5. The licenses assigned to the primary must be sufficient to cover the secondary,
  6. Passive servers do not require licenses to be assigned, but are unable to run any production workloads, and cannot be marked readable, serve data such as reports to clients, or perform additional backups,
  7. The ‘passive’ instance does not need a license to be assigned to perform backup and restore related tasks only to synchronize with the primary server, and maintain a passive database instance in a ‘warm standby state’
  8. When database mirroring, the secondary server cannot provide reporting functions,
  9. The backup server can take over during a failure, i.e. hardware or software failure, or routine system maintenance
  10. The server cannot be sequestered for short-term transaction and backup load-balancing, to improve performance of the primary,
  11. The passive node must takeover completely. For example, with database mirroring or log shipping, all databases should move together, and no production instances must remain on the primary. If some databases continue to operating on the primary while the remainder are moved to standby, the standby would not be eligible under the passive fail-over right.

The following table captures some useful information when assessing the impact of high availability (HA) implementations, comparing basic availability groups and advanced ‘Always On’ Availability Groups,

Basic Availability Group Advanced  – Always On Availability Group

with Windows Server Failover Cluster (WSFC).

Two replicas (a primary replica and secondary replica). Supported with Standard Edition Two synchronous, and six Asynchronous replicas, each of which hosts a set of secondary databases and serves as a potential failover targets for the availability group. Supported with Enterprise Edition 
No read  (write-only) access on the secondary replica satisfies the ‘passive’ exception eligibility and no license is assigned in anticipation of a fail-over event.

The secondary replica cannot be used to run backup, reporting, or checkdb.

Support to mark the secondary replica as readable.This will enable reporting queries, backup on secondary replicas, and checkdb.

This is ‘active’ under the failover exception and would require a license to be assigned.

The secondary replica is not readable, and subsequent backup is not possible. If marked as read-only, ‘copy only’ backup is supported to a secondary replica
Two nodes, single database failover, with non-readable secondary. A multi-node, multi-database failover, with a minimum configuration of three SQL servers, and a required minimum of two SQL servers to be licensed appropriately with Enterprise Edition.
All Standard Features

Basic Adaptive Query Processing Only

+ Enterprise Features, including but not limited to: Enterprise Data Management (Data Quality Services, Master Data Services), Advanced Adaptive Batch Query Processing (Batch Mode Memory Grant Feedback, Batch Mode Adaptive Joins), Advanced Security with Transparent Data Encryption, Advanced BI (with tabular model, direct query, and in-memory analytics), Advanced R and Python integration (GPUs with parallel computing via Machine Learning Services)

The operational logic for the fail-over right is as follows:

  1. A right to have running instances that meet the eligibility requirements of passive instances, with active SA.
  2. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server, or a new license assigned.
  3. The license can be re-assigned dynamically at point-of-failover, with active SA, within the same server farm.
  • You can move licensed software from shared servers back to on-premises, or to another party’s shared servers, but not on a short term basis (not within 90 days of the last assignment). This also applies if the licenses need to be re-assigned to another ‘server farm’ that is more than 4 time-zone hours away (except if in the EU or EFTA region).
    • Accordingly, there is no flexibility to dynamically re-assign licenses with workloads across multiple cloud environments in a multi-cloud strategy, or across globally distributed data centers.

[Ref: Microsoft Product Terms, May 2019, Page 75, 88 of 116]

The operational logic for fail-over right for cloud hosting scenarios, is as follows:

  • Without Software Assurance, both active and passive servers within the cloud environment are licensed.
  • If Software Assurance is maintained, and the active primary is on dedicated hardware, the passive is required to be on dedicated hardware.
  • Similarly, if the active primary is on shared tenancy servers in a public cloud environment, the passive failover server is also required to be on shared tenancy servers with the same partner.
  • Microsoft curtail using a third-party cloud provider as the fail-over destination from on-premises.  You are restricted from deploying SQL Server with active SA on-premises to extend the passive fail-over to a third-party cloud provider.

[Ref: SQL Server 2017 Licensing Guide, Page 26 of 36]

Final Thoughts

The published guidance on the requirements for Software Assurance would be a subtle, but significant change to how the fail-over rights in the Product Use Rights were interpreted by Microsoft and its subsidiaries for many years. The incremental evolution of SQL server licensing reiterates my  strong recommendation to refer to all binding-documentation, rather than relying solely on non-binding advisory documentation (even Microsoft’s own websites and blogs). While the correct interpretation is commonly shared by experienced licensing professionals, trainers and Microsoft licensing executives, it is valuable to always look directly at all relevant binding (and non-binding) documentation to ascertain the true impact to how the license version, and the role of Software Assurance can impact architecture choices.

The SQL server ‘passive failover rule’ was, and remains, an important licensing exception, and still to some extent, a principle driver of cost reduction in SQL licensing, but as illustrated in this article, as Microsoft has sought to evolve their commercial licensing model to drive revenue growth, and customer purchasing behaviours to secure ongoing predictable revenue through maintaining customers in ‘Software Assurance’, the value of the perpetual licensing asset has been curtailed.

Thanks All


About

This website is a way to give back to the licensing community and as an information resource for all customers that work with Microsoft software and licensing. I hope you find it of value.

Tony Mackelworth is Head of Microsoft Advisory Services at SoftwareONE

If you would like to reach out for a coffee or a meeting under NDA, Email or connect via Twitter or LinkedIn

Copyright – Softspend Limited 2019. All Rights Reserved.