Private equity and portfolios
Consolidating legacy archives after a buy-and-build: a playbook
By SourceX Editorial · Updated
Short answer
To consolidate legacy data after a buy-and-build, keep one archive-by-acquisition register: a row for every legacy system at every acquired entity, recording its records, date coverage, export status, storage location, governing terms and decision owner. Freeze, capture and verify each system before retirement, and never let a migration project be the only record of history.
Key takeaways
- An archive-by-acquisition register gives each legacy system at each acquired entity its own row, owner and status.
- Record the governing terms beside each archive, because privacy notices, customer contracts and vendor terms stay attached to the records.
- Verify an archive by reconciling counts, opening attachments and tracing links before the source system is shut off.
- The provenance facts captured in the register are the same facts a future licensee, auditor or acquirer will ask for.
What is an archive-by-acquisition register?#
An archive-by-acquisition register is a single table, owned at the platform level, that lists every legacy system inherited through each add-on and tracks what happened to its records. It turns a scattered integration effort into one place an operating partner, CFO or acquirer can read.
Most buy-and-build platforms track integration by workstream: finance cutover, CRM migration, email domains. Those trackers close when the new system goes live. The register stays open, because its job is to show that history from every acquired company still exists, where it sits and under what terms.
The register complements a decommission checklist rather than replacing it. A checklist governs one shutdown; the register shows the whole set of archives across every add-on, which is what a lender, auditor, licensee or eventual buyer wants to see.
The register template: columns and example entries#
The register template needs enough columns to answer who, what, where and under which terms for each archive, and no more. Keep entries factual and short, and link to the underlying contracts and exports rather than pasting them in.
| Column | What to record | Example entry |
|---|---|---|
| Acquired entity | Legal name and closing date | Add-on C, its legal entity name and closing month |
| Deal structure | Stock purchase, asset purchase or merger | Asset purchase |
| Legacy system | System name, vendor and instance | FieldEdge, single instance |
| Record families | Types of records held | Service calls, estimates, invoices, equipment history |
| Date coverage | First and last record dates | From system adoption to cutover |
| Export status | Not started, exported or verified | Verified |
| Archive location and format | Storage path and file formats | Platform cloud storage, CSV plus attachments |
| Link keys preserved | IDs that connect records | Customer, location, job and invoice IDs |
| Governing terms | Notice versions, customer contracts, vendor terms | Seller's privacy notice and vendor terms version |
| Decision owner | Person who approves access and deletion | Platform COO |
| Retention rule | Schedule that applies | Platform retention policy, warranty records class |
| Licensing status | Not reviewed, in scope or excluded | Not reviewed |
Six phases from freeze to retirement#
The six phases below take each legacy system from active use to a verified archive and a documented shutdown. Run them per system, and record the current phase in the register so the platform view stays accurate.
Capture is where most history is lost. Migration teams map the fields the new system needs and leave the rest behind, including free-text notes, internal comments and status changes, which are often the records that explain why decisions were made.
- Freeze: stop structural changes to the legacy system once the migration plan is set, so the export reflects a stable schema.
- Capture: export all tables, attachments, notes and audit logs, not only the records selected for migration.
- Verify: reconcile counts, open sample attachments and trace a few records end to end.
- Document: attach the data dictionary, governing terms and export method to the register row.
- Decide: assign the decision owner and retention rule, and flag records that must be deleted or segregated.
- Retire: cancel the subscription or decommission the server only after verification is signed off.
How to verify an archive before the source system goes away#
Archive verification proves an export is complete and usable while the source system can still be checked against it. Once the subscription lapses or the server is wiped, gaps cannot be fixed.
Assign verification to someone who used the system, such as a former dispatcher or office manager, alongside IT. They know which records should exist and will notice when a familiar field is missing.
| Check | How to run it | Pass condition |
|---|---|---|
| Record counts | Compare totals per table with reports run in the source system | Counts match, or differences are explained |
| Attachments | Open a sample of files from different years | Files open and match their parent records |
| Linkage | Trace sample records from customer to job to invoice | Every link resolves using preserved IDs |
| Notes and history | Confirm free-text fields and status changes exported | Text is complete, not truncated |
| Readability | Ask someone outside IT to find a known record | Record found without the old system |
When to open and update a register row#
A register row should open during diligence on each add-on, not after integration starts. The system list from diligence becomes the first draft of the rows, and the purchase agreement tells you which entity holds the records and under which deal structure.
After closing, the register only stays useful if specific events force an update. Tie updates to those events rather than to a calendar, so changes are captured when they happen.
Vendor renewal dates deserve the closest watch, because retrieval rights can end with the subscription. HubSpot's Product Specific Terms, for example, strongly recommend retrieving Customer Data before the Subscription Term ends and say that for several Hub subscriptions HubSpot will not provide access to Customer Data after termination or expiration. Note each system's retrieval terms in its register row.
- An add-on signs or closes: open rows for every system named in diligence.
- A vendor renewal or cancellation notice arrives: confirm the export phase before the date passes.
- A system is retired, a server is moved or a building lease ends: complete capture and verification first.
- A key employee who ran a legacy system gives notice: record the data dictionary and known quirks before they leave.
- A licensing, audit or legal hold request touches an archive: update the licensing status and decision owner.
Which provenance fields should the register capture?#
The provenance fields a register should capture are the ones that let a later reader trust the archive: where the records came from, how they changed hands and which uses are allowed. Those questions recur in audits, exits and data licenses.
Industry standards point the same way. The Data & Trust Alliance's Data Provenance Standards organize dataset metadata into three groups, Source, Provenance and Use, and describe that metadata as necessary to enable proper dataset selection for AI model training. The Use group includes elements such as consent documentation location, license to use and intended data use.
A register that already records the source entity, deal structure, export method, governing terms and decision owner covers much of that ground. Filling those columns when the archive is made is far cheaper than reconstructing them from former employees later.
Illustrative: a commercial mechanical platform with five add-ons#
Illustrative: a fictional commercial mechanical platform has acquired five regional contractors. The platform runs ServiceTitan. The add-ons arrived on FieldEdge, an older on-premise dispatch system, two QuickBooks files with spreadsheet job logs, and one company that had already moved to ServiceTitan under its own account.
The operating partner asks the platform COO to own the register, with a row per system. The on-premise dispatch server, due to go when its building lease ends, is captured first; verification finds the attachment folder sat on a separate drive, which is recovered before the server is wiped. The spreadsheets are archived with a short data dictionary written by the former office manager.
When the platform later reviews whether its service histories could be licensed, the register answers the first questions quickly: which entities' records exist, under which terms, with which links intact. Two archives are marked excluded because the governing customer contracts restrict reuse.
How SourceX uses an archive register#
SourceX uses an archive register as the starting point of the Supply step in the SourceX five-step transaction. A register lets the fit check run on metadata alone, because it already names the systems, record families, date coverage and governing terms for each acquired entity.
If a package proceeds, the register's provenance and terms columns feed the SourceX Evidence Packet, which documents provenance, licensing rights, permitted use, the privacy record and release authorization. Large archives stay in the platform's own storage.
Frequently asked questions
Who should own the archive register at a platform company?
One named leader at the platform, often the COO, CFO or head of IT, should own the register, with a decision owner listed on each row. Brand or site leaders contribute entries, but a single owner keeps statuses current and approves access and deletion.
Should archives stay in the original vendor's format?
Keep the native export and add an open format such as CSV or a database dump alongside it. Native formats preserve detail; open formats keep the archive readable after the vendor relationship ends. Store attachments with their original file names and parent IDs.
Do we need rows for add-ons we later sold or closed?
Yes, if you still hold their records for legal, tax or warranty reasons, or if the divestiture agreement says who keeps history. Record divested and closed entities with their status so nobody has to reconstruct what happened to their systems.
How does the register help at exit?
Buyers ask where historical records live, whether systems were retired cleanly and whether any data commitments exist. A current register answers with evidence, shows any licenses granted, and reduces the follow-up requests that slow a diligence process.
What if a legacy system can no longer be exported?
Document what remains: reports, backups, printed records or a read-only database copy. Some vendors can restore a lapsed account or provide a final export on request. Record the gap in the register so later reviewers know the coverage limits.
Sources
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups, Source, Provenance and Use, and say this metadata is needed to enable proper dataset selection for AI model training. Source
- The Use group of the Data Provenance Standards includes elements for consent documentation location, license to use and intended data use, among others. Source
- HubSpot's Product Specific Terms strongly recommend retrieving Customer Data before the Subscription Term ends and, for several Hub subscriptions, provide no access to Customer Data after termination or expiration. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.