TL;DR: Reconcile records, history, and integrations before switching CRMs. Keep one system in charge of live work during the parallel run, capture every change at cutover, and test rollback before reopening sales.
A CRM, or customer relationship management system, holds the records your team uses to sell and serve customers. Moving those records is only part of replacing it. Cutover is the moment the new system takes responsibility for live work.
This runbook starts after you have approved the move. If that decision is still open, use the CRM migration cost and cleanup comparison first. The question here is whether a rep can find the right customer, see usable history, and take the next action after the switch.
What should a CRM migration checklist include?
A CRM migration checklist should cover records, relationships, history, access, integrations, live-work ownership, validation, and rollback. Preserve record relationships with stable source IDs and a checked source-to-destination ID map. Assign a person and a passing result to every item before choosing the cutover date.
A source ID identifies a record in the old CRM; the destination may assign a different ID. The map connects those two identities so a contact's deal stays attached to the right company. Customer names alone are not reliable keys.
This protects the workflows described in our sales automation guide: routing, follow-up, activity capture, and clean handoffs. Automation can execute the wrong action perfectly when its customer relationships or owner fields are wrong. Test the business action alongside the imported row.
Use the following scenarios to define your data migration requirements. Each needs more than a successful contact import.
| Business | What must survive | User check after migration |
|---|---|---|
| B2B services | Company, buying contacts, open deal, proposal, next task | Rep opens a deal and finds its decision-maker and next step |
| Home services | Customer, service address, estimate, booking, assigned rep | Coordinator follows a new inquiry through estimate follow-up |
| E-commerce | Customer-to-order reference, support context, opt-out state | Support sees the correct order without restarting a sales sequence |
| SaaS | Account, subscription reference, renewal date, account owner | Renewal owner sees the right customer and renewal task |
| Multiple locations | Branch ownership, record visibility, shared customers | Branch user sees authorized records and cannot open another branch's restricted data |
Map records before moving them
Create one mapping sheet per object, such as companies, contacts, deals, and activities. Include source field, target field, type, required status, transformation, owner, and validation rule. Resolve duplicates before freezing the baseline; the CRM data hygiene sprint covers that preparation.
Keep original IDs as migration references, even when email or domain is a supported matching key. Record deliberate merges in the map: several old contact IDs may point to one approved survivor. An unexplained many-to-one mapping is a defect, and an email address change must not silently create a second customer.
Load dependencies in the order supported by the destination. For example, create companies before importing contacts and deals that reference them. Salesforce explains that relationships depend on record IDs and supports either an ID crosswalk or suitable External ID relationships in its organization migration guide.
Map retired users to an approved active owner, while retaining the original owner as historical context when needed. Check pipeline stages, date formats, time zones, currency codes, and required fields. Test visibility as an ordinary rep as well as an administrator; an admin seeing everything proves little about sales access.
Can you migrate CRM activity and field history?
You can migrate supported activity records and preserve exportable history in an archive, but you cannot assume the new CRM will recreate the old timeline or audit trail. Decide separately what becomes a native record, what stays in a searchable archive, and what cannot be exported. Test those choices on old and unusual records before committing to them.
| History type | Migration treatment | Evidence to check |
|---|---|---|
| Notes, calls, meetings, emails | Import through a supported activity route | Original event time, author context, body, associated customer |
| Tasks and open follow-ups | Preserve status, owner, due time, completed state | Completed work stays completed; due work appears once |
| Attachments and recordings | Transfer supported files or retain authorized archive access | File opens for the intended user; required retention is possible |
| Field-change history | Export supported audit records separately | Old value, new value, actor, event time; known gaps listed |
| Reports and attribution | Archive baseline outputs and document definitions | Same filters, stages, currencies, and cutoff before comparing totals |
HubSpot's multiple-object import can create, but cannot update, emails, meetings, notes, and tasks. Its import documentation distinguishes these activities from objects that support updates. Re-uploading an activity file is therefore not a safe retry strategy by itself.
Maintain an import ledger linking each source activity ID to its batch, acceptance result, and destination ID where available. Check accepted records before retrying a timeout; replay only confirmed missing activities. If acceptance cannot be determined, stop that batch and resolve it instead of guessing.
Preserve the original event timestamp separately from the import timestamp. Do not turn a historical email into a new outbound email or re-enroll an old customer in follow-up. Archive access also needs an owner, access controls, retention rules, and a tested retrieval method; keeping an expired legacy URL is not preservation.
How do you run two CRMs in parallel without duplicate work?
Run the new CRM in shadow mode while the old CRM remains responsible for live work. Copy approved changes into the destination for comparison, but prevent it from sending messages, assigning real work, or updating connected systems. Users should not edit the same production records independently in both CRMs.
Parallel run means comparing outcomes, not doubling activity. Keep destination workflows that send, bill, notify, or enroll customers disabled. Test those actions with controlled records and destinations in a supported test environment, then record how production settings will differ.
Give each integration a simple contract:
| Connection | Authority that stays in place | Cutover check |
|---|---|---|
| Website form → CRM | One intake route owns each submission | Same submission ID produces one lead and one intended alert |
| CRM → email platform | One CRM controls sales-triggered enrollment | Historic imports cannot start new outreach |
| Booking tool → CRM | Booking system owns meeting status | Reschedule or cancellation updates the correct meeting once |
| Billing system → CRM | Billing system owns payment state | CRM reflects payment without creating another charge or invoice |
| CRM → reporting store | One active extraction route per dataset | Old and new IDs do not double-count one deal |
Track a source event ID, record ID, version or ordered position, destination result, and retry state. A duplicate event should have the same effect as processing it once; that property is called idempotency. Confirm it for the actual connector rather than assuming the CRM provides it for every action.
Run the same new-lead, owner-change, stage-change, and cancellation cases through both paths. Compare expected results after the destination has caught up to the same source position. Reuse the form-to-CRM integration checks for hidden fields, duplicate matching, owner alerts, and source data.
Execute the CRM migration project plan in seven steps
A CRM migration project plan needs an ordered task list, named owners, measured timings, passing checks, and a stop decision. Validate the migration by comparing record IDs, relationships, critical values, and end-to-end business actions at the same cutoff. Equal total record counts alone do not establish a correct migration.
Keep the working packet under a clear name such as “CRM Migration Cutover Runbook: Records, History, Integrations, and Parallel Run.” Attach the mapping sheet, batch ledger, integration inventory, test results, and rollback instructions. Microsoft's cutover guidance calls for task owners, backup owners, verification, sign-off, and a rehearsed rollback plan.
1. Name the decision owner and freeze the design
The operations lead owns go/no-go, with a backup who can make the same decision. The CRM admin owns imports; the integration owner controls connectors; a sales lead signs off real user tasks. In a small business, one person may hold several roles, but every role still needs coverage.
Freeze field, pipeline, workflow, and mapping changes during rehearsal. Keep normal customer work running in the source until the scheduled write freeze. Publish a cutover start time, latest rollback decision time, support contact, and approved fallback intake process.
2. Rehearse the full route with controlled records
Use a sandbox or isolated test account supported by your CRM. Include a duplicate, missing required value, retired owner, restricted record, historical activity, attachment, deleted record, and open deal. Test a second import and a failed batch as well as the happy path.
Measure export, transfer, import, validation, and recovery time with realistic volumes. Microsoft recommends a 20–30% migration-time buffer for monitoring overhead. Its go-live planning guidance is the source for that allowance; add separate time for your measured rollback and user checks.
3. Load the baseline and start shadow comparison
Export a consistent baseline and retain its export job ID, cutoff, file counts, and checksums. A checksum helps detect a changed or corrupted file; it does not prove that the export included every required record. Use protected storage and keep migration access limited to the people doing the work.
Load the reviewed records with destination side effects disabled. HubSpot free-tool imports allow files up to 20 MB and 500,000 rows in a rolling 24-hour period. Check the current file and import limits before sizing batches; a fresh calendar day does not reset a rolling limit.
4. Freeze writes and capture the final delta
The final delta is every relevant change after the baseline, including inserts, updates, deletes, merges, relationship removals, cleared fields, and permission changes. First pause source users and scheduled jobs, stop connector writes, and let in-flight work settle or enter a durable holding queue. Keep new inquiries recoverable while both CRMs are closed to normal writes.
Use a supported change feed or a reconciled export comparison. A filter on a record's last-modified date may miss deletions or child-relationship changes. Record both the UTC cutoff and the source's ordered change position where available; use overlap plus deduplication when timestamps have limited precision.
Apply changes through the agreed cutoff and verify there are no unresolved batches. HubSpot's file-format guidance says blank cells do not clear existing values. Handle intended clears and deletions through an explicitly tested route; never let an older snapshot restore a newer opt-out or deleted record.
5. Complete the data migration validation checklist
Compare expected destination records against the approved source scope, accounting for documented merges and archives. Check relationships and values, then have a rep complete a task from intake to follow-up. The following are proposed launch gates, not vendor defaults.
| Check | Passing evidence | Stop condition |
|---|---|---|
| Records | Every in-scope source ID has its expected destination or approved disposition | Missing ID, unexpected extra record, or unexplained merge |
| Open pipeline | Deal IDs, amounts, currencies, stages, owners, and next steps match | Any unexplained critical-field mismatch |
| Relationships and history | Expected links reconcile; risk-based samples open with correct context | Broken required association or inaccessible required history |
| Access | Rep can perform authorized work; restricted test is denied | Unauthorized visibility or blocked critical user task |
| Intake and follow-up | Controlled submission reaches one owner and one intended action | Lost lead, duplicate task, or duplicate outbound action |
| Final delta | Changes through cutoff applied; rejected and pending work accounted for | Unknown acceptance state or untracked held events |
Also run a data migration testing checklist for failure paths. Simulate an API timeout after acceptance, an expired connection, malformed data, duplicate delivery, and two changes arriving out of order. Passing means visible recovery without duplicate side effects or older values overwriting newer ones; otherwise hold the affected workflow.
6. Switch ownership and release held events
Stop the old connectors' write authority before starting their replacements. Disable scheduled jobs, delayed retries, and outbound workflows, then confirm nothing remains in flight. Switch the intake destination and process held events in order, with the tested duplicate controls.
Keep legacy webhook endpoints receiving or safely forwarding delayed events until their senders have switched. A connector showing “connected” does not prove old traffic has stopped. Check provider delivery logs and the event ledger for gaps, especially across the final cutoff.
Enable a limited production workflow, send a controlled new inquiry, and verify the customer record, owner, next task, and intended notification. HubSpot notes that owners assigned by import receive no assignment notification in its import rules. Test the live notification path separately from imported ownership.
7. Open access and monitor the first business cycle
Reopen sales only after the decision owner records the passing checks. Keep the source read-only, retain recoverable destination changes, and watch failed events, queue age, unassigned leads, duplicate work, and pipeline differences. Assign someone to review exceptions through the first relevant sales and reporting cycle.
For a proposed four-hour maintenance window, reserve the last hour for a rollback that rehearsal proved fits. If the required checks have not passed by the three-hour decision point, begin recovery while time remains. Those timings are an example; calculate your own deadline from measured work and an agreed recovery allowance.
How do you roll back a CRM migration safely?
Pause destination writes and side effects, recover every change accepted since cutover, and reconcile those changes into the old CRM before it resumes ownership. A pre-cutover backup cannot contain a lead or opt-out created after the switch. If current changes or accepted actions cannot be recovered, keep affected work paused and use the approved fallback intake process.
Rollback has different costs before and after live work begins. Before launch, you can usually keep the source authoritative and abandon the destination import. After launch, you need a tested return path for new IDs, updates, deletions, task completion, and permission changes.
Use this order:
- Stop and hold. Freeze destination edits and outbound actions, pause both connector routes, and retain new inbound work.
- Resolve acceptance. Check which messages, tasks, or downstream requests were already accepted, including timed-out requests.
- Recover the delta. Export destination changes and map new destination records back to source identities; check conflicting changes explicitly.
- Reconcile and test. Apply supported changes with automation off; verify current opt-outs, deleted records, owners, open tasks, and required relationships.
- Return ownership. Re-enable one source route, release held events safely, and verify a controlled new inquiry before reopening users.
An email sent or charge accepted by another system cannot be undone by restoring CRM data. Keep evidence of those actions so rollback does not repeat them. If the old CRM cannot represent essential new data, the tested response may be a forward repair instead; decide that limit before go-live.
A small-team cutover example
A useful cutover result is proven continuity of customer work, followed by a measured reduction in ongoing effort. The following operator composite is hypothetical, not a public customer claim or a measured That'sGonnaHelp engagement. Its business counts, costs, timings, and results are planning assumptions.
Consider an eight-rep B2B services firm moving to HubSpot. Its approved scope contains 9,600 contacts, 1,200 companies, 240 open deals, and 18,000 historical activities. An operations coordinator spends an assumed ten hours per month repairing broken follow-up and reconciling spreadsheets.
The team uses source exports, Excel mapping sheets, HubSpot's supported import tool, and an existing integration platform for intake. It creates the company/contact/deal map and a separate activity ledger. Quotes remain in a protected document store, with tested links from their destination deals.
Rehearsal exposes two failures: replaying a notes batch creates duplicates, and a cleared source field remains populated after CSV import. The team fixes the batch recovery process and uses a supported field-clear operation. It repeats both failures before approving the cutover window.
The composite uses a shadow run, but some businesses cannot. HubSpot reports that Marq faced a 90-day migration deadline and could not run both platforms live together. Its named public case describes manual data uploads and a hard cutover; that different, larger-company situation does not validate this composite's schedule or results.
In the assumed acceptance record, all scoped IDs have an approved destination, all 240 open deals retain their required links, and controlled duplicate events produce one intended action. The team also verifies a rollback with a newly created lead and a later opt-out. These are modeled test outcomes, not evidence that any production migration will have zero errors.
Suppose monthly repair effort later falls from ten hours to two. At an assumed $60 per hour, eight recovered hours are worth $480; subtract an assumed $120 in added monthly operating cost for a $360 monthly net benefit. With $3,600 in one-time effort and transition costs, simple payback is ten months, provided the team actually realizes that value.
How much does CRM migration cost?
CRM migration cost includes mapping, history handling, integration work, rehearsal, staff training, overlapping subscriptions, and recovery time. The table models a $2,660–$4,700 planning range for a modest scope, with the composite at $3,600. These are assumptions, not a market average or a quote; replace them with your actual requirements.
| Cost line | USD planning range | Composite budget or price basis |
|---|---|---|
| Mapping, transfer, integration testing, training | 36–60 hours × $60 = $2,160–$3,600 | 48 hours = $2,880; assumed labor |
| Temporary overlap and migration access | $300–$600 | $400; assumed allowance |
| Archive setup and monitoring | $200–$500 | $320; assumed allowance |
| One-time total | $2,660–$4,700 | $3,600; sum of the three project lines |
| Salesforce Starter Suite | From $25/user/month | Public starting price; monthly or annual billing |
| Salesforce Pro Suite | From $100/user/month | Public starting price; annual billing and contract |
Salesforce Starter Suite starts at $25 USD per user per month; Pro Suite starts at $100, billed annually with a contract. These public prices were checked September 7, 2026; transaction fees apply. They illustrate license costs, are not the composite's HubSpot quote, and do not establish import or integration entitlements for your account.
Use the automation ROI calculator to vary one-time cost and realized monthly benefit. Simple payback is one-time cost divided by monthly net benefit: $3,600 ÷ $360 = ten months in the composite. If recovered staff time has no realized value, keep it separate from cash savings; the example does not claim revenue uplift.
When comparing CRM migration services, ask what the quote includes beyond row transfer. Specify attachments, activity recovery, required clear/delete operations, integration tests, training, and rollback evidence. CRM migration software that moves contacts cheaply may leave the hardest work in your team's hands.
CRM data migration best practices and limits
Use this runbook when the destination fits the workflow and the team can test a controlled handover. Delay the move if required history cannot be preserved, access rules cannot be reproduced, or nobody can recover changes during an outage. CRM data migration best practices do not make an unsupported data model or unrecoverable integration safe.
A small team with one CSV and no live integrations may need a brief import and freeze, not a custom change-capture service. A business that cannot pause writes needs a proven synchronization design and conflict policy beyond this generic runbook. Regulated records or unusual retention duties also need their own reviewed requirements before exports are retained or accounts retired.
Avoid five common mistakes:
- Checking totals alone. Two missing contacts and two duplicates can leave the count unchanged.
- Treating every import as an update. Activity creation and blank-field behavior differ by route.
- Leaving both systems active. Old schedules and delayed retries can recreate work after cutover.
- Calling an old export a rollback plan. It omits post-cutover leads, deletions, and completed actions.
- Canceling the old account too soon. Archives, delayed integrations, and recovery access may still depend on it.
FAQ
The remaining decisions concern scope, tool fit, duration, and when the old CRM can be retired. Resolve them before scheduling the production switch. The answers below separate the operating choices in this runbook from capabilities that must be checked in your actual accounts.
What is CRM data migration, and what is CRM migration?
CRM data migration moves selected customer records and their relationships into another system. CRM migration is the wider change: data plus configuration, access, integrations, reports, and the way people work. A contact import can be complete while the wider migration still fails a sales handoff.
How long should the CRM parallel run last?
Run it long enough to observe the normal workflows and delayed jobs that matter to your business. For a modest daily sales process, three to five business days can be a starting planning window, not a researched benchmark. A weekly report, renewal job, or long delay needs a separate test or a longer observation period.
Which CRM migration tools should a small team use?
Start with supported native import or migration tools if they cover your records, relationships, and history. Use a supported connector for repeatable changes only after testing its limits and recovery behavior. Choose custom API work when a required gap justifies the maintenance and the team can prove safe replay and reconciliation.
When can you retire the old CRM?
Retire it after the agreed recovery period and after every remaining dependency has a verified replacement. Confirm archive retrieval, report access, late event handling, record links, exports, and contract cancellation terms. A calendar date alone is insufficient if any required history or incoming event still depends on the old account.
Does migrating a contact reset their marketing permission?
No. Treat permission as current state with its source and scope, not as a benefit of importing the contact. Carry forward opt-outs and unresolved permission without enrolling those people in outreach. Check the destination's native subscription controls and the requirements that apply to your audience separately.
Can CRM reports disagree even when the records match?
Yes. The systems may use different stage definitions, date fields, currency conversions, or attribution rules. Compare the underlying deal IDs and values first, then align the report definitions and cutoff. Keep old published reports labeled as historical snapshots; do not rewrite past performance merely to make the dashboards agree.
Answer clarity notes
This article is an operating runbook with proposed launch gates, not proof that a specific CRM account is ready to migrate. Public documentation supports the attributed platform facts. The recommended controls and composite business math serve different purposes.
- Dates: publication and source checks are September 7, 2026. Vendor documentation may describe earlier updates; no case-study deadline is a promise about your project.
- Pricing and ROI: public Salesforce starting prices are separate from the $2,660–$4,700 planning range and illustrative $3,600 budget. Labor rates, overlap costs, savings, ten-month payback, and planning windows are assumptions, not guarantees or quotes.
- Evidence: the B2B services example is a hypothetical operator composite. Marq is a named HubSpot customer story, reported by the vendor; its hard cutover is not a measured result from That'sGonnaHelp.
- History and recovery: an archive preserves accessible exported evidence, not necessarily native timeline behavior or a complete audit trail. Rollback cannot unsend messages or undo accepted external actions.
- Scope: this guide supports US SMB operations planning. It does not determine legal retention, consent obligations, contractual rights, or a platform's permission to import particular data; those need the appropriate account and professional review.
Sources
These primary sources support the stated migration practices, import behavior, public pricing, and named case. The launch thresholds, failure tests, and composite budget are this article's proposed operating guidance. Recheck the specific import route and account tier before cutover.
- Microsoft: Plan and rehearse a cutover
- Microsoft: Data migration planning for go-live
- HubSpot: Format import files and check limits
- HubSpot: Understand supported imports
- Salesforce: Migrate records between organizations
- Salesforce: Small business pricing
- HubSpot: Marq migration case study
That'sGonnaHelp can help turn your object map and integration inventory into a scoped cutover test plan. Bring a sample export, your live workflow list, and the history your team must still be able to use.

