As the trees blaze colour and our nights grow crisper, I am reminded that along with post-season baseball, it’s deal time! Fourth-quarter technology transactions are in full swing as parties race to sign technology agreements and put in place new technology systems before year-end.
In their haste to close deals, however, some clients forget to think about the optimum way to contractually deal with the inevitable termination or expiration of their agreements. This is pure folly, of course, and not recommended. The following are five key areas that should be considered in connection with the exit of any technology contract.
Licence grants and abrupt terminations
How many standard technology agreements have we all read that state that upon any termination or expiration, the licensee shall “immediately” cease all use of the software in question? This often comes as a rude surprise to clients, who think that they have “perpetual” licences only to discover that, in fact, their actual licence grants do not extend beyond the termination date.
This can be problematic, particularly if (i) there is no replacement solution in the wings; (ii) the client has further sublicensed the software in question to affiliates, or other tiers/channels of users. Abrupt termination is often the norm in many “vanilla” cloud-based services agreements as well. Unfortunately, it is often not realistic or feasible for clients to cease using the technology in question on a dime. Accordingly, it is imperative that clients carefully scrutinize their licence grants and related to termination clauses in question to fully understand what the prospective vendor is offering them by way of ongoing usage rights (if any) and adjust the boilerplate accordingly.
Termination assistance/wind down
Related to the above, many standard vendor technology agreements specifically avoid offering customers any kind of meaningful termination assistance/wind-down periods.
Generally speaking, if a company took months to negotiate a mission-critical technology agreement, how is it reasonable to expect that the same company will be able to easily abandon that same technology and either shift to an in-house application or another third-party vendor? It’s not, of course, so the technology agreement must contain detailed language to reflect a more nuanced understanding of the client’s needs in relation to the exit.
Again, this is particularly relevant regarding cloud-based services, where typical agreements mostly ignore the issue or favour the “pull-the-plug” strategy. Consider what kind of transition period makes sense, its duration, whether the company will likely shift to another third-party vendor, or bring a replacement solution in-house and what kind of documentation or other data is required to kickstart and assist such transition.
If a client is not comfortable working out and documenting the nitty-gritty details in advance in the contract, the agreement should at least contain provisions establishing a framework for creating and implementing a transition plan that includes the scope of termination assistance services to be provided, service levels during the wind-down period, personnel to be used to provide such services, and the final end date for such services. Most reasonable vendors will agree to the provision of termination assistance/transition services, so long as they are paid for. These payment terms should also be carefully spelled out in the contract.
Confidential information
Standard technology agreement terms may require the parties to delete data or the confidential information of the other party after termination/expiration or are silent on deletion. However, in an age of third-party backup technology, what does deletion really mean? What about data held by any of the vendor’s subprocessors and subcontractors?
In the absence of actually securely smashing the physical storage media, “deletion” may simply mean that the data “pointers” regarding locations of data fragments are deleted and data is overwritten by fresh data over time. Also, in a multi-tenant cloud environment, many vendors will not commit to searching out and deleting a particular client’s data without additional payment.
Note as well any carve-outs on data deletion; i.e., vendors that may seek to use elements of customer confidential information or data once it has been “anonymized” for statistical or operational purposes. At the same time, there may be instances when a client wants its vendor to retain data in order to meet certain regulatory requirements. Confidentiality clauses, especially those relating to the return or destruction of data, must be carefully negotiated, depending on the nature and sensitivity of the information in question.
Data return/preservation
If a vendor is hosting or otherwise retaining a customer’s data in connection with its provision of technology services, it is critical for the technology agreement to clearly state how and when a customer can retrieve its data. Be very wary of carve-outs/limitations on data retrieval, including any dreaded “data lock-in” by a vendor should a customer’s payment to the vendor be in arrears.
Review the prospective agreement to ensure that it does not contain “data hostage” payment terms, i.e., data will be automatically deleted within 90 days of termination/expiration should the customer fail to pay its outstanding monies.
Confirm and detail the process in the agreement by which customer data will be returned or retrieved by the customer following termination/expiration of the technology agreement.
This process should include the timeframe within which the vendor must provide either the data itself or access to the data, as well as an agreed-upon format of the data to be returned. This format should be documented in the agreement. Keep in mind that if a cloud provider returns data in its own proprietary or otherwise inaccessible format, it may be utterly useless to the customer. While this may not affect many business customers, many “free” cloud providers offering storage to private customers may state that they will delete customer data in apparently dormant accounts, i.e., those that are inactive for a continuous period, so be wary of using those services in a commercial context without carefully reviewing their terms.
Customers may also wish to obtain certification by an officer of the technology vendor that the customer data has been appropriately removed/deleted from the technology vendor’s systems and confirmation that there is no residual data usage of any customer data, unless otherwise expressly agreed by the customer.
Escrow or not?
I am not always an enthusiastic advocate of putting escrow clauses in my technology contracts (especially those relating to cloud services) on the basis that, in most instances, clients do not have the ability, knowledge, or capacity to take responsibility for and make use of the vendor’s software in a way that makes sense for the clients in the long term, even if the escrow clauses allow the client to outsource the escrowed code to third-party contractors — after all, managing the technology is not a part of the customer’s core business.
However, there are times when a client is highly dependent on a mission-critical piece of vendor technology, and if that vendor is financially or otherwise shaky, escrow does make sense in that context. Accordingly, it is critical to spend some time drafting a robust escrow clause that goes far beyond standard vendor bankruptcy or insolvency triggers. Minimally, failure, inability, or unwillingness to provide maintenance/support services, change of control events or loss of key employees, and other threshold events should be added to the escrow clause.
Consider whether the proposed technology contract contains non-solicitation clauses regarding former employees and contractors of the technology vendor, and, if so, these should be eliminated so that if escrow is triggered the client is not precluded from accessing the knowledge and institutional memory of those who actually know and understand the technology in question. Of course, escrow is useless unless the vendor actually regularly updates its escrowed source code and related documentation/technical notes, so clients will need to ensure that this is tended to regularly by the vendor if they have any interest in relying on such clause.
Survival clauses
Ah, those pesky survival clauses. Who really reads them anyway? I certainly do and recommend that anyone who negotiates a technology contract scrutinize them carefully.
I am always amazed how some vendors and clients attempt to keep virtually the entire agreement alive after termination/expiration. I am not in favour of operating long term under a “dead” agreement, so I try to keep alive only a very narrow subset of terms.
For example, I do not see the commercial reasonableness of asking a vendor to maintain indemnities in perpetuity, particularly if the vendor is no longer getting any revenue under the agreement. At the same time, I recognize that it may take some time for an intellectual property claim to manifest, so there is value to maintaining an IP indemnity for a limited period post-termination. The key here is proportionality, focusing on the most relevant clauses and tailoring their survival given the nature of the deal.
Of course, relevant operational terms should survive during any wind-down period, but after that, consider which of the terms should truly survive for a limited period versus surviving indefinitely and avoid defaulting to a laundry list of the majority of terms in the agreement.
In summary, clarity is the key to a “good exit.” While no one ever wants to talk about the divorce while planning for the wedding, spelling out the critical exit terms in the technology agreement can often make the difference between a reasonable termination experience and being hit with some unpleasant surprises. Plan accordingly!
In their haste to close deals, however, some clients forget to think about the optimum way to contractually deal with the inevitable termination or expiration of their agreements. This is pure folly, of course, and not recommended. The following are five key areas that should be considered in connection with the exit of any technology contract.
Licence grants and abrupt terminations
How many standard technology agreements have we all read that state that upon any termination or expiration, the licensee shall “immediately” cease all use of the software in question? This often comes as a rude surprise to clients, who think that they have “perpetual” licences only to discover that, in fact, their actual licence grants do not extend beyond the termination date.
This can be problematic, particularly if (i) there is no replacement solution in the wings; (ii) the client has further sublicensed the software in question to affiliates, or other tiers/channels of users. Abrupt termination is often the norm in many “vanilla” cloud-based services agreements as well. Unfortunately, it is often not realistic or feasible for clients to cease using the technology in question on a dime. Accordingly, it is imperative that clients carefully scrutinize their licence grants and related to termination clauses in question to fully understand what the prospective vendor is offering them by way of ongoing usage rights (if any) and adjust the boilerplate accordingly.
Termination assistance/wind down
Related to the above, many standard vendor technology agreements specifically avoid offering customers any kind of meaningful termination assistance/wind-down periods.
Generally speaking, if a company took months to negotiate a mission-critical technology agreement, how is it reasonable to expect that the same company will be able to easily abandon that same technology and either shift to an in-house application or another third-party vendor? It’s not, of course, so the technology agreement must contain detailed language to reflect a more nuanced understanding of the client’s needs in relation to the exit.
Again, this is particularly relevant regarding cloud-based services, where typical agreements mostly ignore the issue or favour the “pull-the-plug” strategy. Consider what kind of transition period makes sense, its duration, whether the company will likely shift to another third-party vendor, or bring a replacement solution in-house and what kind of documentation or other data is required to kickstart and assist such transition.
If a client is not comfortable working out and documenting the nitty-gritty details in advance in the contract, the agreement should at least contain provisions establishing a framework for creating and implementing a transition plan that includes the scope of termination assistance services to be provided, service levels during the wind-down period, personnel to be used to provide such services, and the final end date for such services. Most reasonable vendors will agree to the provision of termination assistance/transition services, so long as they are paid for. These payment terms should also be carefully spelled out in the contract.
Confidential information
Standard technology agreement terms may require the parties to delete data or the confidential information of the other party after termination/expiration or are silent on deletion. However, in an age of third-party backup technology, what does deletion really mean? What about data held by any of the vendor’s subprocessors and subcontractors?
In the absence of actually securely smashing the physical storage media, “deletion” may simply mean that the data “pointers” regarding locations of data fragments are deleted and data is overwritten by fresh data over time. Also, in a multi-tenant cloud environment, many vendors will not commit to searching out and deleting a particular client’s data without additional payment.
Note as well any carve-outs on data deletion; i.e., vendors that may seek to use elements of customer confidential information or data once it has been “anonymized” for statistical or operational purposes. At the same time, there may be instances when a client wants its vendor to retain data in order to meet certain regulatory requirements. Confidentiality clauses, especially those relating to the return or destruction of data, must be carefully negotiated, depending on the nature and sensitivity of the information in question.
Data return/preservation
If a vendor is hosting or otherwise retaining a customer’s data in connection with its provision of technology services, it is critical for the technology agreement to clearly state how and when a customer can retrieve its data. Be very wary of carve-outs/limitations on data retrieval, including any dreaded “data lock-in” by a vendor should a customer’s payment to the vendor be in arrears.
Review the prospective agreement to ensure that it does not contain “data hostage” payment terms, i.e., data will be automatically deleted within 90 days of termination/expiration should the customer fail to pay its outstanding monies.
Confirm and detail the process in the agreement by which customer data will be returned or retrieved by the customer following termination/expiration of the technology agreement.
This process should include the timeframe within which the vendor must provide either the data itself or access to the data, as well as an agreed-upon format of the data to be returned. This format should be documented in the agreement. Keep in mind that if a cloud provider returns data in its own proprietary or otherwise inaccessible format, it may be utterly useless to the customer. While this may not affect many business customers, many “free” cloud providers offering storage to private customers may state that they will delete customer data in apparently dormant accounts, i.e., those that are inactive for a continuous period, so be wary of using those services in a commercial context without carefully reviewing their terms.
Customers may also wish to obtain certification by an officer of the technology vendor that the customer data has been appropriately removed/deleted from the technology vendor’s systems and confirmation that there is no residual data usage of any customer data, unless otherwise expressly agreed by the customer.
Escrow or not?
I am not always an enthusiastic advocate of putting escrow clauses in my technology contracts (especially those relating to cloud services) on the basis that, in most instances, clients do not have the ability, knowledge, or capacity to take responsibility for and make use of the vendor’s software in a way that makes sense for the clients in the long term, even if the escrow clauses allow the client to outsource the escrowed code to third-party contractors — after all, managing the technology is not a part of the customer’s core business.
However, there are times when a client is highly dependent on a mission-critical piece of vendor technology, and if that vendor is financially or otherwise shaky, escrow does make sense in that context. Accordingly, it is critical to spend some time drafting a robust escrow clause that goes far beyond standard vendor bankruptcy or insolvency triggers. Minimally, failure, inability, or unwillingness to provide maintenance/support services, change of control events or loss of key employees, and other threshold events should be added to the escrow clause.
Consider whether the proposed technology contract contains non-solicitation clauses regarding former employees and contractors of the technology vendor, and, if so, these should be eliminated so that if escrow is triggered the client is not precluded from accessing the knowledge and institutional memory of those who actually know and understand the technology in question. Of course, escrow is useless unless the vendor actually regularly updates its escrowed source code and related documentation/technical notes, so clients will need to ensure that this is tended to regularly by the vendor if they have any interest in relying on such clause.
Survival clauses
Ah, those pesky survival clauses. Who really reads them anyway? I certainly do and recommend that anyone who negotiates a technology contract scrutinize them carefully.
I am always amazed how some vendors and clients attempt to keep virtually the entire agreement alive after termination/expiration. I am not in favour of operating long term under a “dead” agreement, so I try to keep alive only a very narrow subset of terms.
For example, I do not see the commercial reasonableness of asking a vendor to maintain indemnities in perpetuity, particularly if the vendor is no longer getting any revenue under the agreement. At the same time, I recognize that it may take some time for an intellectual property claim to manifest, so there is value to maintaining an IP indemnity for a limited period post-termination. The key here is proportionality, focusing on the most relevant clauses and tailoring their survival given the nature of the deal.
Of course, relevant operational terms should survive during any wind-down period, but after that, consider which of the terms should truly survive for a limited period versus surviving indefinitely and avoid defaulting to a laundry list of the majority of terms in the agreement.
In summary, clarity is the key to a “good exit.” While no one ever wants to talk about the divorce while planning for the wedding, spelling out the critical exit terms in the technology agreement can often make the difference between a reasonable termination experience and being hit with some unpleasant surprises. Plan accordingly!
