What to do with acquired companies' old systems in a buy-and-build

Why do legacy systems pile up in a buy-and-build?#

Legacy systems pile up in a buy-and-build because every add-on arrives with its own ERP, CRM, helpdesk, email tenant and shared drives. The platform standardizes on one stack, and the integration plan focuses on what the business needs to run tomorrow: open orders, active customers, current price lists and receivables.

History rarely gets the same attention. Closed orders, resolved service tickets, old quotes and years of email sit in systems nobody uses daily, and they vanish quietly when a subscription lapses or a server is decommissioned. By the third or fourth add-on, the platform may hold only a thin slice of what the combined companies once knew.

The four decisions for each legacy system#

Each legacy system should get one of four decisions, recorded in the integration tracker with an owner and a date. The decision is per system, not per company, because an add-on's helpdesk and its ERP often deserve different treatment.

Review for value is not a fifth workstream bolted onto integration. It is a short check, run on metadata, that asks whether the history in a system is deep, linked and rights-clear enough to be worth documenting before it is archived or retired.

Which rights checks come before any decision?#

Rights checks come before any decision because what the platform may do with an add-on's history depends on contracts the platform did not write. The structure of the acquisition matters too: a stock purchase keeps the add-on's records and obligations inside the acquired entity, while an asset purchase transfers only what the agreement lists.

Run the checks once per add-on and reuse them across that add-on's systems. Record each answer in the inventory rather than in an email thread, so the next person to touch the archive can see why it was kept or released.

• 1Vendor terms: export rights, data formats, and what happens to data after termination under the add-on's plan.
• 2Customer contracts: confidentiality clauses, data use limits and return or deletion obligations, especially in national account agreements.
• 3Privacy notices in force when the records were collected, including website and portal notices.
• 4Employee notices and handbooks that govern email, chat and call records.
• 5Supplier and distributor agreements that restrict use of pricing or volume information.
• 6Deal documents: purchase agreement schedules, excluded assets and any transition services agreement covering system access.

Why combined history across add-ons can be worth more#

Combined history across add-ons can be worth more because several companies in the same trade cover more regions, customer types, product lines and years than any one of them alone. For an AI developer studying how distributors resolve order exceptions or how contractors diagnose callbacks, breadth across operators is a real advantage.

The gain only holds when fields can be mapped to a common structure and each add-on's rights position is clear. A combined package is only as clean as its weakest component, so carve out an add-on with unresolved restrictions rather than letting it hold up or contaminate the rest. Keep a source label on every record so each company's provenance stays visible after consolidation.

How to sequence the work after each close#

The sequence after each close should protect history first and make decisions second. Most of the damage happens in the first renewal cycle after closing, when subscriptions are cancelled to save cost before anyone has confirmed what they hold.

Carve-outs need one extra step. When an add-on is bought from a larger seller, its records may sit in the seller's shared systems and reach the buyer only through a transition services agreement. Agree the export scope, formats and date range in that agreement before signing, because leverage to ask for history fades once the service period starts running down.

• 1Step 1: list every system at the add-on with its owner, admin account, contract end date and record families.
• 2Step 2: freeze deletion and auto-purge settings until decisions are made.
• 3Step 3: export full history in the vendor's native format and an open format, and confirm the files open.
• 4Step 4: document what each export contains, the date range and who produced it.
• 5Step 5: map live records into the platform and assign each legacy system a decision.
• 6Step 6: give notice of non-renewal only after exports and decisions are signed off.

Illustrative: an industrial distribution platform with three add-ons#

Illustrative: a fictional industrial distribution platform runs on Acumatica and acquires three regional distributors. One runs Epicor, one runs SAP Business One, and the smallest uses an aging on-premise order system with a custom database maintained by a retired contractor.

The integration team migrates open orders, active customers and current pricing into Acumatica. Full order histories from Epicor and SAP Business One are exported and archived in read-only storage. The on-premise system is flagged for value review because it holds many years of order exceptions with free-text notes on substitutions, short shipments and credit memo reasons. One add-on's agreement with a large OEM customer restricts use of that customer's order data, so those accounts are carved out of any future package, and the rest is documented before the server is shut down.

Mistakes that erase history#

The most common mistake is letting finance cancel subscriptions at renewal because the system looks unused. The second is letting the departing owner's admin credentials lapse, which can leave nobody able to request a full export.

Vendor post-termination windows are short and vary by product. HubSpot's Product Specific Terms say that for hubs such as Sales and Service it will not provide any access to Customer Data after termination or expiration. Freshworks partner support says Freshdesk permanently deletes an account's data 14 days after the subscription end date and that an export can take up to 10 business days. Atlassian documents a 60-day retention period for deactivated paid cloud sites. Check the add-on's current terms and order form, because these windows change.

Other losses come from migrating only the last year or two of transactions, purging old email tenants to save license seats, and storing exports with no documentation of what they contain. An archive without a description is often treated as junk and deleted at the next cleanup.

How SourceX reviews legacy archives in a roll-up#

SourceX treats each add-on's archive as a candidate package within the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The Supply step starts from metadata such as system names, date ranges and record families, so no files are shared during the initial assessment.

Archives stay in the platform's own storage or ship on encrypted drives; SourceX does not host multi-terabyte datasets. Where a package combines several add-ons, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each source company.