How to Choose and Migrate a CRM Without Losing Data or Disrupting Sales
Choose by process and data-model fit, preserve record relationships and active sales work, reconcile every migration outcome and retain a controlled route back if cutover evidence is not acceptable.
Fast answer: A safe CRM migration preserves relationships, ownership and active workflows—not only contact fields. Inventory every object, clean and map the data, freeze changing automations, test a representative sample, reconcile record counts and relationships, run both systems during validation and retain a documented rollback route.
Choose the CRM by Process Fit—Not Feature Count
Start with the sales, service and account process that users must operate every day. A platform can contain hundreds of features and still be unsuitable when its record model, permissions, pipeline, reporting or integration route conflicts with the way the business works.
Process model
Can the platform represent lead capture, qualification, deals, handoffs, service, renewals and account ownership without excessive workarounds?
Data model
Can companies, contacts, opportunities, activities, tickets, products and custom records be related in the required way?
Permissions
Can users view and change only the records, fields, exports and administration functions appropriate to their role?
Integration
Can website forms, email, calendar, telephony, billing, helpdesk and reporting systems connect through supported interfaces?
Administration
Can an internal owner maintain fields, users, workflows and reports without making every change a development project?
Exit and portability
Can the business export usable records, relationships, activities and configuration evidence if it later changes platform?
Require a configured demonstration
Give shortlisted platforms the same representative scenario: one new enquiry, one existing account, one multi-contact deal, one service issue, one renewal and one management report. Ask the provider to show how the process works using required permissions and integrations—not a generic product tour.
Businesses still deciding the future process and platform can use CRM consulting for requirements, workflow and platform selection before committing to configuration or migration.
Compare three-year operating cost
Include licences, required editions, storage, marketing contacts, calling, automation, implementation, migration, integrations, support, administration and user adoption. BhavPro’s CRM ROI calculator can structure an indicative comparison after the process and licence assumptions are known.
Relationship InventoryInventory Objects, Relationships and Workflow Dependencies
Microsoft’s current CRM migration guidance identifies schema mismatch, data volume, data quality, relationship dependencies, downtime and security as core migration challenges. The inventory must therefore go beyond contacts and columns.
Contacts, companies, deals, activities and tickets
Modern CRMs treat these as separate objects with associations. HubSpot’s current import documentation supports companies, deals, calls and meetings across multiple objects and requires unique identifiers to update records and rebuild associations. Salesforce likewise supports external IDs for associating related records during import.
| Object | Source Identifier | Parent or Related Object | Active Workflow | Migration Decision |
|---|---|---|---|---|
| Companies | Account ID, domain or approved business key | Parent company, owner, contacts and deals | Account management and reporting | Migrate, merge, archive or exclude |
| Contacts | Contact ID plus controlled matching fields | Company, deals, tickets and activities | Sales, service and communications | Migrate with preferences and source |
| Deals | Opportunity ID | Company, contacts, owner and products | Pipeline, forecast and next actions | Prioritise all open deals |
| Activities | Activity ID | Contact, company, deal or ticket | Follow-up and customer history | Confirm platform-specific import support |
| Tickets | Case ID | Account, contact, service and owner | Support queue and service reporting | Protect all active and unresolved cases |
| Users | Source user ID and email | Teams, queues, records and permissions | Ownership, approval and reporting | Map active and historical owners |
Orders, billing, provisioning and telephony records
A CRM may contain references to operational systems rather than the complete order or billing record. Preserve the external IDs and connection logic. For telephone workflows, map phone numbers, users, queues, call outcomes, activity ownership and recording references. Review BhavPro’s VoIP and CRM integration guidance when future call logging, screen-pop and missed-call workflows are part of the migration.
Operational dependencies
Record which external system remains authoritative.
- Orders and product configuration
- Invoices, payments and subscriptions
- Provisioning and activation status
- Support and service records
Communication dependencies
Identify where communication history is stored and how new activity will be created.
- Email and calendar synchronisation
- Calls, recordings and dispositions
- SMS and messaging events
- Website forms and lead-source data
Clean and Classify the Source Data
Do not use the migration to copy every historical weakness into a more expensive platform. The ICO requires personal data to be adequate, relevant, limited to what is necessary, accurate where required and retained no longer than needed for its purpose.
| Category | Decision | Control |
|---|---|---|
| Active operational records | Migrate with full validation | Prioritise open deals, tasks, tickets, renewals and current accounts |
| Required historical records | Migrate or retain in controlled archive | Document purpose, access and retention |
| Duplicates | Merge according to approved precedence | Preserve relationships, ownership, activity and consent |
| Obsolete or excessive fields | Exclude | Record the approved reason and source location |
| Inaccurate records | Correct, mark as historical or exclude | Preserve source and correction evidence where relevant |
| Unsupported attachments | Convert, link to archive or exclude | Verify accessibility and access control |
| Suppression and preferences | Migrate as controlled records | Do not infer fresh consent from migration |
Define duplicate rules by object
Email address alone may be insufficient or unsafe as a universal match key. Companies may share domains; contacts can change email; leads and contacts may represent the same person in different stages. Define exact, fuzzy and manual-review rules and identify which record survives.
Map the TargetMap Fields, Owners, Permissions and Statuses
| Source Field | Source Meaning | Target Field | Transformation | Validation | Fallback |
|---|---|---|---|---|---|
| Account Status | Current commercial state | Customer Lifecycle | Map approved source values to target values | Every active account receives a valid value | Route unmapped values for review |
| Sales Rep | Current owner | Record Owner | Source user ID to active target user | No open deal lacks an owner | Assign controlled migration queue |
| Deal Stage | Progress through old pipeline | Target Pipeline Stage | Map by business meaning, not label similarity | Stage totals and values reconcile | Hold ambiguous deals for sales review |
| Marketing Preference | Channel status and source | Subscription or suppression fields | Preserve evidence and date | No suppression status is lost | Default to non-marketing where evidence is absent |
| Legacy Record ID | Source primary key | Migration External ID | Copy unchanged | Unique and complete | Reject missing keys for controlled repair |
Preserve current and historical ownership
Open work needs an active owner. Historical activities may belong to former users. Decide whether the target platform supports inactive users, historical-owner fields or migration users. Do not silently assign every old record to the current administrator.
Test permissions with real roles
Validate salesperson, manager, service, finance, marketing, administrator and integration identities. Confirm who can view, edit, delete, merge, export, import and change workflow rules. Platform administration permissions should not be assumed from ordinary record access.
Automation ControlFreeze or Redesign Automations
Historical imports can accidentally send customer messages, create duplicate tasks, change owners, open tickets or update connected systems. Catalogue every trigger in the source and target before importing data.
- List every source automation and decide whether it is migrated, rebuilt, replaced or retired.
- Disable outbound actions in the migration environment.
- Mark imported records where platform rules need an exclusion condition.
- Test automations separately with controlled records.
- Record the order in which workflows and integrations are re-enabled.
Run a Representative Test Migration
A test containing only clean contacts proves little. Include every object, relationship, owner type, status, activity type, duplicate pattern and integration dependency that could affect live operation.
| Test Case | Expected Result | Evidence |
|---|---|---|
| Company with several contacts and open deals | All records retain the correct parent and associations | Relationship sample with source and target IDs |
| Former owner with historical activities | History remains attributable without granting active access | Owner mapping and activity review |
| Duplicate contacts with different histories | Approved survivor retains required relationships and preferences | Merge log and before/after comparison |
| Open ticket linked to account and service | Status, owner, messages and service reference remain usable | Operational user acceptance test |
| Deal with products and custom fields | Value, stage, line items and reporting classification reconcile | Deal-level financial comparison |
| Unsupported activity or attachment | Controlled archive, link or recorded exclusion is created | Exception register |
| Rejected or malformed record | Import stops or routes the record without losing the reason | Error file and repair decision |
Confirm platform-specific import limits
Import behaviour differs by platform, edition and object. For example, HubSpot currently states that existing emails, meetings, notes and tasks cannot be updated through import. Confirm supported activity types, attachment limits, association rules and update behaviour using current vendor documentation.
ReconciliationReconcile Counts and Relationship Integrity
Record counts alone cannot prove migration integrity. A deal without its company, contact or owner is technically present but operationally damaged.
Source extracted = excluded + merged or transformed outcome + successfully loaded + unresolved exception| Check | Evidence | Acceptance Rule |
|---|---|---|
| Open pipeline value | Source and target totals by currency, owner, pipeline and stage | Every difference is explained and approved |
| Parent-child relationships | Sample and automated orphan checks | No required contact, deal, ticket or activity is orphaned |
| Ownership | Counts by active, former and migration owner | All active work has the intended responsible user or queue |
| Activities | Counts by type, date range and related object | Required history is accessible and correctly linked |
| Preferences | Suppression, channel and evidence comparison | No opt-out or restriction is weakened |
| Permissions | Role-based user acceptance | Users can perform required work without excessive access |
| Integrations | End-to-end trigger and destination verification | No duplicate or unauthorised external action occurs |
| Reports | Source benchmark and target report comparison | Leaders understand accepted definition changes |
CRM Migration Readiness and Reconciliation Checker
Assess the current migration state. The checker identifies whether the project is ready for discovery, a test migration or controlled cutover.
CRM Migration Control Checker
Select the evidence currently available. The result is a planning assessment, not a guarantee that data loss or disruption cannot occur.
CRM Migration Reconciliation Workbook and Relationship Map
Complete one row for every object and a separate relationship row for every required parent-child link. Do not sign off the cutover while unexplained differences remain.
| Object | Source | Excluded | Merged | Loaded | Rejected | Delta | Unexplained Difference | Owner | Sign-Off |
|---|---|---|---|---|---|---|---|---|---|
| Companies | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Contacts | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Leads | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Deals | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Activities | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Tickets | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Custom records | Enter count | Enter count | Enter count | Enter count | Enter count | Enter count | Must equal zero | Name | Date |
| Relationship | Expected Links | Loaded Links | Orphans | Sample Size | Errors Found | Correction Rule | Owner |
|---|---|---|---|---|---|---|---|
| Company → Contact | Enter count | Enter count | Zero required | Enter sample | Enter count | Document | Name |
| Company → Deal | Enter count | Enter count | Zero for required links | Enter sample | Enter count | Document | Name |
| Deal → Contact | Enter count | Enter count | Review every orphan | Enter sample | Enter count | Document | Name |
| Record → Owner | Enter count | Enter count | Zero active-work orphans | Enter sample | Enter count | Document | Name |
| Activity → Related Record | Enter count | Enter count | Review every required orphan | Enter sample | Enter count | Document | Name |
| Ticket → Account/Contact | Enter count | Enter count | Zero active-ticket orphans | Enter sample | Enter count | Document | Name |
| CRM → External System ID | Enter count | Enter count | Zero for active integrations | Enter sample | Enter count | Document | Name |
Parallel Run, Cutover and Rollback
Use a defined authority model during transition. Two freely editable CRMs produce divergent records and can make rollback harder rather than safer.
| Stage | Source CRM | Target CRM | Key Control |
|---|---|---|---|
| Preparation | Authoritative and live | Configured test environment | No customer-facing automation from imported records |
| Main extraction | Live with change tracking | Receives controlled migration | Record extraction timestamp and source backup |
| Validation | Authoritative; restrict structural changes | Tested by controlled users | Reconciliation and issue log |
| Freeze and delta | Read-only or tightly controlled updates | Receives final changes | Conflict and duplicate rules |
| Cutover | Read-only fallback | Authoritative for new work | Named decision authority and monitoring |
| Hypercare | Retained for approved validation period | Live with daily issue review | Rollback threshold and decommission date |
Define rollback triggers before go-live
- Unexplained record or pipeline differences exceed the approved limit.
- Required relationships or owner assignments are missing.
- Users cannot complete a critical sales or service process.
- Integrations create duplicate or incorrect external actions.
- Permissions expose restricted records or prevent required work.
- The issue cannot be contained inside the agreed recovery period.
The NCSC recommends maintaining a separate safe backup and checking that it contains the required data. A CRM rollback also requires the application state, configuration, user access, integration settings and delta changes needed to resume operation—not merely a spreadsheet export.
Post-Migration OperationPost-Migration Adoption and Reporting
A technically correct migration can still disrupt sales when users cannot find records, pipelines use unfamiliar definitions or managers continue to operate from spreadsheets.
| Area | Measure | Action |
|---|---|---|
| Access | Failed sign-ins, missing views and permission requests | Resolve role design rather than granting broad access |
| Record quality | Duplicates, missing owners and incomplete required fields | Correct causes and migration exceptions |
| Pipeline | Deals without next actions, wrong stages or unexpected value | Review with sales managers daily during hypercare |
| Activity | Email, calls, meetings and tasks recorded correctly | Repair integration or user workflow gaps |
| Adoption | Active users, update frequency and spreadsheet workarounds | Train by role and remove duplicate processes |
| Reporting | Definition and total differences from approved benchmarks | Document intended changes and correct defects |
When the relationship map, source data and target process are understood, BhavPro’s CRM implementation delivery can cover configuration, migration, testing, training, go-live and post-launch support.
Define
Agree the process, platform requirements, owners, objects and cutover constraints.
Inventory
Map sources, relationships, fields, users, automations and integrations.
Prepare
Clean, classify, deduplicate, transform and protect the source data.
Test
Run representative imports and validate every object and workflow dependency.
Reconcile
Prove counts, relationships, owners, activities, reports and permissions.
Cut Over
Run delta migration, controlled go-live, hypercare and decommissioning.
Need to replace a CRM without breaking active customer work?
BhavPro can help scope the target process, prepare relationship-aware migration data, configure the CRM, test workflows, reconcile the result and support controlled go-live.
CRM Selection and Migration FAQs
How do you choose the right CRM before migrating?
Document the real sales, service and account processes first, then compare platforms against object structure, pipelines, permissions, reporting, integrations, migration capability, administration, user experience, data export and three-year operating cost. A configured demonstration using representative records is more useful than a generic feature tour.
What data should be migrated to a new CRM?
Migrate active and legally required records that support current sales, service, reporting and customer obligations. Archive, anonymise or delete obsolete, duplicate, excessive and unsupported data according to an approved retention decision rather than carrying every historical field into the new platform.
Why are CRM object relationships important?
A contact may belong to a company, a deal may have an owner and several contacts, and activities may relate to multiple records. If those links are lost, the individual records can exist while the customer history, pipeline context and reporting become unreliable.
What is an external ID or migration key?
It is a stable identifier retained from the source system and used to match records, rebuild relationships, prevent duplicates and reconcile the migration. Keep a crosswalk between source IDs and new CRM IDs until validation and rollback periods have ended.
Should duplicate records be removed before migration?
Duplicates should be identified before migration, but merging requires business rules. Confirm the surviving record, field precedence, relationship transfer, activity history, consent and ownership. Preserve an audit trail for material merges rather than deleting records without evidence.
How should CRM activities be migrated?
Inventory calls, emails, meetings, notes, tasks and attachments separately because platforms often impose different import rules for activities. Preserve the activity date, owner, direction, participants, related record, subject, outcome and original source identifier where supported.
Should CRM automations remain active during migration?
Normally, automations that can send messages, create tasks, change stages or update connected systems should be paused or redirected in test environments. Re-enable them only after triggers, historical records, duplicate behaviour and destination actions have been validated.
What is a representative test migration?
It is a controlled import containing normal, duplicate, incomplete, unusual and high-value records across every object and relationship type. It should test users, owners, activities, permissions, integrations, rejected records, automations and reporting before the full migration.
How do you prove that a CRM migration is complete?
Reconcile source, excluded, transformed, loaded, rejected and duplicate counts by object; verify financial and pipeline totals; sample parent-child relationships; confirm owners, activities, consent, permissions and integrations; and record every accepted difference with an owner.
What is a delta migration?
A delta migration moves records created or changed after the main extraction. It reduces the time the source system must remain frozen. The business must define the change window, source timestamp, conflict rule and final reconciliation before cutover.
Should old and new CRMs run in parallel?
A short, controlled parallel period can support validation, but two editable systems can create conflicting records. Define which system is authoritative for each process and use read-only access, synchronisation or a strict update rule rather than unrestricted dual entry.
What should a CRM rollback plan include?
Define the decision authority, rollback trigger, source backup, old-system access, delta changes, integration reversal, user communication, credential changes and the point beyond which rollback is no longer practical. Test the recovery steps before cutover.
How should phone-system records be handled?
Map call activities, recordings or recording references, phone numbers, users, queues, dispositions and click-to-call or screen-pop dependencies. Confirm whether historical calls can be imported and test the future VoIP-to-CRM workflow separately.
How long should the old CRM remain available?
Keep it only for the validated operational, legal, audit and rollback period. Where possible, restrict it to read-only access. Apply a documented retention and decommissioning decision so the old platform does not become an uncontrolled duplicate customer database.
Executive Decision Summary
- Choose by process and data-model fit. Require configured demonstrations using representative records and user roles.
- Inventory relationships, not only fields. Preserve companies, contacts, deals, owners, activities, tickets and external-system references.
- Move only justified data. Clean duplicates, inaccuracies and excessive history according to approved rules.
- Control automations and integrations. Prevent historical imports from creating live messages, tasks or external transactions.
- Reconcile business integrity. Verify counts, relationships, ownership, pipeline value, permissions and active workflows.
- Retain a tested fallback. Protect the source, track delta changes and define rollback authority before cutover.
Preserve the Customer Relationship—not Just the Contact File
BhavPro can help turn a CRM replacement into a controlled business transition with an owned data model, relationship-aware migration and measurable cutover evidence.
Official Sources Used in This Guide
The references below support the schema, relationship, unique-identifier, duplicate, data-protection, backup and platform-import guidance used throughout this page.
- Microsoft Learn — CRM Data Migration to Dataverse covers schema mismatch, data volume, quality, relationship dependencies, downtime, security and continuity.
- HubSpot Knowledge Base — Import Records for Multiple Objects documents unique identifiers, record associations and current activity-import limitations.
- Salesforce Help — Import Related Records With an External ID explains using stable external identifiers to associate records during upsert.
- Microsoft Learn — Detect Duplicate Records explains duplicate controls for accounts, contacts and other record types.
- Information Commissioner’s Office — Data Minimisation requires personal data to be adequate, relevant and limited to what is necessary.
- ICO — Accuracy covers reasonable steps to keep personal data accurate, record its source and correct errors.
- ICO — Storage Limitation explains retention schedules and deletion or anonymisation of data no longer required.
- National Cyber Security Centre — Backing Up Your Data explains separate protected backups and checking that required data can be restored.
