TMS and WMS consolidation after logistics acquisitions

What should move to the platform TMS, and what should stay behind?#

The platform TMS should receive live operational data: open orders and loads, active customer and carrier profiles, current rate agreements and the location master. Closed history is a different problem. Old loads were created under another company's status codes, accessorial rules and numbering, and pushing them into the new data model tends to strip the fields that explained them.

Most integration teams get better results by splitting the work. Live data is migrated and cleaned for the platform; closed history is exported whole, kept in its original structure and stored in an archive people can still query. The same split applies to a WMS: on-hand inventory, item masters and open orders move, while receipt, putaway, pick, ship and adjustment history is archived.

Which links in shipment history are worth protecting?#

The links worth protecting in shipment history are the ones that connect a customer request to what physically happened and to how any problem was settled. A load record on its own says little. A load joined to its stops, tracking events, delay codes, the exception raised, the claim filed and the credit issued tells the full story of a decision.

Those chains break most often at renumbering. Migration tools usually assign new IDs, attachments are stored under paths that no longer resolve, and free-text notes are truncated because the target field is shorter. Each break turns a connected history into loose tables that nobody can reassemble later.

• 1Order to load to stops: which customer order became which load, with planned and actual times at each stop.
• 2Load to tracking events: status messages, check calls and ELD or telematics pings with timestamps.
• 3Event to exception: the delay, refusal, damage or shortage raised, with its reason code and who logged it.
• 4Exception to claim: the claim file, carrier response, photos, inspection reports and correspondence.
• 5Claim to money: the credit memo, chargeback or write-off in accounting, with its approval.
• 6WMS receipt to putaway to pick to ship to return, including cycle-count adjustments and their reason codes.

Pre-retirement checklist for each legacy TMS and WMS#

A pre-retirement checklist gives the integration lead one gate per system: nothing is switched off until every line is complete and signed by the system owner. Run it separately for each acquired company, because each one negotiated its own vendor contract and stored its records in its own way.

• 1Read the vendor agreement for the termination notice date, post-termination export rights and any fee for bulk exports.
• 2List every record family the system holds, including modules the team rarely opens, such as claims, freight audit or yard management.
• 3Export full history twice: once in the vendor's native or backup format, and once as flat relational tables with every key preserved.
• 4Download attachments separately: bills of lading, proof-of-delivery images, damage photos, inspection reports and claim letters.
• 5Export reference tables as of the cutover date: status codes, reason codes, accessorial codes, user lists and master records.
• 6Build a crosswalk that maps every legacy load, order, customer and carrier ID to its platform equivalent where one exists.
• 7Reconcile record counts by year and record type between the live system and the export, then trace sample chains end to end.
• 8Store the archive read-only, with role-based access, a named owner and a recorded retention decision.
• 9Write a provenance note: legal entity, system and version, date range, export date and the person who ran the export.
• 10Only then send the termination notice or let the subscription lapse.

Where do claims histories usually get lost?#

Claims histories usually get lost because they rarely live entirely inside the TMS. Many smaller carriers, brokers and 3PLs track over, short and damaged claims in a shared inbox, a spreadsheet or the accounting system, and only the original shipment sits in the TMS. Retiring the TMS then leaves the shipment without its outcome, or the claim without its shipment.

Ask each acquired company's claims or customer service lead to walk through one recent claim from first notice to settlement, naming every tool they touched. That walk-through finds hidden locations faster than any system inventory.

Illustrative: a freight platform retiring two acquired systems#

Illustrative: a fictional buy-and-build platform, Quillmere Freight Group, runs brokerage on a cloud TMS and acquires two add-ons. One is a regional LTL broker on an older on-premise TMS with its own claims module. The other is a contract warehouse on a hosted WMS, with returns handled through RMA numbers in a separate customer portal.

The integration lead migrates open loads, carriers and current rates from the LTL broker, then exports closed history with load, stop and event IDs and a crosswalk. The claim walk-through reveals that settlement letters live in a shared mailbox, so the mailbox is exported and tagged by claim number. At the warehouse, on-hand inventory moves to the platform WMS, while receipt, pick and return history is archived with RMA links intact.

Before cancelling either legacy contract, the team reconciles counts and traces sample chains from order to credit memo. One shipper contract at the LTL broker restricts reuse of its shipment details, so those records are tagged for exclusion in the archive. The legacy systems are retired only after both system owners sign the checklist.

Who holds the rights to archived history after systems merge?#

Rights to archived history generally stay with the legal entity that created the records, even when the data now sits in the platform's storage. Merging systems is an operational step; it does not rewrite the customer contracts, shipper confidentiality terms or vendor agreements that applied when each record was made.

Keep an entity tag on every archived record and index each acquired company's customer contracts against its customer master. Shipper agreements often treat lanes, volumes and rates as confidential. If several add-ons once competed for the same freight, pooling their rate and capacity history raises separate antitrust questions that counsel should review before anyone builds a combined dataset.

How SourceX approaches consolidated logistics archives#

SourceX treats a consolidated logistics archive as one supply per legal entity and runs each through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first look uses metadata only, such as system names, date ranges and record families, so no files leave the archive during the initial assessment.

When an entity proceeds, preparation removes personal details such as driver names and phone numbers and confidential details such as shipper names or restricted rates, and the entity's own signer approves the release. The SourceX Evidence Packet records provenance down to the legacy system and date range, and large archives stay in the company's own storage or ship on encrypted drives.