CRM Migration: Move Contacts, History and Deals While Sales Keep Working

A CRM migration is not complete when the contact file has been imported. It is complete when a salesperson can open a deal, identify the right contact, read previous agreements and understand what needs to happen next.

The objective is to preserve that continuity throughout the transfer. This does not mean promising absolutely no disruption: a controlled pause on updates may be necessary, supported by a temporary procedure for incoming enquiries.

Salesforce’s migration guide includes data, configuration, processes, permissions and integrations, rather than contact records alone. Your migration plan should address that full scope. Source: Salesforce.

1. Define what must keep working

Before exporting anything, list essential sales operations: looking up a customer, updating a deal, retrieving a quotation, assigning a callback and capturing an enquiry from the website.

For each operation, identify the person responsible for testing it, the system available during cutover and the temporary alternative. If an enquiry arrives while CRM updates are paused, where will it be recorded? Who will transfer it afterwards?

Assign distinct responsibilities:

• the sales representative approves field meanings and record usability;
• the technical owner manages extraction, loading and integrations;
• the data owner decides how to handle merges, exclusions and anomalies;
• the coordinator authorises cutover and tells people where to work.

In smaller organisations, one person may cover several roles. Decisions still need an owner, particularly when a technical correction changes information used by the sales team.

2. Build an inventory rather than exporting everything

List the objects in use: companies, people, opportunities, activities, notes, emails, documents, products, quotations and custom objects. Include views, reports, automations and external connections.

For each item, record its source, export format, relationships, owner and intended destination. Classify it as:

• migrating into the operational CRM;
• remaining in an accessible archive;
• being rebuilt in the new platform;
• being excluded following a documented decision.

Twenty recommends reviewing data before transfer, prioritising active contacts, open opportunities and important activities. Selection should nevertheless remain a business decision, rather than automatic deletion based on a record’s age. Source: Twenty.

For a European business, involve the person responsible for privacy in reviewing retention, access and contact preferences. Avoid allowing exports and test environments to become permanent copies without clear ownership. Decide who can access them and how their eventual removal will be recorded.

3. Prepare a data map that can be tested

Mapping should explain how each piece of information changes structure. A useful table includes the source field, destination field, type, transformation, mandatory status and planned validation.

Here is an explicitly hypothetical example:

Preserve a stable source identifier and a cross-reference table linking it to the new identifiers. These will support relationships between objects, error investigation and subsequent updates.

Do not assume that a company name is unique. Different businesses may have similar names, while one organisation may have several locations. Email addresses and domains also require checking before they become matching keys.

Twenty’s documentation calls for mapping fields and identifying format transformations before importing. Source: Twenty.

4. Clean contacts without losing relationships

Deduplication does not mean deleting rows that look alike. First decide which record retains the main information and how associated activities, opportunities and preferences will be consolidated.

Hypothetical example: two contacts share a purchasing department’s generic email address but represent different people. Automatically merging by email would remove a useful distinction. Flag the case for review rather than resolving it blindly.

Standardise telephone numbers, countries, unnecessary spaces and character encoding. Keep the original extraction protected and work on versioned copies. For every merge, record the identifiers involved and the resulting record.

Check the destination’s required formats. Twenty, for example, documents YYYY-MM-DD dates, API names for selection fields and a specific structure for telephone numbers. These are product requirements, not universal rules for every CRM. Source: Twenty.

Where the contact database needs dedicated attention, Contact cleaning and normalisation covers deduplication, correction and standardisation of contact data.

5. Treat historical information as a separate workstream

Before transferring history, distinguish notes, calls, emails, appointments, attachments and status changes. For each category, check what the source system exports and what the destination can actually import.

Capabilities differ. Twenty’s guide includes notes and activities in its import sequence, whereas Clientify describes file imports covering companies, contacts and opportunities, without activity history. Sources: Twenty, Clientify.

