Software companies
Merging Salesforce orgs after an acquisition: keep the old history
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
When you merge Salesforce orgs after an acquisition, current records migrate well but much of the acquired org's history usually does not: field history, stage changes, original created dates and owners, email messages, feed comments and old files. Archive the whole acquired org before the merge, then migrate only what the combined team needs day to day.
Key takeaways
- Standard data loads create new records, so original created dates and creators are lost unless preserved deliberately.
- Field history and opportunity stage history rarely move with the records they describe.
- Archive the acquired org completely before any record is deduplicated, merged or deleted.
- Keep the old record IDs on every migrated record so the archive and the combined org stay linked.
- Check the acquisition agreement and the acquired company's customer contracts before reusing its data for a new purpose.
Why do Salesforce org merges lose history?#
Salesforce org merges lose history because a migration inserts the acquired company's records as new records in the surviving org. The new org stamps them with its own created date, its own record IDs and whichever user ran the load, and the system-generated history that described each record's past stays behind.
Deduplication adds a second layer of loss. When the acquired company's accounts and contacts are merged into existing ones, the losing record's field values, owner and activity links can be overwritten or reparented. A rushed cleanup after cutover can then delete the only remaining trace of a customer's earlier relationship with the acquired company.
Automation in the surviving org can also rewrite history on arrival. Flows, assignment rules and email alerts fire on inserted records, reassigning owners, changing stages or emailing customers about deals that closed long ago. Bypass automation for the migration user and test the load in a sandbox first.
What history usually does not migrate#
The history that usually does not migrate is the history Salesforce generates itself: field changes, stage changes, case changes and audit fields. Some of it can be preserved with extra work, and some can only be kept in an archive linked by record ID.
| History | Why it gets left behind | How to keep it |
|---|---|---|
| Field history tracking | System-generated; normal loads cannot insert it as native history | Export to the archive with parent record IDs |
| Opportunity stage history | System-generated, like field history | Export; optionally summarize into a custom object |
| Original created date and creator | Set automatically on insert unless a special permission is enabled before loading | Enable the permission before loading, or store originals in custom fields |
| Activities and email messages | High volume, and older activities may be archived by the platform | Export with parent IDs and the original dates |
| Feed posts and comments | Often skipped as low priority | Export where they hold deal or case decisions |
| Files and attachments | Storage limits and ownership mapping | Export with links to their parent records |
| Case history and case comments | System-generated or tied to old users | Export with case numbers and IDs |
| Closed-lost reasons and picklist values | Values not mapped in the new org | Map them, or archive the old values with definitions |
Archive-before-merge checklist#
An archive-before-merge checklist makes sure the acquired org can be reconstructed after it is gone. The archive also needs metadata, because a list of field values is hard to read years later without the field definitions, picklists and record types that gave them meaning.
Run the checklist while the acquired org is still fully licensed and its admins are still employed; both tend to disappear soon after closing. Timing matters for a second reason. Salesforce's Main Services Agreement says that after termination, customer data is made available for export only if the customer asks within 30 days, after which Salesforce has no obligation to keep it. The acquired company's own contract may differ, so check its order forms.
Salesforce's built-in Data Export Service is a useful baseline but not the whole archive. Trailhead describes manual exports every 7 days in Enterprise, Performance and Unlimited Editions and every 29 days in Professional Edition, with options to include attachments, documents and Salesforce Files. The export arrives as zip files of CSVs that must be downloaded promptly, because the files are deleted after a short window.
- Freeze configuration changes and bulk deletions in the acquired org.
- Inventory objects, record counts and storage use, including custom objects.
- Export every standard and custom object with record IDs, including history objects, using the Data Export Service or a data loader.
- Include files, attachments and email messages, with their parent record IDs.
- Download each export zip as soon as the notification email arrives.
- Export metadata: fields, picklist values, record types, validation rules and page layouts.
- Capture the user list with roles, profiles and active status, so owners can be identified later.
- Reconcile export record counts against the org's own reports.
- Put the archive somewhere the company controls, name its owner and record how long each object will be kept, and only then begin deduplication, migration and decommissioning.
Deciding what migrates and what stays archived#
What migrates should be decided by what the combined team will use, while everything else stays in the archive with a link. Migrating every closed opportunity and every old email clutters the surviving org, consumes storage and makes reports harder to trust.
A legacy ID field on each migrated record is the bridge. With it, a sales rep looking at a migrated account can find its old stage history, emails and cases in the archive without anyone loading them into the new org.
| Record type | Migrate to the combined org | Keep in the archive |
|---|---|---|
| Active accounts and contacts | Yes, with legacy IDs | Pre-merge versions and owners |
| Open opportunities | Yes | Stage history |
| Closed opportunities | Summary fields only, if needed for reporting | Full records, stage history and notes |
| Open cases | Yes | Case history |
| Closed cases | Usually not | Full records and comments |
| Activities and emails | Recent ones on active accounts | All, with parent IDs |
Rights questions an acquisition adds#
An acquisition adds rights questions because the acquired company's CRM was built under its own contracts and notices. Its customer agreements may restrict how customer information is used or require deletion on request, its privacy notice told contacts how their data would be used, and the deal structure decides which entity now holds the records.
Merging orgs to serve the same customers is one purpose; reusing the data for something new, such as analytics products or licensing, is another. Those uses are assessed with counsel against the acquisition agreement, the inherited contracts and the privacy laws that may apply. This is general information, not legal advice.
Illustrative: a fleet maintenance software company absorbs a rival#
Illustrative: a fictional fleet maintenance software company acquired a smaller rival that had run its own Salesforce org for years, with renewals, support cases and partner deals. The integration partner planned to migrate active accounts and open opportunities, then delete the old org after cutover.
The COO added an archive step. The export captured opportunity stage history showing how renewals had been negotiated, closed-lost reasons, case comments and email threads, all keyed to legacy IDs stamped on the migrated accounts. Renewal managers could trace each acquired customer's history from the combined org, and the archive was kept under a named owner instead of disappearing with the old licenses.
How SourceX approaches merged CRM history#
SourceX approaches merged CRM history as a record of how deals and customer relationships actually progressed, which is why stage history, notes and activities matter more than the current snapshot. Under the SourceX Enterprise Data Value Framework, human-generated signal and recency raise value, while rights questions inherited from an acquisition can narrow what is usable.
An acquired org's archive is handled as a separate package from the acquirer's own CRM, with its own Rights step, because inherited contracts and privacy notices differ. The SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, starts from metadata such as objects, years covered and record types, and nothing leaves the company until it approves.
Frequently asked questions
Should we merge the orgs or keep both running?
It depends on how closely the teams will work together. Running both for a while lets sales and support continue without disruption, but every month of parallel orgs adds license cost and reporting gaps. Whatever the timing, archive the acquired org first, so the decision about when to switch it off is not also a decision about losing history.
Can field history be loaded into the new org as native history?
Not through normal data loads, because field history records are generated by the platform when values change. Teams usually keep field history in an external archive linked by record ID, or summarize key changes into a custom object. Check Salesforce documentation and your integration partner's approach before promising anything more.
How long should we keep the acquired org after cutover?
Keep it at least until the archive has been verified against the org's own counts and a retention decision has been recorded for each object. Legal holds, open disputes and customer contract obligations can extend that. The point of decommissioning is lower cost, not deletion of history nobody has reviewed.
Who owns the acquired company's CRM data after closing?
That depends on how the deal was structured. In a stock purchase the acquired entity usually still holds its records; in an asset purchase, the agreement lists what transferred. Customer contracts may also limit transfer or reuse. Counsel should confirm which entity holds the data before it is merged or reused.
Do we need to tell the acquired company's customers?
Possibly. If customer or contact data will be used differently than the acquired company's privacy notice described, notice updates or consent may be required under the laws that apply. Customer contracts can add their own notice duties. Counsel can advise on what the integration plan triggers.
Sources
- Under the Salesforce Main Services Agreement, if the customer asks within 30 days after termination or expiration, SFDC makes Customer Data available for export or download; after that 30-day period SFDC has no obligation to maintain or provide Customer Data. Source
- The Data Export Service allows a manual export once every 7 days (weekly) or every 29 days (monthly); weekly exports are available in Enterprise, Performance and Unlimited Editions, while Professional and Developer Editions can generate backup files only every 29 days. Source
- Salesforce's Data Export Service has options to include images, documents and attachments and Salesforce Files, and the export arrives as zip files of CSVs, split into multiple files when large. Source
- Salesforce data export zip files are deleted 48 hours after the notification email is sent, not counting weekends. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.