Systems and records
Standardizing systems across portfolio companies without losing history
By SourceX Editorial · Updated
Short answer
Portfolio company system standardization keeps history intact when it follows four steps: inventory each company's systems and records, archive each company's full history in open formats before cutover, standardize forward with open work only, and keep ID maps linking legacy records to new ones. Archive first, migrate second, cancel last.
Key takeaways
- Archive each company's full history before cutover, then migrate only open work to the shared platform.
- Each operating company still owns its records after standardization, so keep archives separated by legal entity.
- ID maps between legacy and new records make an archive usable for diligence, claims and analysis.
- Do not cancel a legacy subscription until its archive has been verified against record counts.
- Archived operating history can support later value-creation work, including a data licensing review.
Why standardization programs lose history#
Standardization programs lose history because migration budgets are sized for go-live, not for the past. Integration teams move open customers, open orders and current items to the shared ERP or CRM, then cancel the legacy subscription to capture the savings that justified the project.
The losses show up later. A customer disputes a warranty and nobody can find the original job. A buyer's diligence team asks for order and margin history by customer and receives a patchwork. An add-on's support history, the best record of how its product actually failed, sits in a cancelled help desk account.
Field mapping causes quieter damage. Status codes, custom fields and notes that do not fit the shared platform's design get dropped, so even migrated records lose the context that made them useful.
The four-step sequence#
The four-step sequence separates preserving the past from running the future, so each company's history is captured before any system is switched off.
The order matters. Archiving before migration lets the integration team be strict about what it carries forward, because nothing left behind is lost. It also shortens the migration, since only clean, current records need mapping and testing.
- Inventory: list every system at each company, the record families it holds, years of history, record counts, owners, contracts and renewal dates.
- Archive: export each company's full history from every legacy system in open formats, with attachments and a data dictionary, into storage the operating company controls.
- Standardize forward: migrate open work and the master data needed to run the business onto the shared platform, using its standard design.
- Keep ID maps: record the legacy system, legacy ID and new ID for every migrated record, and store the map with the archive.
What to migrate and what to archive#
The split between migrating and archiving follows one rule: migrate what the business must transact on, archive what it must be able to look up. Most record families have both halves.
The archive column is not a dumping ground. Each archive gets an index naming the system, the date range, the objects included, record counts and anything deliberately left out.
| Record type | Migrate to the shared platform | Archive with full history |
|---|---|---|
| Customers and suppliers | Active accounts with current terms | Inactive accounts and full contact and activity history |
| Orders, jobs and projects | Open orders, open jobs and work in progress | Closed orders, jobs and projects with lines, notes and changes |
| Items and parts | Active items with current costs and revisions | Obsolete items and full revision and cost history |
| Financials | Opening balances and summarized prior periods | Transaction-level ledger detail for every legacy period |
| Support and service | Open tickets and active service contracts | Closed tickets with comments, attachments and resolutions |
| Engineering and product | Open issues and active repositories | Closed issues, pull request reviews and release history |
Building ID maps that survive the next deal#
ID maps survive the next deal when they are plain tables stored with the archive, not logic buried in an integration tool. Each row should carry the operating company, the legacy system, the legacy record type, the legacy ID and the new ID.
Add a legacy ID field to migrated records on the shared platform as well. A user can then jump from a customer or item in the new system to its archived history without asking IT. Map users and employees too, because archived records refer to people by system user IDs that mean nothing once accounts are deleted.
Prefix or partition by company. After several add-ons, the same customer number or item code can exist in more than one legacy system, and an unprefixed map will merge records that should stay apart.
How to verify an archive before cancelling a legacy system#
An archive is verified when someone other than the person who exported it can answer real questions from it without the legacy system. Make that test a gate in the cutover plan, with a named sign-off, before the cancellation notice goes to the vendor.
Keep the verification notes with the archive. A future buyer, lender or auditor will ask how the company knows the archive is complete, and a dated checklist answers that better than anyone's memory.
- Record counts per object match the legacy system's own reports for each year.
- A sample of closed orders, jobs or tickets opens with their lines, notes and attachments intact.
- Every coded field, such as status, reason or item class, resolves through the data dictionary.
- A finance user can rebuild a past period's revenue by customer from the archive alone.
- ID maps link a sample of migrated records back to their archived history.
Who owns each archive?#
Each operating company owns its own archive, even when a shared services team runs the systems. Standardization changes where records are processed, not which legal entity holds them or which customer contracts govern them.
Check credit agreements and investor documents before reusing archived data beyond running the business, for example by licensing it. Some contain covenants on intellectual property or asset transfers that require consent.
| Question | Who usually decides | Where to record it |
|---|---|---|
| Where the archive is stored and who can access it | Operating company leadership with group IT | Archive index and access policy |
| How long each record family is kept | Operating company, advised by finance and counsel | Retention and deletion schedule |
| Whether records can be reused or licensed | Operating company signer, with sponsor consent where required | Approval record for each use |
| When a legacy system is cancelled | Integration lead, after archive verification | Cutover checklist with record counts |
Illustrative: a buy-and-build platform of four distributors#
Illustrative: a fictional industrial distribution platform has acquired four regional distributors. The platform company runs NetSuite; the add-ons run Epicor, Acumatica, SAP Business One and an older on-premises ERP. The operating partner wants one ERP and one CRM across the group.
The integration team inventories all four companies first. Each add-on's history, including orders, quotes, returns, supplier exceptions and customer notes, is exported with a data dictionary into storage owned by that company. Open orders, active customers and active items migrate to NetSuite with a legacy ID on every record, and the ID maps sit in each company's archive.
Later, when the group reviews which companies hold licensable operational records, two of the add-ons can be assessed from their archive indexes alone. The legacy systems were cancelled long before, but nothing that mattered went with them.
How SourceX fits a standardization program#
SourceX fits a standardization program at the archive step. The inventory each company builds for migration is close to the metadata SourceX uses in Supply, the first step of the SourceX five-step transaction, and the SourceX Enterprise Data Value Framework helps rank which archives hold connected records with decisions and outcomes.
Each operating company remains a separate supplier with its own rights review, approval and SourceX Evidence Packet. The sponsor coordinates; the company that holds the records decides what, if anything, is licensed.
Frequently asked questions
Should we standardize before or after the next add-on acquisition?
Run the inventory and archive steps for each company as soon as it joins, even if standardization comes later. Archiving early protects history from departing staff and lapsed subscriptions, and it makes each later cutover smaller and safer.
How long should legacy systems stay available after cutover?
Long enough to verify the archive against record counts and to finish any period-end processes that still depend on them. After that, a verified archive with ID maps usually replaces the need for a live legacy system. Retention needs are confirmed with finance and counsel.
Can a shared services team hold every company's archive?
Yes, as a custodian, provided archives stay separated by legal entity and access follows each company's policy. Mixing archives in one undifferentiated store makes rights reviews, deletion requests and future divestitures much harder.
What happens to an archive when a portfolio company is sold?
The archive normally goes with the company that owns the records, along with its ID maps. Keeping archives separated by entity from the start turns a divestiture into the transfer of a folder rather than a data extraction project.
Does standardization help or hurt data licensing later?
It helps when history was archived first, because the archive is complete and indexed. It hurts when only open records were migrated and the legacy systems were cancelled, because the connected history buyers look for no longer exists.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.