CRM services · Migration
A migration is finished when the reconciliation report says so, not when the import job ends. We map every field in writing, clean and deduplicate before loading, prove the result in trial runs, and plan a cutover you can reverse.
one-offFull export via API, IDs keptAccount · Contact · Deal
one-offMapped staging tables
one-offLoad parents before children
validatedCounts, links and samples compared
one-offFreeze, final delta load, switch integrations
A CRM migration moves your customer records, their relationships and their history from one system to another, and rebuilds the configuration around them: pipelines, automations, reports and permissions. A CRM data migration is the data part of that work. Done properly, it is a controlled transition with a written mapping spec, trial loads, a reconciliation report and a cutover plan that includes rollback.
The inventory covers more than contacts and deals. Relationships and history are where migrations usually lose data.
| Item | How it is handled | What to watch |
|---|---|---|
| Accounts and contacts | Migrated with source IDs stored in an external ID field | Duplicates across both, contacts without an account |
| Deals / opportunities | Migrated with stage mapped to the new pipeline | Stages that don’t exist in the new pipeline, closed-lost reasons |
| Activities | Emails, calls, meetings, tasks and notes migrated as linked activities | Volume and API limits, original timestamps and authors |
| Attachments and files | Downloaded and re-uploaded, linked to their records | Storage limits on the target platform, file size caps |
| Owners and users | Mapped from source users to target users, inactive users to a holding owner | People who have left, shared inboxes |
| Custom objects | Recreated in the target data model, then migrated | Objects with no equivalent; relationship cardinality |
| Pipelines and stages | Rebuilt in the target CRM from the agreed process | An opportunity to fix stages, not copy old mistakes |
| Automations and reports | Rebuilt, not converted. Each rule is re-specified | Rules nobody remembers; reports nobody runs |
| Integrations | Repointed to the new CRM at cutover | Webhooks and API keys still pointing at the old system |
Seven steps. Trial loads repeat until reconciliation passes; only then is cutover scheduled.
Export the source schema, record counts per object, field fill rates and storage used. Interview the CRM owner about what each field means.
DeliverableSource inventory with counts and fill rates
A row for every source field: target field, transformation, validation rule and owner. Fields not migrated are listed with the reason.
DeliverableSigned field-mapping specification
Deduplicate, normalize phone numbers and countries, fix broken relationships, archive records you agree not to move.
DeliverableCleanup log with merge decisions
Load into a sandbox of the target CRM in dependency order: users, accounts, contacts, deals, activities, files.
DeliverableTrial load run log
Compare counts, relationships and sampled field values against the source. Repeat trial loads until the report is clean.
DeliverableReconciliation report per trial
Freeze edits in the source, load the final delta, switch forms and integrations, run a last reconciliation.
DeliverableCutover checklist with timings and sign-off
Daily checks in the first week, fast fixes for anything users find, then the source system is archived.
DeliverableHypercare issue log and archive location
Excerpt from a mapping specification. Every row is a decision someone signed off.
| Source field | Target field | Transform | Rule |
|---|---|---|---|
| Company.Name | Account.name | trim | Required. Records without a name go to review. |
| Company.ID | Account.legacy_id | copy | External ID, unique. Used to link children. |
| Person.Phone | Contact.phone | to E.164 | Country from Account.country when missing. |
| Deal.Stage | Deal.stage | lookup table | “Verbal yes” -> Negotiation. Unknown stages block the load. |
| Deal.Owner | Deal.owner_id | user map | Inactive users -> holding owner, flagged for reassignment. |
| Deal.Amount + Currency | Deal.amount | keep currency | No conversion. Currency code required. |
| Note.Body | Activity.note | HTML -> text | Original created date and author preserved in fields. |
Deduplication is a set of written rules, not a button. Each rule is agreed before it runs.
Contacts match on normalized email; where email is missing, on name plus company domain plus phone. Accounts match on domain, then on normalized name plus country.
MechanismKeys are tested on a sample first and the false-match rate reviewed with you.
When two records merge, a rule decides which value wins per field: most recently updated, most complete, or from a preferred source.
MechanismSurvivorship table per object, part of the mapping spec.
Uncertain matches are not merged automatically. They go to a review list your team can approve or reject.
MechanismReview list with match score and the fields that matched.
Every merge records the IDs of the records combined, so a wrong merge can be traced and undone.
MechanismMerge log kept with the reconciliation report.
What the reconciliation report checks after each trial load and after cutover.
Source count, minus agreed exclusions, minus merges, must equal the target count. Any gap is listed by record ID.
Every contact has its account, every deal its account and owner, every activity its parent. Orphans are counted and listed.
A random sample per object is compared field by field against the source, after transformations. Mismatches are classified as mapping errors or source data issues.
File counts and sizes per object, and spot checks that files open and sit on the right record.
No record left with an unmapped or inactive owner, except those assigned to the agreed holding user.
The last day is planned to the hour. Rollback criteria are agreed before it starts.
Edits in the source CRM stop at an agreed time. Users are told in advance; forms queue or point to a holding page.
CheckSource set to read-only, freeze time logged
Records created or changed since the last trial load are extracted and loaded using the same mapping.
CheckDelta counts match source changes
Web forms, email sync, ERP or billing connections and webhooks are repointed to the new CRM.
CheckEach integration tested with a live record
Final reconciliation on core objects, plus a short smoke test by named users from each team.
CheckReconciliation within agreed thresholds
If a rollback criterion is met, integrations are pointed back and the team continues in the source system while the issue is fixed.
CheckSigned go decision, or rollback executed
Each path has its own constraints. These are the ones we plan for.
| Path | What to plan for |
|---|---|
| Spreadsheets -> CRM | Inconsistent columns across files, duplicates between sheets, no stable IDs. Most of the effort is cleanup and deciding the data model. |
| Legacy or custom system -> CRM | Direct database access or file exports instead of an API, undocumented fields, codes that need lookup tables. |
| Salesforce <-> HubSpot | Different object models (opportunities vs deals, account-contact relationships), association rules, API rate limits on both sides. |
| Microsoft Dynamics 365 -> another CRM | Custom entities, option set values, activity parties on emails and meetings, data in related Dataverse tables. |
| Zoho CRM or Pipedrive -> another CRM | Custom modules or fields, API call limits per day, file and note exports. |
We give a dated plan after the inventory. These are the factors that set it.
Each object needs mapping, ordering and reconciliation. Custom objects also need modelling in the target.
Years of emails and attachments can dominate the load time, limited by API quotas and storage.
Duplicates, missing relationships and free-text codes add cleanup rounds before trial loads pass.
Most migrations need two or three trial loads before reconciliation is clean.
Every connected system must be tested against the new CRM before cutover.
Migration is one part of a platform change. These pages cover the rest.
A CRM migration moves customer data, and the configuration that gives it meaning, from one system to another: from spreadsheets or a legacy database into a CRM, or from one CRM platform to another. Records and their relationships are moved; pipelines, automations, reports and permissions are rebuilt on the new platform, because they rarely transfer one to one.
It depends on the number of objects, the volume of records and activity history, data quality, custom objects, and the API limits of both systems. A straightforward move of contacts, accounts and deals can take a few weeks including trial loads. Migrations with years of activity, attachments and custom objects take longer. The cutover itself is usually planned for a weekend or a low-traffic window.
In stages: inventory the source, write a field-by-field mapping specification, clean and deduplicate, run trial loads into a sandbox, reconcile counts and samples against the source, then freeze, load the final delta and switch over. Records are loaded parents first (accounts, then contacts, then deals and activities) so relationships resolve, using source IDs stored on the new records.
Not if they are in scope. Logged emails, calls, notes, tasks and file attachments can be migrated as activities and files linked to the right records, within the target platform’s storage limits. Some history is better archived than migrated; we list what moves, what is archived and where the archive lives.
Yes, until cutover. Trial loads run against a sandbox while the team keeps using the old system. At cutover there is a short freeze window, typically measured in hours, during which the final changes are loaded and integrations are switched.
The cutover plan has rollback criteria agreed in advance, for example a reconciliation mismatch above a set threshold on a core object. If a criterion is hit, integrations are pointed back at the old system and the team continues there. The old system stays read-only and available until you sign off the new one.
Next step
Tell us where the data is and where it needs to go. The assessment starts with counts and a sample, so the plan is based on your data, not on assumptions.
Request a migration assessmentUseful to have ready
Not everything is needed. A rough answer is enough to start.
