M&A - Divesting Data: Ten Considerations

Historically, asset delivery as part of a divestiture was somewhat simplified because what was being transferred was primarily hard assets (real estate, machinery, inventory, etc.), and therefore easily carved out of an existing business.

As business and revenue models move away from hard assets and toward soft assets, like software and data, a seller must efficiently and accurately identify, extract, and deliver in-scope data to the buyer during a carve-out divestiture.  This process can be extremely complex in larger global businesses.  The seller's ability to separate and deliver data can add or subtract millions of dollars to the deal's outcome.  

Below are ten things you should consider when divesting data.  These considerations should be spelled out in the legal agreement in some form.  Setting the right expectations up front will not only protect the seller, but it will set the goal posts for the buyer as they do transition planning.  

1.  Define the Scope, History, and Time of Transfer

This is somewhat obvious, but at times overlooked.  Carefully define what data is in scope.  Be very specific on what stays and what goes.  You'll want to create a list of all data assets across all business functions, and then work the list.  

Sometimes you'll find that you have data that is not part of the transaction embedded within in-scope data (marketing documents, engineering designs, databases, etc.)  Identify these more complex data assets/structures and make a plan on how to segment the data and perform the transition.

How far back in time are you going to provide data; 1 year, 3 years, 7 years?  This may vary with the type of data you are delivering.  Define this as short and strictly as possible, and then give the Data Steward or Legal the ability to make case by case exceptions on what makes sense to deliver.  

You will also need to specify the terms of when the assets will be delivered.  It’s likely you will be unable to provide all the assets at close.  

Don’t set yourself up by defining, or assuming, in the deal agreement that the data assets transfer at close.  While the data's ownership will change at close, you must define the correct amount of time post-close to deliver the assets.  If you fail to specify enough time you will likely be pressured by the buyer for the entire separation.  This will erode confidence and be a distraction for you and the buyer.

You should also set expectations on when the data can be "accessable" to the buyer.  Sometimes a buyer will want access to the data while it's still in the seller's systems/posession.  One common example of this is when a buyer performs an account receivable workout from the seller's system instead of importing AR transactions into their own AR systems.  

Pay careful attention to when the buyer is expecting to receive the data.  Don't let the buyer's ability/inability to accept the data put you in a situation where you  wait for months, and then you are expected to deliver the data under a very short/difficult timeline.  Migrations/cutovers during a transition service agreement (TSA) can stress the seller's resources to quickly provide data to match the buyer's integration plan of record.  I explain this more below.

2.  Define Transfer Method

Clearly set expectations with the buyer on the method of transferring the data.  Will you be using SFTP, FTPS, hard disks, network storage devices, servers/data center hardware, USPS, FedEx, Truck, Pickup Only, etc.?  

Digital and physical security policies and requirements vary greatly between companies and even geographies.  Work with the buyer to understand their requirements and what you are able to accommodate.  How will the data be secured and encrypted?  What's the process of chain of possession?  How will the buyer confirm having received the data (as opposed to accepting the data, see below)?  Will the data require a file integrity hash to be provided?  

Data sovereignty may impact the transfer of data.  Help the buyer understand what legal limitations you have in providing the data in scope due to the location and type of data.  For example, a buyer may need to obtain a data center in a geography due to the legal restraints against transferring personal data outside of that territory.

3.  Define Transfer Format

The buyer should understand the various formats in which they will receive the data.  Will the data be formatted text, tab delimited, PDF, Excel, or a proprietary format in which specific applications/licenses are needed to interpret the data?  

Clearly spell out the state in which the data will be delivered.  What I mean here is that the data should be extracted in its raw form without the seller having to perform calculations, conversions, or reconciliations/normalization.  A simple example of this is that you may have data in your database that represents imperial measurements/dimensions.  The buyer my be in Europe and want you to provide the measurements in metric.

Your deal terms should outline the responsibility for data manipulation to be the buyer's.  As the seller, if you have the resources, you might consider setting up a process where the buyer could pay you to perform certain data manipulation services.  The need for these data services are most often only discovered after the separation has begun. If the buyer has a weak integration team, this could really help the success of the deal.

4.  Data Retention Policy

