Your TMS or visibility vendor was acquired: how to protect access to your data

What changes when your TMS or visibility vendor is acquired?#

When a TMS or visibility vendor is acquired, your contract usually carries over to the new owner, but the product roadmap, hosting and data-use terms can change. Acquirers commonly consolidate overlapping platforms, retire features, move hosting and update terms of service, sometimes through a click-through notice rather than a negotiated amendment.

Visibility platforms raise the stakes because they often hold records you keep nowhere else: tracking events from carrier integrations, predicted arrival times against actual arrivals, exception alerts and the notes your team added. A TMS holds the loads, rates, carrier details and invoices that drive daily work. Losing reliable access to either is both an operational and a legal problem.

This is general information, not legal advice. Contract terms differ, so review your own agreements with counsel.

Step 1: read the assignment and change-of-control clauses#

The assignment and change-of-control clauses tell you whether the vendor could transfer your contract without your consent and whether the deal gives you any right to exit. Read them alongside the data clauses, because together they decide what you can ask for now.

If the contract is silent on data ownership or return, that silence is itself a finding. It is the clause to negotiate first, and change-of-control rights, where you have them, are the leverage to do it.

Step 2: export your history now#

Export your history now, while the current platform works and the people who know it are still at the vendor. Waiting for a migration notice risks shorter export windows, changed formats and support teams focused on moving customers to the new platform.

Test each export by opening it outside the platform and comparing it with what users see on screen. Exports that look complete often leave out notes, attachments or event history beyond a default window, and those gaps are far easier to fix while the platform still runs.

• 1TMS: loads, stops, rates, accessorials, carrier records, invoices, claims and internal notes.
• 2Visibility: tracking events, predicted and actual arrival times, exception alerts and comments.
• 3Carrier connectivity records showing which carriers sent which data, and how.
• 4Documents: bills of lading, proof of delivery and rate confirmations.
• 5User and permission lists showing who had access to what.
• 6Field definitions and code lists for every export.

Step 3: confirm retention and deletion in writing#

Retention and deletion should be confirmed in writing: ask the vendor how long it will keep your data after termination, where it is stored, whether it will move to the acquirer's systems and how deletion is certified. A support chat answer is not enough; ask for a letter or email from someone authorized to commit the company.

Ask the same questions about backups and subprocessors. If the acquirer plans to merge hosting, find out whether your data will sit in a new region or with new subprocessors, and whether your existing privacy terms and security commitments carry over unchanged.

Step 4: review new terms before you accept them#

New terms deserve review before acceptance because updated agreements are where data-use rights quietly expand. Route any click-through update to counsel rather than letting a dispatcher accept it at login.

Step 5: document what you hold and who can reach it#

Documenting what you hold means keeping an export manifest: for each file, the source system, export date, date range, row count, field definitions and the people who can access it. The manifest proves completeness if a dispute arises and keeps the archive usable long after the platform is gone.

Published provenance standards offer a useful model. The Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, and a manifest built along those lines answers most of the questions a future acquirer, auditor or data licensee will ask.

Illustrative: a distributor's counsel after a visibility deal#

Illustrative: a fictional food and beverage distributor runs a TMS for its private fleet and a visibility platform for common-carrier loads. The visibility vendor announces it has been acquired by a larger logistics software company with an overlapping product.

The general counsel works through the five steps. The contract allows assignment to a successor, but data return is promised only in the vendor's standard format. IT exports tracking events, arrival history and exception notes with a manifest. Counsel obtains written confirmation of retention after termination and declines an updated clause allowing model training on customer data until it is narrowed.

The outcome: when the acquirer later announces a platform migration, the distributor already holds a complete archive under its own control, and its operations team moves on its own timetable rather than the vendor's.

How SourceX treats vendor-held history#

SourceX treats vendor-held history as licensable only when the supplier can show it controls the records and the vendor terms allow the use. In the Rights step of the SourceX five-step transaction, vendor agreements are reviewed alongside customer contracts, and the export manifest becomes part of the provenance record in the SourceX Evidence Packet. The supplier approves every step, and large archives stay in its own storage.

Vendor terms matter here because a visibility vendor that has already used your tracking events in pooled benchmarks or models may hold rights that overlap with what a buyer wants. The rights review identifies that overlap before any sample is discussed, so the supplier is not surprised late in a transaction.