CRM and helpdesk consolidation after add-ons: keep the full history

What should CRM consolidation after an acquisition keep?#

CRM consolidation after an acquisition should keep two things: a working set of live records in the platform's system and a complete history of each add-on's old CRM and helpdesk. Most integration plans deliver the first and quietly lose much of the second.

The reason is scope. A consolidation project is judged on whether sales and support teams can work in one system from cutover, so the migration covers active accounts, open opportunities, open tickets and current contacts. Closed tickets from earlier years, lost deals and the notes explaining why a customer churned rarely make the cut, and the old subscription is then cancelled to save money.

That history explains how the acquired business actually ran: which issues recurred, how fixes were found, which objections lost deals. It matters for integration reviews, warranty and dispute questions, and later for any AI project or data license that needs records with outcomes.

What do migration tools usually drop?#

Migration tools usually drop the context around a record rather than the record itself. A ticket arrives in the new helpdesk with its subject and public replies, but without the internal notes agents wrote to each other, the tag that marked the resolution, or the link to the engineering issue that fixed it.

Check each element below with a test migration before signing off on scope. Behavior varies by tool, plan and mapping configuration, so treat the table as a list of questions to test, not a forecast.

The pre-cutover export checklist#

The pre-cutover export is separate from the migration and runs before it. Treat it as a full copy of each add-on's CRM and helpdesk in a format the company controls, whatever the new system ends up importing.

The configuration export is the step most often skipped. Without the old picklist values and tag definitions, a resolution code written as a short internal abbreviation means nothing to anyone who joins after the integration.

• 1Confirm owner-level admin access to each legacy instance, not a departing employee's login.
• 2Export every object, including closed tickets, closed-lost deals, archived contacts and custom objects.
• 3Export ticket threads with internal notes and side conversations, not only the public conversation.
• 4Export logged emails, call notes and meeting activities, which often sit in separate activity tables linked to accounts and deals.
• 5Download attachments as files and keep the mapping from each file to its ticket or deal.
• 6Export audit logs, status and stage history, and field history wherever the plan allows.
• 7Capture link tables: ticket to deal, ticket to engineering issue, contact to account.
• 8Save configuration: field definitions, picklist values, tags, macros, workflows and SLA policies.
• 9Compare record counts and the earliest record dates in the export against the live instance.
• 10Store the export read-only, labeled with source company and export date, with a named owner.

How deduplication can erase history#

Deduplication erases history when duplicate accounts and contacts are merged without a snapshot, and it is where consolidation does the most silent damage. Add-ons often share customers with the platform and with each other, so the same account appears in two or three CRMs. When duplicates are merged, one record survives with a single set of field values. Values from the other record that were not chosen are discarded, related activities are reattached in ways that are hard to trace, and the merge is often difficult or impossible to reverse.

Save a pre-merge snapshot of every record involved, and build a crosswalk table that maps each legacy record ID to its new ID. The crosswalk is how anyone later reconnects an old ticket thread, attachment or invoice to the consolidated account.

Add a source-entity field to every migrated record naming the legal entity that created it. The tag answers questions that arrive long after integration: which privacy notice applied when the record was collected, which customer contract governed it, and which entity holds the rights if the records are ever reviewed for licensing.

Migrate, archive or both: a rule by record type#

The rule by record type is simple: live records migrate into the platform system, history goes to the archive, and some records belong in both. Deciding by record type keeps the scoping debate short.

Keep the archive in storage the company controls, readable without the old vendor, and listed in the retention schedule, so it is neither kept forever by accident nor deleted by a cleanup script.

Illustrative: three add-ons, one CRM#

Illustrative: a fictional buy-and-build platform in field service software acquires three smaller vendors. One runs Zendesk with Jira links, one runs a HubSpot portal for both sales and support, and one runs Salesforce with email-to-case. The platform standardizes on Salesforce.

The integration team scopes the migration to active customers and open cases. Separately, the CTO's team exports each legacy system in full, including internal notes, Jira links and closed-lost deals, and builds a crosswalk before the deduplication run merges overlapping customer accounts. Every record carries a source-entity tag.

Support works in one system from cutover, and the old subscriptions are cancelled only after export counts match. Later, a warranty dispute is settled from the archive. When the group screens its companies for data licensing, one add-on's linked ticket-to-fix history qualifies for review, while another's is set aside because its customer contracts restrict reuse.

How SourceX treats consolidated histories#

SourceX reviews consolidated archives at the level of the entity that created the records. In the Supply step of the SourceX five-step transaction, the source-entity tag and crosswalk let each add-on's history be assessed on its own, and nothing is shared during the initial assessment.

If a package proceeds, the SourceX Evidence Packet records provenance, including the original system and the migration path, along with licensing rights, permitted use, the privacy record and release authorization. A clean pre-cutover export makes that provenance straightforward to document.