Will you keep a copy of the data that you transfer, or destroy it?  In most cases you'll want to keep a copy of all data and destroy it per your normal data retention policies.  Keeping a copy of the data prevents you from having to pick out and delete data from your systems, potentially causing downstream bugs or system issues due to data interdependencies.

As you deliver the data, if possible, create a repository with everything you transferred to the buyer.  You can use this repository to understand what was delivered if ever you need to do an audit.  You don’t want to have to pick through backups or guess what was included or excluded in a extract that was performed months ago.  Ideally the the need for this would be mitigated through a acceptance/sign-off process.

5.  Post-Close Data Ownership

If the deal includes a transition services agreement, how will you treat the data that’s generated after close, but prior to the end of the TSA?   Does it belong to the buyer or the seller?  

For example, let’s say you’re developing code for a shared hardware chip.  You run the business under TSA for a year and develop software code directly or tangentially while performing the TSA.  Do you deliver the code snapshot from the date of close and keep the rest, or do you deliver everything you create during the TSA as well?  

6.  Buyer Access to Non-Separated Data

Post-close access for the buyer to the seller's network/systems/tools might be critical to the separation.  If under TSA, the buyer may need access to run a portion of the business that’s not yet been transitioned. While this a security challenge for the seller, it will be critical for the buyer to maintain and potentially understand how to stand up their own business processes and operations.  The seller will likely have to do this anyway if there are employees that are transitioning to the buyer at close, but still needs access to their old systems/tools to execute the TSA.  

This type of arrangement frequently happens with ERP systems where the buyer will not transition historical data, but rather start fresh on their side, and then have the seller give them access to the old ERP for a period of time for operations and customer support.

7.  Vendor Data

As the seller, it's easier for you to control the quality, format, and extraction of the data you generate in-house.  Sometimes you will have data generated and stored by vendors with data quality and extraction capabilities that are less than what the buyer expects.  For example, you might have to rely on a vendor's capabilities, like Salesforce, as part of your data delivery.  Vendor data quality and formats can only be controlled to an extent.  

Set the expectation with the buyer that you will have limitations around quality, format, and extraction SLAs with certain vendor data.  As the seller, you don’t want to be responsible for vendor data beyond the vendor's capabilities.

8.  Buyer Sign-off SLA

The seller should have expectations of how quickly the buyer should sign off on delivery of data assets.  If buyer is understaffed in their ability to accept and assess data, they may significantly delay sign-off causing you to incur more costs keeping resources on staff just in case more extracts are needed or they discover missing data when they get around to importing it six months after TSA termination.

9.  References in Data

You may have data that is part of the deal that has hyperlinks, or other references, to tools/files/records that are out of scope for the transaction.  You need to be clear to the buyer that you are not responsible for delivering hyperlinked data if it's not part of the deal.  Just because you have a link to that data in the record/file, does not mean that it comes into scope for the deal.  This is not a rabbit hole you want to go down.  You may find this crop up in knowledge bases, product/service manuals or catalogs, and engineering specifications.  These types of information systems usually contain quite a bit of links.

Additionally, you may need to think through your capability to maintain referential integrity of linked/hyperlinked data.  If it's going to be difficult, address that challenge with your team and buyer as soon as you can.

10.  Plan of Record Migration SLA (Incremental or Phased?)

You need to set expectations around your ability to provide data based on how the buyer expects to stand up their business.  I’ve seen buyers that initially wanted to transfer data function by function as they stood up capabilities on their side, and then at the last minute switch to a customer by customer migration plan.  That last-minute change turned a single data transfer plan into many smaller transfers that had the same level of effort and risk for each transfer, causing seller costs to increase.

Alternatively, you may encounter some hybrid plans that involves, geography/territory, market, capability (supply chain/operations/engineering), and customer.  If you can't deliver the data based on the buyer's plan of record, it can torpedo the buyer's ability to execute their integration and destroy the deal value drivers.  Make sure you and the buyer have a very good understanding of how to execute their plan of record with both companies given resources/budgets.  Plan and set expectations conservatively and realistically here.  It always takes longer than you'd like.

Conclusion

M&A transactions will increasingly involve the exchange of data.  M&A separation teams need a good understanding of how to deliver the data with a minimum of surprises to the buyer while simutaniously protecting the data the buyer did not purchase.