When an M&A transaction closes, the buyer will typically be unable to stand up its own IT environment on day one. In this scenario, the seller often continues operating existing IT systems, provides access to employees who understand them, and delivers data needed for the transition for a period after closing to assist the buyer in eventually operating a standalone IT environment of its own.
A traditional transition services agreement, or TSA, is a mechanism used to document the provider’s (generally the seller’s) bridge of services to the recipient (generally the buyer) for a period of time after closing as necessary for the recipient to independently operate its IT systems.
Transition services are generally provided to accomplish three goals: keep the lights on, support the transition through knowledge transfer, and deliver agreed-upon assets.
While that may seem straightforward, when IT transition services are being provided the parties must carefully consider the specific services and their respective obligations during any such transition period, and allocate responsibility accordingly.
Keeping the Lights On
The provider’s first responsibility is assisting with continuity. During the agreed transition period, the provider generally continues performing services previously used by the transferred business, in substantially the same manner as before closing.
With respect to IT transition services, unless the TSA says otherwise, the provider generally maintains the current environment—and is not responsible for building the recipient’s new one.
Supporting the Transition
The provider may also make knowledgeable personnel available to answer questions, explain processes, and transfer institutional knowledge. In this context, that may involve making the IT employees that know how the relevant applications interact available to the service recipient for a period of time.
The TSA IT transition services schedule should define the expected level of such support, including available hours, response times, meeting cadence, and documentation. It should also clarify who is responsible for the project plan and any implementation decisions, and note applicable vendors, testing, migration, and cutover logistics.
Delivering the Agreed Assets
The provider’s third responsibility is often the delivery of data, documentation, or other agreed assets. The TSA should identify what data will be delivered, when it will be delivered, and in what format.
If the buyer requires cleansing, transformation, configuration, or conversion beyond the agreed format, that additional work is generally handled through a change-control process rather than treated as part of the original service.
Allocate Responsibility for the Outcome
A traditional IT TSA is process-based rather than results-based. The provider performs the agreed services, supplies the agreed support, and delivers the agreed assets.
In this scenario, the provider can keep the lights on, explain how the existing environment works, and deliver the agreed data, but the recipient must determine where—and how—the business goes next with respect to IT and is responsible for using the resources provided during the transition period to establish its replacement environment and achieve the desired result.
Specifically, the recipient in this scenario typically remains responsible for designing its future-state environment, engaging implementation vendors, configuring and testing replacement systems, migrating data, and completing the cutover.
The TSA should define the existing services, available support, deliverables, dependencies, and change-control procedures, and clearly allocate the parties’ obligations and responsibility with respect to the IT transition.