Systems and records
After an acquisition: archive or migrate the acquired company's systems?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
After an acquisition, archive the acquired company's systems first and migrate only what the combined teams need to operate. A complete, owner-controlled export of each CRM, helpdesk, ERP and code system, indexed by original IDs, protects history whatever the integration plan becomes; migration then carries active records rather than the whole past.
Key takeaways
- Archive every core system before deciding whether to migrate it; the decision can wait, the export cannot.
- Migrate active records into group systems and keep closed history in a searchable archive keyed by original IDs.
- Code repositories are the exception: move them whole, with full commit history, rather than archiving snapshots.
- Customer data stored inside an acquired software product is not the same as the company's own operating records.
- Freeze deletions and retention changes from day one, and take admin access away from departing staff.
Why archive first?#
Archiving first means taking a complete, verified export of each acquired system before anyone decides to migrate, merge or retire it. Integration plans change, vendor renewals arrive on their own schedule and the people who understand the old systems leave, so the export is the only step that keeps every later option open.
Migration and archiving answer different needs. Migration serves the teams who will work in the group's systems tomorrow. Archiving serves everyone who will ask about the past: finance, legal, customer success, a future buyer of the business and any review of what the records are worth.
An archive-first default also takes pressure off the migration. When closed history is safe elsewhere, the migration can carry only active records, which makes it smaller, cleaner and easier to validate.
Decision rules by system type#
Decision rules by system type give integration teams a default for each kind of system while leaving room for exceptions. The table sets the default and what the archive must contain so nothing important is lost when the source system is retired.
Write the exceptions down as carefully as the rules. A helpdesk may stay in place because the acquired product keeps its own support team, or a CRM move may wait because the brand keeps selling under its own name. Recording the reason for each exception lets the next add-on start from the same rules instead of a fresh debate.
| System | Default | Migrate when | The archive must include |
|---|---|---|---|
| CRM | Archive full history; migrate active accounts and open deals | Sales will work the same accounts from the group CRM | Activities, emails, notes and associations, with record IDs |
| Helpdesk | Archive full history; migrate open tickets and recent history | Support moves to the group helpdesk | Full transcripts, internal notes, tags and attachments |
| ERP and accounting | Archive full history; convert balances and open items | The back office moves to the group ERP | Detailed transactions, master data and the ID crosswalk |
| Code repositories | Move whole, with full commit history | Always, into the group's code host | Not a snapshot: branches, tags, reviews and linked issues |
| Issue tracker | Keep in place or move whole with the code | Engineering keeps building the product | Comments, change history, links to commits and releases |
| Team chat and email | Archive under the retention policy | Rarely | Channel history and departed staff mailboxes, as policy allows |
What changes for software acquirers and holding groups#
Software acquirers and holding groups usually keep the acquired product running, so consolidation focuses on back office systems while engineering systems stay intact. A group may move billing, CRM and finance onto group standards and leave product development, support tooling and documentation largely where they are.
One distinction runs through every decision: the acquired company's own operating records are different from customer data inside the product it sells. Tickets, code reviews, incident records and sales history are company records. Data that customers store in the product is held under customer contracts and is generally not the acquirer's to archive for other purposes or to license.
Treat engineering history as an asset to keep whole. Moving repositories and issue trackers with full history preserves the link between a reported problem, the discussion, the fix and the release, which is exactly what a snapshot loses.
Check what the move tool actually carries. A git clone keeps commits, branches and tags, but review discussions live in the code host. GitLab, for example, says its project export files should not be used as backups, and that after import or export only the latest diff version and latest pipeline in merge requests are visible. Where earlier review rounds matter, pull them through the API before the old host is closed.
Rights do not always move with the data#
Rights to use acquired data depend on the deal structure and the contracts that come with it, not on who holds the files. In a stock purchase, contracts usually stay with the acquired entity; in an asset purchase, accounts, contracts and data may need to be assigned, and some vendor terms restrict transfer.
The acquired company's privacy notices and customer agreements continue to govern the personal and customer data it collected. Before merging records into group systems, check whether those notices and contracts permit that use, and keep each entity's archive separate until counsel confirms what can be combined. This is general information, not legal advice; review each acquisition with counsel.
| Deal structure | What usually happens to systems and contracts | What to check |
|---|---|---|
| Stock purchase | Accounts and contracts stay with the acquired entity | Change-of-control clauses in vendor and customer contracts |
| Asset purchase | Accounts, contracts and data may need to be assigned | Whether vendor terms allow assignment, and customer consent needs |
| Merger into a group entity | Records move to the surviving entity | Which privacy notices and contracts govern the merged records |
| Carve-out from a parent | Records may stay in the parent's systems | Data access, export help and retention in the transition services agreement |
Sequencing system work after close#
System work after close follows a sequence that protects history before anything changes. The steps fit most add-on acquisitions, whatever their size.
- Freeze: pause deletions, purges and retention changes in every acquired system.
- Secure: move admin access to group IT and remove it from departing staff and contractors.
- Inventory: list systems, plans, renewal dates, export paths and record IDs.
- Export: take full exports, including attachments and media, by record type and year.
- Verify: reconcile counts and spot-check records end to end.
- Decide: apply the decision rules system by system and record each decision.
- Migrate and retire: move active records, then retire systems only after sign-off.
Illustrative: a software group absorbs a fleet maintenance vendor#
Illustrative: a fictional vertical software holding group acquires a fleet maintenance software company. The group standard is one CRM and one finance system across its businesses; the acquired company runs its own CRM, a helpdesk, an issue tracker and a code host.
The group COO applies the archive-first default. CRM and helpdesk history is exported in full, with internal notes and links to engineering issues; active accounts and open tickets move to group systems. Repositories move whole into the group's code host, and the issue tracker stays in place for the product team. Customer fleet data inside the product is left out of the archive entirely.
When the group later screens its businesses for licensable records, the acquired company's support tickets, linked issues and fixes are intact and documented, and the rights review starts from a clear line between company records and customer data.
Mistakes that destroy acquired history#
The mistakes that destroy acquired history are usually administrative, not technical. They happen when nobody owns the old systems in the gap between close and integration.
The common ones: cancelling a subscription at renewal before the export is verified; migrating everything into the group CRM and breaking the links between activities, contacts and deals; deleting a team chat workspace to save seats; leaving a former founder with the only admin login; and losing the ID crosswalk when the migration consultant moves on.
How SourceX works with acquired-company records#
SourceX treats each acquired company as its own supplier, with its own fit check, rights review and signer, even when the group coordinates the work. The first assessment uses metadata only, such as systems, record types and years of history.
For records that proceed, the SourceX Evidence Packet documents provenance through the acquisition, the licensing rights the entity holds, permitted use, the privacy record and the release authorization, so the group and any future buyer can see exactly what was approved.
Frequently asked questions
How long should acquired systems stay running?
Keep them until exports are verified, each system's decision is recorded and no legal hold, audit or customer obligation needs the original. Contract renewal dates then set the practical timing. Negotiating a brief read-only extension is often simpler than rushing an export against a renewal date.
Should we merge the acquired CRM into ours?
Merge active accounts, open deals and the contacts sales will use. Keep the full activity history in the archive, keyed by original record IDs, and store those IDs on merged records. Merging all history tends to break associations and clutters the group CRM with records nobody opens.
What happens to systems under a legal hold?
A legal hold overrides the retirement plan. Records under hold must be preserved as required, which may mean keeping the original system or a forensically sound copy. Involve counsel before changing, exporting or retiring any system named in a hold.
Can we license data from a company we just acquired?
Possibly, once rights are clear. The acquired entity's contracts, privacy notices and vendor terms decide what can be licensed, and the entity usually signs as the supplier. Starting from a verified archive makes that review much faster.
Who should own the acquired company's archive?
Group IT usually holds it, with a named business owner at the acquired company for questions about content. Keep it separate from group systems, restrict access by role and record the retention rules agreed with counsel.
Sources
- GitLab says project export files should not be used to back up data, and after import or export only the latest diff version and latest pipeline in merge requests are visible. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.