For history that cannot be transferred directly, choose an explicit approach: a verified technical route or an accessible archive referenced from the relevant records. Define who can access it and how long it should remain available.

Check authorship, original dates, time zones and customer associations. If the platform cannot preserve an attribute, document the limitation rather than replacing it with invented information.

Attachments need separate checks: Twenty states that they are not included in CSV exports. Verify files, versions and relationships. A link back to the old CRM is insufficient if it will stop working after decommissioning. Source: Twenty.

6. Transfer deals and next actions together

For every open opportunity, check at least the company, contacts, owner, pipeline, stage, amount, currency, expected closing date and next activity. Include the current quotation and the notes needed to continue the conversation.

Hypothetical example: a deal is marked “Proposal sent”, but the customer has already requested a revision. Moving only its stage and value would lose important context. The migration should also preserve the request, the correct document and the assigned task.

Do not equate stages with similar names without checking their meaning. If two stages are combined, preserve the previous stage in a historical field where needed and document the effect on reporting.

Sales continuity depends on the connection between history, opportunities and future activities. Softer also highlights this distinction in its description of an operational CRM. Source: Softer.

7. Configure the destination before loading data

Prepare fields, selection options, pipelines, users and permissions before testing. Check how to handle owners who have left the business: operational ownership may change, while historical authorship should be preserved where possible.

Twenty specifies that fields must exist before CSV import and that referenced users must have accepted their invitations. These are product prerequisites to verify, not details to postpone. Source: Twenty.

Prepare automations in an inactive state. During loading, check that new records or stage changes do not generate unwanted emails, assignments or notifications.

For every integration, document its direction, matching identifier, authoritative system and error behaviour. Reconnecting a system without these checks may reintroduce information that has already been corrected. Make activation an explicit step rather than an automatic consequence of importing records.

8. Run a trial that includes difficult cases

Do not restrict testing to straightforward records. Select a sample containing contacts without email addresses, accented characters, companies with several contacts, opportunities in different currencies, inactive owners, attachments and recurring activities.

Import according to dependencies: objects needed by other objects must come first. Twenty’s documented sequence is companies, people, opportunities, notes and activities, followed by custom objects according to their dependencies. Source: Twenty.

Ask a salesperson to complete practical scenarios:

1. find a deal and the correct contact;
2. reconstruct the most recent conversation;
3. open the current quotation;
4. complete an activity and schedule another;
5. check what a colleague with different permissions can see.

Record each error, its correction and the result of retesting. Changes to mapping must be tested through another load. Manually correcting the sample alone does not correct the migration process or demonstrate that the full transfer will work.

9. Capture updates made after the initial extraction

Sales work continues between the first export and final cutover. You therefore need an incremental transfer, often called a delta: new records, modifications and deletions since the initial reference point.

Define how to identify these changes. If reliable modification timestamps or change logs exist, check which objects they cover. Do not assume that updating a note also updates the modification date of its associated company.

If the system cannot reconstruct the delta, consider a fresh full extraction with controlled updates or a longer pause on source changes. The choice depends on the actual capabilities of both CRMs.

Test repeated loading too: the same records should be recognised, not duplicated. If the importer cannot update records through a stable key, design and test an alternative procedure.

Handle deleted records, merges and ownership changes separately. Filtering only for recently created records will not capture these events. Maintain a loading register with batch identifiers, timestamps, outcomes and exceptions so that completed work can be distinguished from items requiring another attempt.

10. Organise the operational cutover

Write an executable sequence with an owner for each action:

1. communicate timing, the system to use and the support channel;
2. save the latest verified copy of data and exportable configuration;
3. pause source updates and the agreed connected flows;
4. extract and load the final delta;
5. verify relationships, assignments and priority opportunities;
6. authorise use of the new CRM;
7. progressively reactivate integrations and automations;
8. reconcile enquiries collected during the transition window.

