Consolidated legacy archives after add-on acquisitions: what to keep

What happens to legacy systems after an add-on acquisition?#

Legacy systems after an add-on acquisition are usually replaced by the platform's ERP, CRM, help desk, TMS or FSM, and the old subscriptions are cancelled to cut cost. Integration teams migrate what the business needs to keep operating: open orders, active customers, current jobs and unresolved tickets.

History is what gets left behind. Migration tools can skip closed records, drop attachments and internal notes, and break the links between a ticket and its emails or an order and its exceptions. Once a vendor subscription ends, access may be limited or data may be deleted under the vendor's terms, so check the documentation and contract before the cancellation date.

What to keep from each legacy system#

Keep a complete export of each legacy system, not just the fields the new system uses. The test is simple: could someone who never used the old system reconstruct what happened on a given order, ticket or job from the archive alone?

The table lists what to include and why each item matters later, for claims, audits, integration questions and any future licensing.

Prefer open, documented formats such as CSV or JSON for records and original file formats for attachments, and keep the vendor's native export as well if one exists. Then pick a handful of closed records and trace each one end to end in the archive before the old system goes dark.

Keep the terms that came with the records#

The terms that governed an acquired company's records belong in the archive, because rights to use those records are inherited from that company's contracts and notices. Platforms often keep the data and lose the paperwork, then cannot answer basic questions about permitted use.

Store customer contracts and standard terms, the privacy notices in force when records were collected, vendor terms for each system, employee notices, NDAs and any prior data-sharing agreements. Whether an asset or stock purchase was used also affects what transferred, so file the relevant parts of the purchase agreement too. Counsel decides how each term applies; the archive's job is to make sure the terms can be found.

A decommission checklist for acquired systems#

A decommission checklist turns archiving into a gate that integration cannot skip. Assign an owner to each check and do not cancel a subscription until every row is done.

The usual failure is timing. Subscription renewals and data center exits set the dates, and archiving gets squeezed into the final stretch. Put the checklist into the integration plan at signing, so exports are tested while the people who know the old system are still on staff.

Where and how to store consolidated archives#

Consolidated archives should sit in company-controlled storage, separate from live systems, read-only and encrypted, with logged access. Loading old records into the new production system mixes histories and makes it hard to tell later which entity a record came from.

Give each archive a short manifest so anyone can understand it without the original team. For a published reference on what such metadata can cover, the Data & Trust Alliance's Data Provenance Standards organize dataset metadata under Source, Provenance and Use headings.

• 1Source entity and the acquisition it came from.
• 2System name and version, with the date range covered.
• 3Record families included and any excluded.
• 4Export date, method and who ran it.
• 5Governing terms and known restrictions.
• 6Archive owner and retention schedule.

Why combined archives matter for data licensing#

Combined archives matter for data licensing because several add-ons doing the same work can together hold a deeper record of that work than any one company. Freight exceptions from three brokerages, or service tickets from three software products in one vertical, can form a more useful package than each alone.

Combining does not merge rights. Each acquired entity's records carry its own customer terms, notices and vendor restrictions, so rights are reviewed entity by entity even if the records later ship together. Licensing also does not require moving archives into one system; a documented manifest per archive is usually enough to scope a package.

Illustrative: a freight and 3PL platform retires three legacy systems#

Illustrative: a fictional logistics platform runs McLeod as its standard TMS and has acquired a freight brokerage on a different TMS, a 3PL warehouse on an older WMS, and a drayage company that tracked exceptions in Zendesk and spreadsheets. The integration plan migrates active loads, customers and inventory only.

The operating partner pauses the cancellations and applies the decommission checklist. Full exports include load histories, EDI logs, exception notes and Zendesk threads with their ticket IDs. Legal finds that the warehouse's customer contracts carry strict confidentiality on shipment data, and that the brokerage's carrier agreements say little about data use.

The archives go to read-only platform storage with manifests. The brokerage archive becomes a candidate for a metadata fit check; the warehouse archive is kept for operations and claims only; the drayage spreadsheets are linked to their tickets before the old Zendesk instance is closed.

How SourceX approaches legacy archives#

SourceX assesses legacy archives through a metadata fit check, so nothing is shared at the start. SourceX does not host large archives: multi-TB datasets remain on company-controlled storage or travel on encrypted drives.

Archives that proceed go through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, with each acquired entity reviewed as its own supplier. The SourceX Evidence Packet then records provenance, licensing rights, permitted use, the privacy record and release authorization.