The pace of movement towards cloud based service solutions seems to be unrelenting, and encompasses solutions of increasing value and criticality. There is accordingly a lot more discussion and negotiation concerning the contract terms which would govern such services. However, whilst much attention will understandably focus upon important themes such as changes to the services descriptions, termination and suspension rights and remedies/liabilities, it is important not to miss certain other less obvious issues, which can otherwise have an unexpected (and potentially somewhat uncomfortable) impact.
The Customer’s Legacy Infrastructure
If the Customer is moving to an IaaS or PaaS model for the time being, it will likely have IT infrastructure of its own which it will no longer then require. In some cases, this may encompass entire data centres. Much if not all of this kit will not yet have been fully depreciated, such that there will be a substantial value left on the Customer’s books, and which would constitute an additional “hit” for the Customer’s balance sheet if it were simply to be written off.
In some cases, the parties may seek to use a bit of financial engineering via the charges provisions in their contract, so as to help mitigate the impact of this. Under such a model, the Supplier might acquire the legacy infrastructure so as to cover its depreciated value, on the basis that it will then recover its payment on an amortised basis over the duration of the contract term. Whilst this may appear to be an elegant solution (at least insofar as the overall financials of the deal will support it), there is a potential problem in that the disposal of the assets to the Supplier may be viewed as a sale, in respect of which VAT will apply. The supplier will then in turn wish to pass the impact of that VAT back to the Customer in the course of recovering its amortised costs… at which point, VAT will be applied again (i.e. such that the Customer ends up paying two lots of VAT).
The parties may seek to avoid this impact by avoiding a transfer of ownership, and simply providing that the Customer will provide the Supplier with an exclusive right of use of the associated hardware… in return for which there is then simply a reduction in the amount of the charges in an amount which is not dissimilar from the remaining book value of them.
Impact on Existing Personnel, and the Position on Exit
In the context of a traditional infrastructure outsourcing agreement, there would inevitably be a consideration of staff transfers under TUPE/ARD, whether that be in relation to the employees of the Customer or any of its incumbent providers. It may be thought that such considerations would not apply in the context of a shift into the cloud, if the Supplier argues that it is not then taking on any undertaking of the Customer’s, and is instead providing a service (often of a “commodity” nature), and in a manner which is quite different to how the Customer may have historically operated.
This may well be true, and the underlying contracts may then also contain “wrong pocket” indemnity provisions, whereby the Supplier gets the protection of indemnities vs pre-existing claims if – contrary to any intentions of the parties – certain employees are in fact able to assert a right of transfer to the Customer. However, if we assume that the employees in question do NOT transfer, there is then the question of what will happen to them once the cloud services kick in. In the ideal world, they would be able to be transferred to other roles or re-skilled, but the bigger the cloud transformation/migration, the more people will be affected, and the less likely it will be that they can all be accommodated in such a fashion. In that event, the Customer will need to factor potential redundancy costs into its financial model for the move to the cloud.
There is then the position on exit to consider. If the Customer shifts from one Supplier to another cloud based service provider, there may very well then be a case for seeing that transfer of responsibility as concerning an “undertaking” (albeit a cloud based one), such that TUPE/ARD might then apply. In such cases – and as we have seen in the outsourcing market – the incoming service provider will likely push for the Customer to provide it with indemnity protections, and the Customer will only be in a position to safely do so if it remembered to “future proof” its contract with the Supplier at the outset, by ensuring that it included indemnities vs such liabilities in relation to the Supplier’s employees and those of its subcontractors. If you look at many (if not most) of the standard contracts of cloud service providers, you will NOT find such protections, however.
Dealing with Demand Management
One of the considerable attractions of cloud services – and in particular for IaaS and PaaS variants – is the speed of deployment. In these days of digital transformation where speed is everything and there is wide spread adoption of DevOps/Agile methodologies, it is crucial that additional IT capacity can be made available as quickly as possible, and without lengthy discussions with internal IT functions as to whether there is sufficient contiguous space available at the Customer’s data centre to host additional server capacity, and how long it will take to procure and configure additional servers. Typically, it is then very easy for the Customer to commission additional capacity and for it to be made available for use, frequently via “self-service” portals which may be directly accessible by business users within the Customer organisation.
This has obvious advantages in terms of speed and convenience. However, it also hides a considerable risk. In the “traditional” world, the Customer’s IT function would at least have an opportunity to review requests for new capacity and determine whether those needs might be capable of being met in different ways (e.g. if equipment had already been acquired for a different project, but where that project had then be delayed or ditched, such that it was now available for use elsewhere). If, however, the Customer’s users can simply commission new capacity/services via a portal or similar, then there is no such control or demand management. We then face what might be termed the “drunk man at the bar” syndrome, i.e. whereby the Customer’s users keep approaching the Supplier for more capacity (even when – on an objective basis – they have “had enough”!), and it is in the Supplier’s financial interest to keep on serving them with it. In a worst-case scenario, a failure to control demand in this way could significantly eat into any anticipated financial benefits from a move to the cloud. However, our experience is that Suppliers are noticeably reticent about taking on any responsibility for helping the Customer to manage its demand for more services (with such functions also instead being provided by third party consultants as part of a “wrapper” service around the delivery of the core cloud services).
Cloud service providers operate very much on an international basis (as do many of their clients). As such, their services will touch – either directly or indirectly – companies and operations in various different places in the world. This can cause a potential problem in the context of sanctions, particularly those from the US. If for example a cloud service provider provides IaaS to an organisation who themselves are NOT domiciled in the US (and so are not subject to US sanctions), and that organisation then provides their own services – whatever they may be – to a customer in (for example) Iran or Cuba, there is a risk that the IaaS provider may then be seen to have “facilitated” a sanctions infringing activity, so as to itself constitute a breach of law. This would then likely trigger a right for the cloud service provider to suspend or even terminate the relevant proportion of the services, without any form of financial liability of its own or even any meaningful prior notice, then leaving the customer organisation somewhat in the lurch when it comes to providing their own services to their end customer.
Dealing with Data
Data knows no geographic boundaries, and both individuals and companies can be somewhat “loose” in terms of where they send data to. However, the legal and regulatory regime associated with the processing of data has become increasingly constrictive and territorial, with EU regimes such as GDPR being mimicked elsewhere, but also creating challenges which cloud service arrangements may find it difficult to address.
So for example whilst many of the larger cloud service providers will offer their clients the ability to specify the regions within which their data will “ordinarily” reside (e.g. the EU region, for those customers who are themselves based within the EU), in the small print of the contract terms you may find that there are exceptions which would allow the cloud service provider to transfer personal data to any of their other facilities anywhere in the world, where required for “support” purposes. It seems difficult to square that off with a customer’s need to have transparency and control of where its personal data is processed for the purposes of GDPR. As a further example of the “irresistible force meets the immovable object” problem, we have GDPR allowing disclosure of personal data where mandated by an EU court, but the US Cloud Act potentially requiring cloud service providers subject to its jurisdiction (e.g. the US domiciled ones) to produce personal data within its possession or control, even if this is located outside the US… and so in potential contravention of GDPR.
The attractions of cloud services are manifold and it seems unlikely that there will be any slowdown in the take up of them in the months and years ahead. There are challenges enough in terms of negotiating the “front end” terms and conditions with cloud service providers, but customers need to take care to think beyond the more obvious contract provisions, and address some of the practical implications of a cloud transformation strategy, less they find themselves facing some unpleasant surprises down the track.