Salesforce recommends a backup before full migration and subsequent checks on data, workflows, integrations and user access. Source: Salesforce.

During the transition, keep one authoritative system for sales updates. Two writable CRMs without synchronisation and conflict rules are not a continuity plan.

Hypothetical example: an urgent enquiry arrives during the pause. The designated person records it in a protected temporary list, including its time and assignee. After cutover, they check whether it has already been captured automatically before entering it, avoiding a duplicate.

11. Prepare a return to the previous system

Rollback means more than possessing a backup. Decide who can authorise it, which problems justify it and how to recover updates already entered into the destination.

Before users start working in the new system, returning may involve reactivating the source. After launch, it also requires extracting and reconciling work completed in the new CRM. Otherwise, the system is recovered but sales activity is lost.

Define concrete conditions: users cannot access priority deals, associations are widely incorrect or essential integrations do not work. Distinguish these from defects that can be corrected without returning to the old platform.

Test access to copies, source availability and the recovery procedure. Also identify the point beyond which fixing the new environment is preferable because returning would require a more hazardous reconciliation. Record that decision before an incident forces the team to make it under pressure.

12. Reconcile data and daily work before closing

Record counts are necessary but insufficient. Document the relationship between extracted, excluded, merged, imported and rejected records. A difference may be valid if explained; identical totals may conceal incorrect associations.

Also compare:

• opportunities by pipeline, stage and owner;
• amounts by currency, without adding different currencies together;
• open activities by assignee and due date;
• contacts without companies and opportunities without contacts;
• availability of priority attachments and history.

For each exception, state its impact, owner and planned resolution. Do not close the project with a vague list of “minor issues”.

The previous CRM may remain available for reference for an agreed period, subject to the access and retention arrangements established. Decommission it only after checking dependencies in other systems as well. In particular, confirm that users are not still relying on document links that point to the old environment.

13. Checklist for the sales lead

Before authorising cutover, verify that:

• Every priority deal has an owner, contact and next action.
• New stages have an approved mapping from previous stages.
• Excluded history can be found in the agreed archive.
• Required quotations and attachments are accessible.
• Users and permissions have been tested with non-administrator accounts.
• The final delta includes activities and relationships.
• Incoming enquiries have a temporary handling procedure.
• Automations and synchronisations have a reactivation sequence.
• Rollback conditions and responsibilities are documented.
• The team knows where to work and how to report problems.

Approval should confirm these checks, not merely acknowledge that the technical import has finished. Keep the evidence with the migration record so that unresolved exceptions remain visible after launch.

14. Frequently asked questions about CRM migration

Can we migrate without stopping sales?

You can design for continuity of sales activity, but you should not assume that every interruption can be eliminated. Separate access to information from permission to update it, and prepare temporary capture of incoming requests.

Is a CSV file enough?

That depends on the objects, relationships and importer capabilities. Check history, attachments, users and configuration separately. Successfully importing contacts does not demonstrate that the migration is complete.

Should we use CSV or APIs?

Decide after checking volumes, limits, relationships, error handling and the ability to update existing records. APIs do not remove the need for mapping, validation or repeated-load testing.

Will emails reappear when we connect the mailbox?

Do not assume so. Check the synchronisation period, permissions, associations and duplicate risk. Testing should include conversations needed for continuity, rather than only new messages.

When should we train the team?

Before launch, using representative scenarios, and again during stabilisation. Salesforce recommends role-specific training and continued support after cutover. Source: Salesforce.

15. Practical next steps

Start with three documents: an object inventory, a field map and a cutover sequence. Add a sample of opportunities that represents real sales work. It will provide a shared reference for technical staff and sales colleagues.

CRM configuration and migration covers setup, imported data and a structure aligned with the actual process. CRM training and governance addresses shared usage, working rules and periodic checks.

Want to discuss your migration scope against the sales team’s operational needs? Book a call. Bring your object inventory, active integrations and the information your team cannot afford to lose.