Changing customer relationship management software is not primarily an exercise in uploading a contacts spreadsheet. The difficult part is preserving the information and context that make those contacts useful: which company they work for, who owns the account, what has been promised, which opportunities are open, when someone last spoke to them, and whether they have agreed to receive marketing.
The safest way to migrate to a new CRM is to inventory your existing data, export a recoverable copy, map every important field and relationship, test with a representative sample, reconcile the full import, and only then switch your team and integrations to the new system. Keep the old CRM accessible in read-only or tightly controlled form until the new one has passed agreed checks. For live businesses, plan a final changes-only transfer and a rollback decision before cutover.
That process reduces avoidable data loss. It does not guarantee that every CRM can reproduce every piece of another system's history or automation. Some information may need an approved archive, a specialist migration method, or a documented compromise. This guide explains how to discover those limits before they become an expensive surprise.
Quick decision: For a relatively simple database of contacts, companies and open deals, a supported native importer may be sufficient. For a sales operation that depends on activity timelines, attachments, custom objects, complex permissions, invoices or extensive integrations, treat the work as a controlled data-and-process migration rather than a one-day import.
What counts as a successful CRM migration?
A successful migration is not defined by a message saying “import completed”. It means staff can perform their important tasks in the new CRM using reliable, properly connected data, and that the organisation can explain what did—and did not—move.
At minimum, check five dimensions. Completeness asks whether the required records were brought across. Integrity asks whether values, record ownership and relationships remained correct. Usability asks whether teams can find and work with the information. Continuity asks whether forms, inboxes, call systems, reporting and automations function after the transition. Compliance and security ask whether personal data, permissions, opt-outs and retention obligations are still properly controlled.
A migration might pass the completeness test while failing badly elsewhere. Imagine 12,000 contacts arrive, but many contacts are attached to the wrong companies. Or every open opportunity imports, but its estimated close date becomes a blank value. Or the new CRM marks previously unsubscribed people as marketable. These are different kinds of failure and they require different checks.
A useful acceptance statement is: Every in-scope active deal can be matched to its source ID, correct account, current stage, amount, owner and next action; critical customer contact restrictions are preserved; and staff can complete the core sales process without using the old system. This is a proposed project standard, not a vendor guarantee. Your business should add sector-specific requirements where applicable.
Decide what “no lost data” means before doing anything
No two CRMs store information identically. The target might not support your old activity type, deal-stage history, custom relationship model or attachment metadata. Therefore establish three categories before selecting an import tool: must move as working CRM data, must remain accessible in an auditable archive, and can be excluded under the business's retention policy.
For example, an account's legal name and open contracts may need to remain searchable within the new CRM. A seven-year-old closed opportunity might only need to remain in a secure archive, depending on applicable retention requirements. A redundant temporary note containing obsolete personal information may not need migration at all. Do not assume either that everything must be carried forward or that historic data may safely be discarded.
Related ToolRankers research: Best CRM for Small Businesses in 2026: 7 Platforms Compared, Best Freshsales Alternatives in 2026: Which CRM Should You Switch To?.
Step 1: Build a complete inventory of data and dependencies
The first practical task is to discover what exists. This sounds simple until you compare the records a salesperson sees with the data a system administrator knows about. Beyond contacts and companies, a CRM may contain leads, opportunities, pipelines, cases, tasks, meetings, call logs, email threads, quotes, products, custom objects, consent records, files, attachments, audit events and values maintained by external applications.
Ask each department to identify what it actually uses. Sales may depend on deal stages and next-action reminders. Customer success may rely on account notes and support tickets. Finance may reference quote IDs or payment-system links. Marketing may need source attribution, preference centres, unsubscribes and segmentation fields. The person responsible for privacy should review personal-information types, retention and export access.
Data or dependency | What to inventory | Typical migration risk |
|---|---|---|
People and companies | IDs, names, emails, domains, addresses, ownership | Duplicates, incorrect company matches |
Leads and deals | Pipelines, stages, amount, currency, products, close dates | Wrong stage, lost history, inaccurate forecasts |
Activities | Notes, calls, emails, meetings, tasks, timestamps | Missing timelines or wrong dates |
Relationships | Contact-company, deal-contact, parent accounts, custom links | Orphaned records and wrong associations |
Files and attachments | Filename, linked record, file type, storage location | Missing files or broken links |
Custom configuration | Fields, option sets, objects, formulas, access rules | Unsupported values or lost controls |
Marketing preferences | Consent basis, source, date, opt-outs, suppression status | Unlawful or unwanted contact |
Connected systems | Forms, email sync, telephony, billing, ecommerce, BI, API jobs | Duplicates, failed workflows, data overwrites |
Do not rely exclusively on a single “export all” button. In Pipedrive, the official export guidance says activities, notes and files linked to contacts or deals must be exported separately; Google Drive-stored files are not included in the global export. It also explains that visibility permissions limit what a non-admin can export [1]. In HubSpot, a general records export provides current property values and associations, while certain activities require a separate export or API route [2]. These are examples of why the source-specific export inventory comes before an implementation schedule.
Create a migration register with a row for each data category, its approximate source count, current system, target location, required export method, field owner, confidentiality level, acceptance check and unresolved issue. This becomes the project's source of truth. Document categories that will remain in the archive so the final stakeholder sign-off is not mistaken for evidence that every item was imported.
Inventory the integrations before they create new data
List every application connected to the old CRM, with the direction of data flow and the system that is authoritative for each field. A website form may create leads. An email platform may write subscription status. An invoicing application may send payment updates. A spreadsheet synchronisation tool may overwrite records during the night. If these keep running against both CRMs, you can create duplicate records or send conflicting updates.
For each connection record who owns it, how it authenticates, which records it can create or edit, where errors are logged and what will happen during the final switch. Ask whether the connection is bidirectional. A sync service that silently rewrites names or statuses is more difficult to investigate than a one-way export job.
Step 2: Choose a migration method that matches the data—not merely the budget
There are four broad approaches. You can use the destination CRM's native spreadsheet importer; its direct vendor-to-vendor migration tool, if supported; a specialist migration application or partner; or a custom integration using APIs and scripts. The correct choice depends on whether your must-have data and relationships are supported, the size and complexity of the dataset, and how much the business can tolerate downtime.
A native CSV importer is attractive because it is accessible and can be tested in small batches. But it may not recreate immutable activity history, file relationships or historical audit fields. A vendor-specific migration pathway can recognise known data structures, but it still requires mapping and reconciliation. Specialist tools can help preserve more object types, although vendors and agencies must be evaluated for access controls, security, coverage and costs. A custom API migration allows the most control but introduces development, maintenance, pagination, rate-limit and error-handling responsibilities.
Approach | Usually best for | Main limitation to establish before purchase |
|---|---|---|
Native CSV/XLSX import | Small or relatively flat datasets | Which history, files, relationships and timestamps cannot import? |
Built-in CRM migration | Supported CRM-to-CRM pathways | Are custom fields, activity types and historical relationships covered? |
Specialist tool or partner | Complex but repeatable migrations | Exact data scope, audit evidence, access terms and remediation responsibility |
Custom API / ETL | Complex objects, transformation and staged deltas | Engineering expertise, platform API restrictions, monitoring and test effort |
For perspective, Pipedrive's documented spreadsheet importer can create or update people, organisations, leads, deals, projects, activities, notes and products [3]. HubSpot supports importing and associating multiple objects and specified activities, but the rules for what can be created versus updated differ by object [4]. Salesforce Data Loader supports insert, update, upsert and export operations, with external IDs available for matching [5]. None of these statements means every previous field or audit event will transfer unchanged.
Questions to ask a migration provider
Ask for a written field-and-object coverage matrix, not a general promise of “seamless migration”. Clarify whether existing record IDs will be stored in a searchable target field; how attachments and notes are transferred; which timestamps and historical changes will remain unchanged; whether associations with multiple records are supported; how errors are surfaced; what is meant by a successful transfer; and whether the provider will run a second changes-only migration near launch.
Also ask who can access raw exported personal data, where staging files are held, how long they are retained, whether a third-party subprocessor is involved, and how the provider proves deletion after handover. Distinguish migration execution costs from possible extra CRM licences, storage, API usage, add-ons and administration. A low-cost automated transfer with no defensible rollback mechanism may be a poor bargain for a revenue-critical system.
Step 3: Back up the source CRM—and prove you can recover the backup
A migration export is not automatically an adequate backup. A contacts CSV may omit notes, attachments, activity records, user permissions and workflow definitions. Before editing records or testing imports, create the most complete authorised export your current provider permits and save configuration evidence separately: pipeline definitions, custom field lists, user-role assignments, automation recipes, connected applications and key reports.
For Salesforce, the platform's Data Export Service can generate CSV exports and provides options to include documents, attachments and Salesforce Files, with edition-dependent export frequency [6]. HubSpot's records export has its own file-format and association behaviour, while a separate property-history export can preserve certain historical values [2, 7]. These product differences show why you should read the vendor documentation relevant to your account plan and record types.
Store the backup in a controlled location with restricted access, rather than sending unencrypted customer data around by email. Use appropriate encryption for stored data and transfers, and restrict access to staff who actually need it. The UK Information Commissioner's Office identifies encryption as an example of a measure for meeting the security principle, not a blanket requirement that all information must always be encrypted [8]. Determine your measures from the data and risk involved.
Test whether the export is readable. Open each file, inspect headers, verify characters and sample rows, check file sizes, and confirm the number of records is plausible. For important attachments, open sample documents and compare them with their originals. If you use a provider-native backup, check the restore procedure and whether you have the access, licences or support route needed to use it. A file you have never tried to read should not be your sole recovery plan.
Freeze the baseline: record the export time, source record counts, schema version, storage location, person responsible and checksum where useful. Keep an untouched raw copy; create separate working copies for cleaning and mapping. In a regulated environment, maintain an access and change log for the migration files. Never assume a newer, incomplete CSV is a replacement for the original evidence.
Step 4: Clean the data without destroying useful history
Data cleaning improves the quality of the new CRM, but excessive or poorly documented changes can sever relationships or erase information that matters. The goal is to remove avoidable errors while preserving provenance. Work from an authorised copy and log the significant transformations you apply.
Start with exact duplicates, malformed email addresses, inconsistent country codes, stale owner assignments and option labels that differ only in spelling. Then tackle ambiguous duplicates: two contacts with similar names might be the same person—or two customers sharing a company inbox. Never merge based solely on a person's name. Where a stronger key is unavailable, quarantine records for human review instead of imposing a high-risk automatic merge.
Pipedrive explicitly provides import-time duplicate handling and warns that contact names alone may collide [9]. HubSpot provides unique identifier choices including email for contacts, company domain for companies, record IDs and eligible custom unique properties [10]. Those vendor rules are not interchangeable: determine how the destination actually identifies existing records before you construct deduplication logic.
Decide which source is authoritative
Your CRM may disagree with billing software or an email marketing system. Decide field by field which source controls the value. The finance system could be authoritative for invoice status, while the CRM controls deal stage. A customer preference centre might be authoritative for subscription choice. Preserve the system-of-record decision in your field map, then prevent an old integration from silently reintroducing outdated values after launch.
Do not change a customer's marketing preference merely to make the new CRM's format simpler. For UK electronic marketing, the ICO's guidance explains that consent and the limited soft opt-in routes have specific conditions, and that objections and opt-outs need to be respected. It recommends maintaining suppression lists rather than simply forgetting unsubscribed contacts [11, 12]. Migration is not an opportunity to relabel unknown consent as consent obtained.
Personal information must also remain adequate, relevant and accurate for its purpose. The ICO's data-minimisation and accuracy guidance explains why collecting everything “just in case”, or knowingly copying incorrect personal data, creates its own risk [13, 14]. Apply the correct retention rules; do not delete legally required records simply because they are old.
Step 5: Map fields and relationships before importing records
A field map is the translation document between the old CRM and the new one. It should identify the source object and field, example value, target object and field, data type, transformation rule, accepted values, fallback for invalid data, whether the field is required, whether it holds personal data and who approved the mapping.
Source field (example) | Target field | Transformation / validation rule | Acceptance test |
|---|---|---|---|
source_contact_id | legacy_contact_id (custom unique field) | Preserve as text, even if the ID looks numeric | One-to-one source/target ID match |
company_id | Account/organisation reference | Import companies first, then resolve relationship | No unexplained orphan contacts |
opportunity_stage | Deal stage | Translate via approved stage lookup table | No unexpected default stages |
deal_amount and currency | Amount and currency | Preserve currency; convert only with approved rate/date | Financial totals reconcile by currency |
owner_user_id | Record owner | Map to active destination users or approved queue | Owners match allocation plan |
marketing_status | Subscription/suppression fields | Preserve legal basis, channel, date and source separately | Suppressed contacts remain suppressed |
last_activity_at | Activity date/time | Parse date and time zone explicitly | Dates match source to agreed precision |
Preserve legacy IDs. Even if the new CRM generates its own IDs, storing the old identifiers in dedicated fields makes reconciliation, incremental migration, audit investigations and rollback much easier. A person's email address is not a universal identity key: email changes, duplicate shared inboxes and records without email can break such assumptions. External IDs offer more reliable matching when supported.
Salesforce documents using external IDs in Data Loader to connect related records during upsert operations [15]. Microsoft Dataverse uses lookup columns to represent record relationships and allows lookup mapping during imports [16]. HubSpot's current documentation specifies unique identifiers and shared columns for importing associations [10]. These are different interfaces for the same conceptual requirement: every imported child record must be linked to the correct imported parent.
Design the relationship loading order
Importing every dataset simultaneously is tempting, but dependencies usually make a planned sequence safer. Start with users and required custom fields or objects. Then load companies/accounts; contacts and related leads; products and price lists where relevant; deals and opportunity line items; activities, notes and files; and finally permissions-sensitive associations and operational reports. The actual order depends on the destination's importer.
A more complicated relationship may involve two companies in a parent-child hierarchy, a contact linked to several organisations, or a deal linked to more than one contact. Confirm the target supports that shape and whether the selected plan offers custom association types. HubSpot, for example, documents that custom association labels require specified higher subscriptions [10]. If a relationship cannot be represented, agree on an explicit alternative instead of silently dropping it.
Treat date, currency and status fields as high-risk
A column that looks fine in a spreadsheet can change meaning when imported. A date such as 03/04/2026 can mean 3 April or 4 March. A CSV opening in spreadsheet software may strip leading zeros from identifiers or phone numbers. A value of 1,200 can be interpreted differently depending on separators and locale. Text encoding can damage names and non-English characters.
Use explicit ISO-style dates where the destination supports them, confirm timezone treatment, and preserve original timestamps in the source archive. Store phone numbers and IDs as text when appropriate. Make separate stage-mapping sheets and prohibit unapproved automatic currency conversion. For changes that cannot be represented exactly, retain the source value or a migration note so users can discover the limitation.
Step 6: Prepare the destination before loading live data
Most import failures become visible when administrators attempt to push data into a CRM whose configuration is not ready. Create and validate critical users, teams, pipelines, stage options, required fields, picklists, custom objects, source-ID fields, permission groups and reference data before the first pilot. Configure the structures needed for the old data, but avoid recreating every obsolete field without considering whether it is useful.
Use a sandbox or isolated test environment when available. If the vendor's plan does not provide one, create a carefully controlled test area and mark imported records as test records; understand that some automations, integrations and billable notifications may still execute across an account. Never test with a full set of sensitive customer records if synthetic or appropriately minimised data can answer the question.
Before loading a pilot, disable or isolate customer-facing automations that could send messages or create billing events, while preserving a safe test path to confirm how they will behave at launch. Also assess workflow enrolment triggers, automatic deal creation, task reminders, notifications and webhooks. Do not simply switch off every control: fraud, security and compliance safeguards may be essential. Plan controlled, documented exceptions instead.
Create a permissions matrix showing what each user role needs to see and modify. Data transfer and access design are connected: even correct records become a serious problem if every member of staff suddenly sees commercially sensitive accounts or restricted notes. Test by logging in as a representative user for each role, not solely as an administrator.
Step 7: Run a representative pilot—not just the easiest hundred contacts
A good migration pilot uses a deliberately varied sample. Include ordinary contacts, companies with multiple employees, deals in every active stage, records with multiple associations, custom-field edge cases, long notes, non-English names, old dates, inactive owners, unsubscribed contacts, files, tasks, currencies and records expected to be excluded. Small samples are useful only when they reveal the range of potential failure.
The pilot should exercise the complete path: export, clean, transform, import, reconnect relationships, attach files where supported, run checks, and let a real user attempt normal tasks. Preserve a log of warnings and errors from the import process. Pipedrive's import documentation describes preview and skipped-item handling [3]; Salesforce's documentation explicitly recommends backing up and testing small batches when working with external IDs [15].
Do not stop at “records imported”. Search for a few known contacts, open their associated companies, confirm their deal stage and next task, inspect notes and files, and check that marketing suppression flags remain in effect. Ask a salesperson to update a permitted record and check whether the intended owner can see it. For a help desk CRM, create a test ticket and confirm it links to the correct customer.
Pilot exit criterion: approve the final mapping only once significant errors have explanations and fixes. If owners do not map, links fail, consent statuses cannot be preserved, or the chosen tool silently drops fields, postpone the full migration. A rushed full import will only multiply those problems.
Step 8: Import in controlled batches and keep a source-to-target ID register
After the pilot succeeds, decide how the full load will be split into batches. Possible boundaries include record type, business unit, creation period or country. The purpose is not merely to make files smaller. Batches make failures easier to diagnose and reduce the temptation to repeat a partially successful upload without knowing which rows were already inserted.
Give each batch a name, version, export timestamp, row count and responsible person. Record the destination import job ID, the number of records created, updated, skipped or rejected, and the location of the error file. Treat retries as separate auditable actions. Where the destination supports an upsert, use an approved external or unique identifier so a failed batch can be retried without automatically creating more duplicates. Verify the behaviour of the particular operation first: “upsert” means matching and then updating or creating records, but the identification rules and side effects differ by product [5].
Maintain a crosswalk, a small but critical table that pairs each source record ID with its target CRM ID and object type. It lets the migration process attach deals to the correct companies, migrate activity histories against the right records, and investigate missing data. If an old CRM ID C-00427 becomes target ID 837492, record both along with the import batch. Where the CRM has a usable legacy-ID field, the crosswalk should also be verifiable within the destination.
When importing related records, pause after the parent stage to verify that every expected source ID resolved to one destination record. Import child objects only when the relationship map is complete enough to satisfy their dependencies. For a company with 60 contacts, validate that all 60 point to the right company rather than assuming successful contact uploads guarantee associations.
Notes, files and activity history deserve a separate workstream
Activity data frequently differs from ordinary records. An old note may have an author, creation time, last edit, content, linked contact and related deal. A destination importer may support a plain-text note but not editable history, the original author or all links. Large attachments may be governed by file-size, storage or API rules; cloud-storage links may be unavailable outside the old integration.
In Zoho CRM's documented account-migration workflow, supported modules include notes, activities, attachments and custom modules, with a particular folder structure for attachment mappings [17]. HubSpot distinguishes records from activities, and its import guidance says existing emails, meetings, notes and tasks cannot be updated via import [4]. These are examples of capability boundaries that must be investigated before selecting the method—not proof that the tools support every conceivable historical field.
For each history category, record three answers: whether the destination can represent the original content, whether it can preserve the original timestamp/author, and whether it can preserve the original related records. If not, agree on a read-only archive or a different migration approach. A link labelled “Previous CRM history archive” may be more honest and useful than copying years of interaction text into a generic custom field that sales staff cannot filter or trust.
Files should be checked as usable files
Counts alone are inadequate. A file record can exist while its download fails or links to the wrong opportunity. For critical attachments, compare names, sizes and opening behaviour; sample both small and large files. Check access rights so that a user who could not view a confidential document in the old CRM does not suddenly gain access in the new one. Do not assume a successful file transfer automatically retains the previous storage provider's sharing permissions.
Step 9: Reconcile record counts, values and relationships
Reconciliation is where teams convert an import report into defensible evidence. Run it twice: once after the main load, and again after the final changes-only transfer at cutover. Compare the source baseline against the target, subtracting only approved exclusions, merged duplicates and records deliberately held in an archive. Record those adjustments. Otherwise a tidy-looking “98% imported” figure hides the very records that may matter most.
Check | Example acceptance condition | What a failure may reveal |
|---|---|---|
Contacts and companies | Source in-scope total equals target plus documented exceptions | Skipped rows, duplicate merges, bad import filtering |
Open deals | All in-scope source IDs present exactly once | Lost opportunities, duplicate upserts |
Deal values | Totals agree by currency and status within an approved tolerance | Currency, decimal, product or stage errors |
Relationships | Required links resolve to valid expected target records | Missing crosswalk IDs, false name matches |
Owners and access | No unapproved ownership or visibility changes | Inactive users, role mapping or permission defaults |
Activities and files | Supported items and archival exceptions are accounted for | Missing export types, attachment errors |
Marketing preferences | Opt-outs and other restrictions are preserved | Incorrect consent mapping or default flags |
Operability | Key workflows execute correctly without unintended sends | Broken integrations, duplicate triggers |
Do not set a universal allowable-loss percentage. Missing one strategic contract attachment may be more serious than a hundred deliberately excluded test leads. Define zero-tolerance categories where necessary and give the project owner authority to block launch. For lower-risk data, set an explicit limit, review every exception type, and obtain recorded business approval.
A transparent example of reconciliation
Suppose a source CRM holds 18,200 contacts. The team has approved excluding 500 synthetic test entries and merging 250 exact duplicate pairs into 250 retained records. The expected destination population is therefore 17,450 contacts, assuming there are no other planned exclusions or destination records. If the import reports 17,390, that is a 60-record discrepancy requiring investigation, not an automatic success because the total looks close.
This is a hypothetical illustration, not a measured outcome from a software test. The difference might arise from failed email validation, a missing required field, a mistakenly excluded business unit or incorrect duplicate rules. To diagnose it, compare the unique legacy IDs rather than matching only on contact name or email. The counts should be accompanied by a list of missing IDs and a reason for each resolution.
Do the same for money. If 480 open deals carry values in GBP, EUR and USD, do not add them into a single monetary total without a consistent and approved conversion basis. Compare totals separately by currency, pipeline and stage. A system that changes £10,000 to $10,000 has kept the number but lost its meaning. If the new system has a base reporting currency, review exchange-rate methods and timestamps before comparing consolidated forecasts.
Test data fidelity with a deliberate sample
Automated checks are necessary but not sufficient. Select samples across revenue size, owners, countries, object types and exception cases. For each record compare important fields between source and target screen by screen. A useful test may cover an inactive owner's deal, a contact with two company relationships, an attachment-heavy account, a suppressed subscriber, a multilingual record, and an opportunity that was recently reopened.
Write discrepancies in a shared defect log with severity, expected outcome, actual outcome, affected record IDs, batch, owner and fix status. A pipeline mismatch affecting a reporting dashboard is not identical to a marketing opt-out being reversed; prioritise accordingly. Re-run the affected reconciliation checks after fixing a rule. Don't accept “we fixed it” without checking the exact records again.
Step 10: Plan the cutover so transactions do not fall between systems
A business continues changing while its data is being copied. Salespeople add notes, new leads arrive through the website, customers unsubscribe and invoices change status. A full export taken on Monday may be correct when exported but stale by Thursday's launch. This gap explains why cutover and delta migration are as important as the initial file transfer.
Choose a cutover window based on the team's actual working hours, dependencies and allowable interruption. Some teams use a short write freeze; others capture changes in a queue or arrange a final API sync. Do not claim a “zero-downtime migration” without specifying how concurrent writes, conflicts and failures are handled. If both CRMs accept edits simultaneously without a clear source of truth, there is a real risk of divergent data.
A practical sequence is to notify users of a defined cutover time; stop or redirect new writes to the old CRM; record the final source update watermark; export records changed since the last load; import those deltas using stable source IDs; reconcile high-priority changes; update integrations and permissions; run smoke tests; and then authorise users to work in the destination. The exact ordering must account for forms, ecommerce orders and service tickets that cannot simply pause. In such cases use a durable queue or temporary manual intake log with a clear reconciliation owner.
Example cutover runbook
Checkpoint | Responsible owner | Decision before moving on |
|---|---|---|
Confirm final backup and source counts | Data lead | Recoverable baseline exists |
Stop legacy write paths or activate queue | Systems lead | No untracked new updates can arrive |
Export and apply approved deltas | Migration lead | Error and duplicate reports reviewed |
Reconcile high-risk records and restrictions | Sales and privacy owners | No launch-blocking discrepancies |
Switch web forms, inbox sync and API consumers | Integration lead | Test transactions reach destination once |
Test visibility, notes, deal creation and reporting | Department representatives | Core operations work as expected |
Approve launch or activate rollback | Named decision owner | Go/no-go decision recorded |
Create a short internal communication that tells staff which system they may edit, from what time, and where to report urgent issues. If users are told to use the new platform while web forms still write to the old one, the cutover is incomplete. If the old CRM stays available for history lookup, mark it explicitly read-only wherever supported and remove integrations that could still modify it.
Step 11: Test the business process, not just the database
A CRM is part of a chain of work. Even accurate records may not deliver business value if an enquiry fails to create a lead, the salesperson gets no task, the quote cannot be issued, or the reporting dashboard counts deals incorrectly. After switching the integrations, run end-to-end tests with permission-controlled test users and harmless test records.
Test a new lead: Submit a test form, confirm that exactly one correctly owned lead appears, ensure any consent preference is recorded separately, check alerts and routing, and make sure no unintended live marketing message is sent. Test a sale: Create an opportunity, change its stage, assign a follow-up and check whether the forecast responds correctly. Test support and billing: Where those systems are connected, confirm the right account receives events and duplicate tickets or invoices are not created. Test an unsubscribe or objection: Verify that downstream email or SMS systems respect the restriction.
Check mobile access and user roles, not only the administrator view. Check dashboards against the reconciled source data. Verify that historic activities show plausible timestamps and associations, particularly if the import tool used the current import date by default. HubSpot's documentation recommends providing activity dates when importing historical engagement types so they do not simply inherit the import time [18].
Do not enable every automation at once. Turn on critical workflows in a planned order, observing job logs and message queues before expanding. Where a workflow is meant to trigger only on newly created records, confirm that imported legacy records will not accidentally meet the same condition. This is particularly important for payment notices, onboarding sequences, overdue reminders, renewals and outreach.
Step 12: Have an executable rollback plan
“Keep the old system for a week” is not a rollback plan. Once staff begin editing in the new CRM, the old data becomes stale. Returning to it may lose post-launch transactions unless you can extract and reconcile those changes. A real rollback plan states the conditions that require stopping, the decision-maker, the last safe source snapshot, where live transactions have gone, how users and integrations revert, and how changes made during the failed cutover are recovered.
The rollback action might be restoring the legacy CRM as the operational system while retaining a controlled ledger of new CRM updates. For some systems a technical rollback can be complex or unavailable; the fallback may instead involve pausing specific integrations, fixing the destination and resuming under controlled conditions. That distinction belongs in the go/no-go meeting, not in an emergency email after data has diverged.
Examples of launch blockers include uncontrolled loss of customer marketing restrictions, unexplained missing open opportunities, financially material mismatches, incorrect access to confidential data, unrecoverable sync duplication or failed required integrations. A minor non-critical reporting formatting issue might be acceptable if the business owner documents a workaround and deadline. Use clear severity thresholds before cutover.
If rollback is activated, communicate one authoritative system to all users. Stop the destination's write-producing integrations before switching sources to avoid replaying events. Preserve logs and backups from both systems for investigation. Run a small, prioritised reconciliation of transactions generated during the launch attempt, then update the migration plan. Never solve a confusing transition by indiscriminately deleting newly imported records before establishing which records contain valid post-cutover activity.
Step 13: Secure the data and preserve legal obligations
Customer lists and interaction histories can include personal information, commercially confidential pricing and even sensitive notes. During migration, copies multiply: an admin export, a cleaned worksheet, a vendor upload, a backup archive and an error file may all hold overlapping data. Each copy needs a purpose, an authorised custodian, an appropriate retention period and a deletion or archiving decision after completion.
For UK-regulated processing, the UK GDPR's principles include data minimisation, accuracy, security, storage limitation and accountability [13, 14, 19]. Migration may also require reviewing provider contracts, access to subprocessors and international data transfers where relevant. This guide is operational advice, not a substitute for a legal assessment of your circumstances. A business working under different national rules should apply the law relevant to its customers, locations and processing activities.
Minimum practical safeguards: use accounts with only the privileges necessary, restrict raw export access, protect data in transit and at rest as appropriate, separate test data from production, document third-party access, record what left the source system, and give special care to security-sensitive or high-risk data. Rotate or revoke temporary migration credentials after completion. Avoid using personal email accounts or public file-sharing links to exchange exports.
A suppression list deserves particular care. Someone who unsubscribed from marketing should not become contactable simply because the destination has a blank checkbox rather than an “opted out” state. The ICO advises businesses to maintain suppression or “do not contact” information so they do not repeatedly contact people who have objected [12]. Preserve provenance where required, not just a yes/no flag with no context.
Decide what happens to the old CRM
There are three common outcomes: retain an appropriate read-only account for a limited period, export approved historical data to a secured archive, or terminate the service after verification. Compare the actual cost of read-only access with the risks of losing historic information. Check the old vendor's cancellation, export and data deletion terms before the last working day, and confirm whether any employees need access for unresolved disputes or legal retention.
Do not keep every old export forever because it feels safer. The ICO's storage-limitation guidance notes that excessive retention can increase risk and compliance burden [20]. Equally, do not erase the only usable record of a customer contract simply to reduce the number of systems. Adopt documented, purpose-based retention periods and obtain appropriate sign-off.
How long does a CRM migration take—and what will it cost?
A small, well-organised contact database may be moved in a short planned window. A larger environment with custom objects, large file volumes, multi-currency pipelines and operational integrations can require much longer. The migration duration depends on data quality, source export coverage, destination capabilities, stakeholder availability and the number of test cycles. A vendor promising “migration in a day” may be describing the copy stage, not the entire operational change.
Costs fall into six groups: extraction, data cleaning, schema and field mapping, transfer or tooling, validation, and cutover/support. Add potential CRM plan upgrades for custom objects or advanced imports, consultant fees, temporary overlapping subscriptions, file storage, training and staff time. Ask for an explicit scope before accepting a fixed price. Professional assistance may be worth paying for when customer relationship history, reporting or compliance are business-critical.
Hypothetical planning calculation
Imagine a 12-person sales team planning a migration that requires 24 hours of administrator work, 40 hours of data preparation, 30 hours of integration work and 16 hours of testing and cutover support. At illustrative internal or contractor rates of £35, £30, £65 and £40 per hour respectively, the labour estimate is £4,630: £840 + £1,200 + £1,950 + £640. If the business budgets an additional £800 for a specialist tool and £500 for overlapping subscriptions and contingency, the planning total becomes £5,930.
These are invented scenario assumptions, not quotes from CRM providers, a market-price estimate or proof of what any particular migration costs. The example illustrates why comparing only monthly CRM subscriptions can conceal the transition's largest expense. Replace each rate and duration with quotes and workload estimates relevant to your project. For material migrations, include contingency for source-data cleanup that emerges only during testing.
Common migration failures and how to fix them
The import says “complete,” but hundreds of records are missing
Inspect the import job's skipped/error file and compare missing legacy IDs to the source register. Look for required fields, encoding problems, invalid options, file size limits, permission restrictions or records excluded by a filter. If the tool skips an entire category because an expected parent record does not exist, fix the parent stage and retry safely using stable IDs. Pipedrive documents mandatory fields and skipped-item behaviour [21].
Contacts are attached to the wrong companies
Pause additional related-object imports. Examine the matching rule and crosswalk: if the association relies on company names, two similarly named companies may have been merged. Rebuild the relationship mapping using verified unique identifiers where possible. Re-run association reconciliation and inspect a risk-based sample, including accounts with subsidiaries or multiple domains.
Emails, notes or deal histories show the wrong date
Check whether the importer accepted an activity date, assumed a local time zone, or assigned the current date as the creation date. Confirm which historic audit fields the destination allows users or APIs to set. If accurate timestamps cannot be reproduced in the live UI, store an authorised historical archive with clear provenance; do not falsify dates or imply the activity occurred at the migration time.
Opportunity values are wrong
Check currency codes, number separators, imported product lines, tax handling and default currency. Compare one deal at a time and then totals by currency and pipeline. Avoid repairing a financial mismatch through a blanket formula unless the root cause is identified and signed off. Restoring the wrong amounts can make the forecast look mathematically consistent while still distorting revenue decisions.
Duplicates appear after a second import
Stop further retries until you know whether the tool used create-only, update-only or upsert behaviour and which unique field was mapped. A spreadsheet of emails may not provide a valid key for all records. Use the source-to-target crosswalk to distinguish genuine duplicates from separate records that happen to share a mailbox, surname or organisation. Correct the matching setup and test a small batch before repeating the remaining work.
Automations send unwanted messages
Disable the relevant workflow or connector in a controlled manner and inspect which records entered it, when and why. Check whether imported records met “new lead” or status-change conditions. Review marketing preferences before attempting any customer communications. Re-enable only after the trigger has been narrowed and a harmless end-to-end test passes.
Staff cannot see the records they need
Check ownership, teams, permission sets, record sharing and visibility defaults. Export/compare a permissions matrix if the products support it. A global-admin demonstration cannot prove that a salesperson has the correct access. Also verify that restricted records have not become visible to broader teams; inappropriate extra access is as important as missing access.
A practical migration checklist
Use this checklist as an editorial planning tool, adapting it to your systems and risk level. Assign an owner and evidence link to each checkpoint rather than ticking tasks solely because someone says they are finished.
Before the migration:
- Agree scope and the meaning of success; identify the business sponsor and final decision-maker.
- Inventory objects, records, attachments, workflows, integrations and marketing preferences.
- Classify what must be live, what may be archived and what may be excluded.
- Confirm destination support, import permissions, licences, vendor contracts and security review.
- Export complete source evidence, record counts and field definitions; prove the backup is readable.
- Create source ID retention, field mapping, owner mapping and stage mapping documents.
During pilot and full transfer:
- Configure target users, fields, pipelines, relationships and safe test conditions.
- Run a representative pilot that includes edge cases, attachments and opt-outs.
- Approve fixes to mapping, duplicate treatment and unsupported fields.
- Transfer in named batches; keep source-to-target ID crosswalks and error logs.
- Reconcile counts, values, ownership, relationships, activities, files and suppression status.
At launch and after:
- Decide the cutover window, final delta strategy, go/no-go criteria and rollback owner.
- Freeze or queue source writes, transfer final deltas and rerun priority checks.
- Switch forms, email, phone and other integrations to the destination exactly once.
- Test representative business workflows with real user roles and harmless records.
- Track defects, support staff, close stale integrations and decide old-CRM retention.
Frequently asked questions
Can I migrate a CRM without losing any data?
You can substantially reduce the risk of missing or incorrect information through full inventories, controlled exports, stable identifiers, testing and reconciliation. But a promise of zero loss is unsafe unless you establish exactly which data and metadata the destination supports. Some audit histories or proprietary activity types may have to remain in an archive rather than appear as native records.
What is the best way to migrate contacts and deals?
For a straightforward data model, a supported native importer can work well. Configure unique identifiers, import required parent objects, map stages and ownership, and then verify deal-contact-company associations. For more complex structures or histories, use the destination's dedicated migration pathway or a carefully evaluated specialist/API approach.
Can I transfer emails, calls, notes and attachments?
Sometimes, but not necessarily in exactly their original form. Coverage varies by source, destination, plan and transfer method. Check each type independently for content, dates, original authors, related records and access permissions; document what must remain in an archive. For example, Zoho CRM documents attachment-aware migration structures while HubSpot applies particular import rules to activities [17, 4].
Should I clean up my database before migration?
Yes, but avoid unexplained mass deletion and aggressive name-based deduplication. Correct obvious formatting, resolve important duplicates with reliable evidence, preserve legacy IDs and log substantive transformations. Retain personal information only where relevant and permitted, but preserve business-critical and legally required records in the appropriate system or archive.
Do I need to shut down the old CRM immediately?
No. Many businesses benefit from keeping a limited, controlled reference period while the new system is verified. Ensure only one system is authoritative for new writes and document how any post-cutover updates will be handled. Check contracts, retention obligations and export access before cancelling the source service.
Is a CSV export enough to back up a CRM?
Not automatically. A general CSV export may contain only certain objects and current field values, rather than attachments, activity history, configuration, permissions or audit logs. Confirm the export categories and test recovery before relying on it. Pipedrive and HubSpot both document significant distinctions between record exports and other data types [1, 2].
How do I stop a migration from sending emails to customers?
Identify all workflows, webhooks and messaging integrations that can run after imported records are created or updated. Isolate or safely disable those triggers during testing, and use test records that cannot reach real recipients. Re-enable controlled automations only after verifying preferences, recipient criteria and the new data's behaviour.
Which CRM is easiest to migrate to?
There is no universal answer. The easiest destination is one that supports your specific data types, unique IDs, associations and business workflows with transparent import errors and a workable exit plan. A basic CRM may be easy for contacts but inadequate for a business with complex linked objects; a more powerful platform may require more setup to achieve the same transfer.
How do we know that the migration really succeeded?
Require documented sign-off based on object-level counts, stable-ID matches, monetary reconciliation, sampled fields and relationships, preserved restrictions, integration smoke tests and operational user acceptance. Record every approved exclusion and unresolved limitation. An “import successful” notification from the software is supporting evidence, not the final acceptance criterion.
Final verdict: Protect the meaning of the data, not just the rows
The right migration plan begins with an inventory and an explicit definition of success, not with a new CRM subscription. For a small organisation with clean contacts and a simple sales pipeline, a native importer plus careful mapping, testing and counts may be enough. For a team whose work depends on relationship history, custom objects, customer restrictions and connected systems, investing in specialist expertise and staged reconciliation may be justified.
The largest practical mistake is treating a high import percentage as proof that the business is ready. A company record without its linked deals, an opportunity without its owner, or a contact without its marketing preferences can be worse than a visibly missing row: it appears trustworthy while telling staff the wrong story.
Keep the source recoverable, preserve unique IDs, pilot the difficult cases, reconcile the relationships, and only cut over when real workflows pass. If something cannot be reproduced accurately, document it and preserve the relevant information in an appropriate archive instead of claiming it migrated. That is how a CRM change can improve operations without sacrificing the history customers and teams rely on.
Sources and fact-checking notes
The following official documentation was consulted for the product-specific details and relevant UK information-governance guidance. Checked 9 October 2026. Product interfaces, feature access and plan restrictions can change; confirm the pages against your actual subscriptions before a live migration.
- Pipedrive — Exporting data from Pipedrive. https://support.pipedrive.com/en/article/exporting-data-from-pipedrive
- HubSpot — Export your records. https://knowledge.hubspot.com/import-and-export/export-records
- Pipedrive — Importing data into Pipedrive with spreadsheets. https://support.pipedrive.com/en/article/importing-data-into-pipedrive-with-spreadsheets
- HubSpot — Import records for multiple objects. https://knowledge.hubspot.com/import-and-export/import-objects
- Salesforce — Insert, Update, or Delete Data Using Data Loader. https://help.salesforce.com/s/articleView?id=inserting_updating_or_deleting_data.htm&language=en_US&type=5
- Salesforce — Export Backup Data from Salesforce. https://help.salesforce.com/s/articleView?id=sf.admin_exportdata.htm&language=en_US
- HubSpot — Export property history. https://knowledge.hubspot.com/properties/export-property-history
- ICO — Encryption and data protection. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/encryption/encryption-and-data-protection/
- Pipedrive — How to avoid duplicates during an import. https://support.pipedrive.com/en/article/how-to-avoid-duplicates-during-an-import
- HubSpot — Format import files. https://knowledge.hubspot.com/import-and-export/set-up-your-import-file
- ICO — Guidance on direct marketing using electronic mail. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/
- ICO — Respect people's preferences. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/respect-peoples-preferences/
- ICO — Principle (c): Data minimisation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
- ICO — Principle (d): Accuracy. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/
- Salesforce — Import Related Records with an External ID in Salesforce Data Loader. https://help.salesforce.com/s/articleView?id=000383207&language=en_US&type=1
- Microsoft — Import data in model-driven apps. https://learn.microsoft.com/en-us/power-apps/user/import-data
- Zoho CRM — Migrating Data Between Zoho CRM Accounts. https://help.zoho.com/portal/en/kb/crm/data-administration/data-migration/articles/migrating-between-zoho-crm-accounts
- HubSpot — Format import files (activity and date requirements). https://knowledge.hubspot.com/import-and-export/set-up-your-import-file
- ICO — A guide to the data protection principles. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/
- ICO — Principle (e): Storage limitation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/
- Pipedrive — Importing: mandatory fields. https://support.pipedrive.com/en/article/importing-mandatory-fields
- Microsoft — Create a relationship between tables by using a lookup column. https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-entity-lookup
- HubSpot — Export contact data. https://knowledge.hubspot.com/import-and-export/export-contact-data
- Pipedrive — Import fields. https://support.pipedrive.com/en/article/import-fields
Editorial methodology: This is a documentation-based procedural guide, not a report of ToolRankers performing a live customer-data migration. The figures in the worked examples are clearly identified as hypothetical. Product capabilities and legal requirements are attributed to their sources; migration recommendations reflect independent editorial analysis. No migration tool, outcome or benchmark was invented.