Any form of acquisition or divestiture will have an impact and some kind of transition plan will be required. Even if you have the disks with the apps and data shipped to your corporate headquarters, there is still a small matter of cutting over to running in your possession. How do you do that and minimize your customer impact? Also how can you be sure you have all of the data prior to the cut-over?

This is where a TSA comes in.

The Transition Service Agreement can double as a contract and planning document. It provides an agreement and details on what an orderly transition of the software bits will look like with a focus on minimizing disruptions. This can be an operational requirement to ensure business as usual and it can also act as insurance in the event additional requirements crop up during the integration phase.

What goes into it?

Just like any migration project:

  1. Establishes the start and end points
  2. Establish what a maintenance and support model would look like throughout the transition
  3. Create a formalized approach for how to convey the data and applications
  4. Limitations to ensure the focus is on conveying the agreed upon pieces

More importantly, it establishes the scope of responsibility.

When should you work on this?

Preferably, the earlier, the better. Think once you are planning to go ahead with the deal. The plan, at a minimum, must be done prior to close to ensure that any formal agreements are in place.

One thing to note about this is that it puts at least the divested company in the position of being a service provider (and possibly the acquirer if there are still dependencies). This is not a common or expected working model, but is where the TSA becomes critical.