When a company decides to pursue an acquisition or divestiture, there are many issues to consider. Far too often, the parties neglect considering, until late in the process, whether any post-closing services need to be provided under a transition services agreement (TSA). This article discusses the general context in which TSAs are required and provides tips for starting to gather and analyze TSA requirements to avoid unnecessary deal costs, delays and inefficiencies.

When is a TSA Required?

Because of the time and resources often required to complete a TSA, the parties should determine early on whether a TSA is warranted. Not every deal requires a TSA: the determination revolves around the interconnectedness of the seller and the target business, as well as the particular capabilities of each party. For instance, will the divestiture result in the buyer acquiring all assets (systems, service agreements, licenses, etc.) needed to run the target business (i.e., the “clean-break” scenario)? If so, is the buyer confident that it will be able to run the divested business without any help from the seller? Likewise, will the seller be able to run its retained business without assets or help from the divested business? If the answer to these questions is “yes,” then a TSA may not be needed. However, if either party will need assets or assistance from the other party after closing, a TSA will be required.

TSAs vary widely in duration, based on the requirements of the particular deal. If the target business is largely autonomous, a TSA lasting several months may be adequate to deal with knowledge transfer and system migration issues. Conversely, in complex situations, where the target business relies on systems shared with the seller’s retained business, or where the buyer itself is unable to provide the required services, a multi-year TSA may be required. Multi-year TSAs give the buyer more time to de-couple from the seller and acquire its own capabilities for running the target business.

While TSAs often cover the provision of services from seller to buyer (known as a “forward TSA”), this is not always the case. In a “reverse TSA” situation, the flow of services is from the buyer (or target business) to the seller. Reverse TSAs are often required where critical assets or resources are to be transferred along with the target business, such as a data center used by the seller’s retained business, or technical personnel used to support applications or systems used by both the target business and the seller’s retained business. The issues of concern to the seller (as a service recipient) under the reverse TSA are generally analogous to those of concern to the buyer under a forward TSA.

TSA issues should be contemplated while the struc­ture of the transaction is still in flux and before the buyer has been identified. For this reason, the seller’s initial preparation is likely to be refined as the deal progresses. Nevertheless, there can be significant value in careful planning early in the deal process, in part because this enables the seller to present a workable deal package to the buyer, including information that the buyer will need to quickly assess any overlaps or gaps in assets and capabilities for running the target business.

TSAs Compared to Outsourcing Agreements
Both TSAs and outsourcing agreements commonly involve one party providing the other with services that may be critical to the operation of the service recipient’s business. However, a key difference in TSAs is that the seller (as the service provider) is generally not in the business of providing those services. Moreover, the seller’s information technology (IT) organization may lack the discipline and the industry standard processes of professional outsourcers. Likewise, the degree of service customiza­tion under a TSA is usually more limited than in an outsourcing agreement, particularly where the seller uses the same systems to service the buyer and the seller’s retained business. For these reasons, the seller may only be willing to commit to provide the TSA services in the same manner that it provides similar services to itself.

What Are the First Steps to Prepare for a TSA?
The seller and buyer should start gathering information relating to the TSA as early as possible in the deal process to help address potential issues before they become major problems. Ideally, the seller and buyer would involve a wide variety of people with the relevant knowledge in early deal discussions. However, this is usually not practical because competing demands on resources and the need for confidentiality limits the number of people who can be involved. This compli­cates and delays the task of gathering information and developing solutions. The objective should be to strike a balance between limiting the “circle of knowledge” and involving the specialists needed to appropriately analyze requirements and resolve issues.


Systems and Services. The seller must identify the systems and services that are currently used to conduct the target business, including those which are critical to the target business. Depending upon the nature of the transaction, potential items to consider include:

  • Implemented systems (e.g., enterprise resource planning (ERP) and human resource systems, claims/payment processing systems, web sites/e-commerce infrastructure, production/ manufacturing control, databases, interactive voice response (IVR)/telephony systems);
  • Interfaces and systems for interactions with third parties (e.g., banks, regulators, data providers, suppliers, customers);
  • IT facilities and resources (e.g., data centers, sup­port/development centers, call centers, offsite data storage sites, disaster recovery/hotsite locations);
  • Service agreements (e.g., outsourcing services, managed network, data center collocation, disas­ter recovery/business continuity, landline/mobile telecom and personal digital assistants (PDAs), support/maintenance arrangements); and
  • License/support agreements (e.g., application, database and operating system software).

For each item identified, the seller should also consider key issues:

  • What technology platforms are used;
  • Whether the system or service was developed internally by the seller’s organization;
  • Whether the system or service is “dedicated” (i.e., used exclusively to support the target business) or “shared” (i.e., used to support both the target business and other parts of the seller organization);
  • What support model is currently used for the target business (i.e., by the target business itself [internal], by the seller or an affiliate of the target business [centralized], or by a third party through an agreement between the provider and the target business or the seller or an affiliate of the target business [outsourcing]);
  • Whether it is feasible to assign to the buyer any third-party agreements used to support the target business, and/or whether consents are required to provide services under the TSA (either temporar­ily or on a long-term basis) to the buyer; and
  • Whether there are commingled data or records that will be impractical for the seller to segregate (e.g. email or historical or archived data).

In addition, the seller should determine whether any of these items will no longer be required after the deal closes, including the costs that may result from terminating any associated contracts. Though these requirements may be buyer-dependent, doing this analysis early often helps the seller develop a more accurate picture of IT-related transaction costs involved in the deal.

Major Projects. The seller should identify major projects that are in process, or scheduled to be performed, for the target business, as well as the preferred disposition of these projects in view of the proposed deal. Considerations here could include: (i) criticality and complexity; (ii) the entities involved in performance; (iii) the current status, including remaining work and completion time frame; (iv) current and planned future investments; (v) practi­calities of completion prior to closing; and (vi) potential costs and other impacts of termination prior to closing.

Personnel. The seller should determine which personnel support the target business (and, if applicable, which target business personnel support other parts of the seller’s organization), including the employing entity, work locations, locations supported by such personnel, whether such personnel are to be retained by the seller or transferred to the buyer and whether any such personnel are critical or “key” personnel to the operation of any business.

Evaluation of Buyer Requirements. The buyer’s key task at the beginning of the transaction is to evaluate the seller’s responses to the inquiries described above (through initial meetings with the seller and due diligence questionnaires), so the buyer has a better sense of the systems and services used to run the target business. The buyer should use this information to identify any potential overlaps and gaps in its own capabilities and systems. In the event of overlaps, the buyer should identify which overlapping item should be retained after closing. In the event of gaps, the buyer should identify how the inadequate or lacking systems or services will be addressed, such as through the buyer’s current systems and services, TSA services or newly procured systems or services. In addition, the buyer should consider how the systems and services of the target business and the seller interconnect with its own technology sourcing model. Incompatibilities with the buyer’s current systems should be identified and analyzed early in the process to identify alternative arrangements. The buyer should also assess sourcing options for the target business when the TSA ends.

The issues described in this article are seldom focused on early in the process of divesting or acquiring a company. When they are left to the end of the deal process, unnecessary delays and costs may result. Proactively addressing these issues up front, as outlined above, can help avoid these problems.

To read this complete article visit Business & Technology Sourcing Review - Issue 15.