CRM migration: a step-by-step checklist

CRM data migration is moving records out of one CRM and into another: contacts, companies and deals, the fields on them, and the links between them, so a contact still belongs to its company and a deal still belongs to both.

It is one part of a CRM migration. The other is rebuilding what the data sits inside, such as pipelines, automations, reports and permissions, which don't travel in an export.

This guide covers the data move from the export to the first two weeks in the new CRM, what gets rebuilt around it, who does what, and when a migration service is worth paying for. The risks are in Risks of migrating your CRM. Cleaning and enriching the data while it is out of both systems is in The hidden gap in migrating your CRM data.

Work through this list as you go, and run down it again before cutover. Each line has its step further down the page.

A CRM export is rows and columns, so anything that is a row can move in a file. Anything that isn't needs the new CRM's own migration tooling, a migration service or rebuilding by hand.

Custom fields, pipelines, users, automations, reports, forms and integrations don't travel in an export. Each one is rebuilt in the new CRM, or created by the new CRM's own transfer tool where it covers your old one, and the rebuild needs a list and an owner as much as the data does.

Check that tool before you plan to rebuild by hand. HubSpot's Smart Transfer, for example, creates properties, pipelines and users in HubSpot from your old CRM's settings before it moves the records, for the apps it supports. It also adds a few workflows of its own, to fill dates and fields the two CRMs store differently. HubSpot's list of them for each app has only these, none of your old CRM's automations, so plan to rebuild those.

Operelio moves field data only: contacts, companies and the values on them. None of the rows below is something it does.

A migration needs four jobs filled. On a small team two people can hold all of them. What matters is that each job has a name against it before anyone exports a file.

Loading the data takes hours. The weeks go on the work around it, and most of that work is the steps on this page: deciding what moves, cleaning, mapping, the test batch, rebuilding fields, pipelines and automations in the new CRM, then the catch-up at cutover and two weeks of small fixes after it.

Scope sets the length more than the number of records. Contacts and companies on a small team, with someone who knows both CRMs, take weeks. Deals, activity history, custom objects and integrations each add their own work, and that is when it runs to months.

The CRM vendors' own guides give similar ranges. Salesforce's says simple migrations may take a few weeks and larger ones several months. HubSpot's puts a small migration (under 25,000 records, standard objects, few integrations) at 4 to 6 weeks and a mid-sized one at 2 to 4 months. Both sell CRMs, so treat their ranges as rough (both read Oct 14, 2026).

Which route fits depends on how much data there is, how much history you need and who is doing the work.

Hire one when activity history, logged emails or attachments have to move, or when nobody on the team has the hours and knows both CRMs. If you're moving contacts, companies and a manageable number of deals, and someone knows both systems, the steps on this page are enough.

A service also earns its fee when you have custom objects or many record types linked to each other, or when the data is regulated and someone has to answer for how it was handled. If the new CRM's own transfer tool covers your old one, try that first: HubSpot's Smart Transfer is available on every HubSpot plan, though mapping custom fields with it needs a Data Hub subscription.

There are two kinds. A migration tool such as Import2 connects to both CRMs and copies the records, and their history where the pair of CRMs allows it, after you map the fields. A done-for-you service, from the same vendors or from a CRM partner or agency, plans, maps, runs and checks the move for you. Import2's pricing page lists its tool starting from $499, or free for a small migration a CRM vendor sponsors, and its consultant-run migration starting from $5,000 (read Oct 14, 2026).

Before you sign, ask these four questions.

HubSpot has two ways in. Smart Transfer (Data Management, Data Integration, Transfer data) connects to the old app and moves records, properties and pipelines across. It covers Pipedrive, Zoho CRM, Dynamics 365, ActiveCampaign, Copper, Mailchimp, Keap, Salesforce, Account Engagement (Pardot), Marketo, Zendesk, Freshdesk and monday.com. Only a Super Admin can run it, mapping custom fields needs a Data Hub subscription, and a transfer can be reverted. It is meant for a one-time move: if you'll keep using Salesforce afterwards, HubSpot says to use its Salesforce integration instead, because running both creates duplicate records.

Smart Transfer moves records as they are, duplicates included, so clean the old CRM before it starts. For any other source, or to clean between the two, use the file route on this page with HubSpot's importer. Its advanced imports take several objects at once and create the associations between them, and it imports calls, meetings, notes and tasks as well as records. HubSpot matches contacts on email and companies on domain, so dedupe both before the load.

Moving everything is the default, and it usually means paying to migrate records nobody will use. Settle these before anyone exports a file.

Export each record type as its own CSV: companies, contacts and deals. Every major CRM has a bulk export in its settings or admin area.

Keep each record's ID from the old CRM in the file, along with the IDs that link it to other records: the company ID on a contact, the contact and company IDs on a deal. Store each old ID in a custom field in the new CRM (a unique-value property in HubSpot, an External ID field in Salesforce). Importers use it to link records, and it leads you back to the original later.

Keep the original exports untouched. Every Operelio tool writes a new file and leaves the upload alone, but your own copy is what you roll back to.

Upload each export and run Data Health Check. You get a quality score from 0 to 100, every issue found (invalid emails, duplicate rows, mixed date formats, placeholder values, encoding problems and dozens more), and every row counted under what it needs: Must fix, Should fix, Tidy‑up or Ready. A score of 80 or above means the file is ready to import, 60 to 79 is worth reviewing, and below 60 the data needs fixing first.

The report tells you what to fix before the move. Re-run Data Health Check on the cleaned file afterwards and you have a before and after score to compare.

Start with duplicates. Decide which copy of a record wins before you remove the others. Deduplicate keeps the first or last occurrence, so sort the export by its last-modified column and keep the last occurrence, which is the most recent version. Deduplicate contacts on email and companies on website or name. Smart matching treats Westmarch Trading and Westmarch Trading Ltd as one company, and similarity matching catches typos. Keep the file of removed rows: if a deal points at a removed duplicate's ID, repoint it to the record you kept before you load deals.

Removing a duplicate row in the file drops that row whole. Neither Deduplicate nor the CRM Formatter, which keeps the first row with each email, combines values from the copies, so if the row you drop holds a phone number or a title the kept row lacks, copy it across first.

Merging inside a CRM works differently. In HubSpot, the record you pick as primary keeps most of its property values, the other record fills the properties the primary has empty, and the associations of both carry over. A HubSpot merge can't be undone, so pick the primary with care.

Next, work down the rest of the report. Clean Headers tidies inconsistent column names, and Find & Replace handles fixes that repeat across the file, such as a legacy placeholder value that should be blank.

Finally, check the data is still current. Email verification finds the addresses that will bounce, and Company Active Check finds companies whose website no longer works, so neither goes into the new CRM. Full email verification and Company Active Check are on Starter and up.

Each tool writes a new file, so you can always step back a version if a fix went further than you wanted. The hidden gap in migrating your CRM data covers this stage in more depth, including enrichment.

For a single list rather than a whole CRM, see cleaning data before or after a CRM import.

Open the CRM Formatter, upload your cleaned file and pick the target CRM's format. Every plan includes eight built-in formats (HubSpot, Salesforce, Pipedrive, Zoho CRM, monday CRM, Freshsales, Close, Copper) and a Generic format. For anything else, custom templates are on Starter and up. There are also ready-made CRM-to-CRM migration templates (Zoho to HubSpot, Salesforce to Pipedrive and more) that pre-fill the mapping when your move matches one.

Operelio auto-maps columns by name: "First Name", "first_name" and "fname" all land on the first name field. Adjust the rest by hand, picking the column for each native field in your new CRM. If a column has no matching field, leave it unpicked so it isn't forced into the wrong one; it shows under Not used from your file.

Map the old ID column to the custom field from step 1. Unmapped columns are left out of the downloaded file by default, so an unmapped ID column would be lost.

If you migrate in weekly batches, save the mapping after the first run and load it for each later file. Saved mappings are available on Starter (25), Pro (150) and Agency (300).

Before you run it, Review shows every row before and after clean-up. It doesn't list rows with an invalid email, a blank required field or a phone with no digits, so filter for those in the file before you import. A push counts the rows your CRM won't take before anything is sent.

If your workspace has a Do Not Contact list (Starter and up), the CRM Formatter screens each file against it and leaves out anyone on it.

The table below lists the mismatches between two CRMs that fail an import, or load wrong values without an error.

Pick 50 to 100 rows that cover the awkward cases: a contact with no company, a company with several contacts, an owner who has left, a record with every field filled. Load them, open them in the new CRM and check each field landed where you meant, the links are there and the dropdowns show the right values.

Fix the mapping and run the batch again until it comes through clean. A wrong mapping caught in the test batch takes minutes to fix. After the full load, you have to correct every record it touched. If you load through the CRM's own importer, delete the test records before the full import, or they arrive twice.

Load parent records before the records that hang off them: users, then companies, then contacts, then deals, then tickets and custom objects, then activities and attachments if they are moving. A contact loaded before its company has no company to link to.

For any target CRM, download the import-ready CSV and load it with the new CRM's own importer. This path works for all eight built-in formats, the Generic format and custom templates.

When the target is HubSpot, Salesforce or Pipedrive, you can skip the download and push directly (Starter, Pro and Agency). You connect via OAuth, so your CRM password is never stored.

Push creates records that don't exist yet and updates the ones that do. By default it only fills fields that are blank in the CRM, as the answer to "Will pushing overwrite data already in the new CRM?" below explains.

Before the push, the push card shows three counts that add up to your row count: what will be created, updated or not sent, with the reason for each row not sent, including rows the CRM won't accept. After the push, the report counts Created, Updated, Refused and Not sent. On a migration you can also set the owner from a column in the file, or assign the whole push to one rep, so each record lands with the right owner.

On Salesforce and Pipedrive, a company column on a contacts push finds or creates the company and links the contact to it. A HubSpot push creates contacts and companies but doesn't link them, so if those links matter, load the contacts through HubSpot's own importer with the ID columns.

Deals go in through the new CRM's own importer or a migration service, using the IDs you kept in step 1 so each deal links to its company and contacts. On Salesforce that means Data Loader, because the Data Import Wizard doesn't import opportunities.

Decide how you would undo a load before you run one. The test batch in step 5 is the first line: a wrong mapping shows up on 50 to 100 rows, not on the whole file.

Tag every load. Add a Migration batch column holding the load date to every file, and map it to a custom field. Decide before the load what would make you stop: counts that don't match, missing links, wrong owners. If a batch fails that test, filter the new CRM on its batch value, delete those records, fix the file and load it again.

Use the CRM's own undo where it has one. HubSpot's imports dashboard lists the records each import created or updated, and you can select and delete them there. Pipedrive lets a global admin revert an import from the import history within 48 hours. A HubSpot merge can't be undone, so leave merging duplicates in the new CRM until the counts are signed off.

Deleting undoes only the records a load created. If the new CRM already held records and the load updated them, deleting them loses the originals, so export the new CRM before you load into it. Your untouched exports from step 1 are the copy of the old CRM to start again from.

Count what arrived against what you sent, for each record type. A push reports how many rows were created, updated, refused by the CRM and not sent. The new CRM's own importer gives you an error file. Compare against the formatted file, not the raw export: the CRM Formatter drops blank rows and repeated emails by default. Every row missing between what you sent and what arrived needs explaining before the team starts work.

Then open a sample of records and compare them with the old CRM field by field, including the owner and the links to companies and deals. When you sign off the migration, record the cleaned file's Data Health Check score next to the step 2 score.

If the team can stop entering data for the move, set the old CRM to read-only when you export and there is almost nothing to catch up. If they can't, freeze it on the cutover date instead, then export everything created or updated since the main export and run it through the same steps. With a saved mapping, that catch-up file maps itself.

If you push the catch-up, choose Overwrite with my data. Its values are newer than the ones you loaded, and the default, Only fill blank fields, would leave the old ones in place. On Salesforce an overwrite with a blank cell clears that field, so check the file has no blanks where the CRM holds a value.

On cutover day, repoint the web forms and integrations you listed in the plan, then submit a test form and check the record lands in the new CRM. Keep the old CRM read-only until the team is working in the new one without going back to check.

Expect questions and small fixes for the first two weeks. Give one person the job of answering them, and keep a shared list of every problem reported: a missing field, a wrong owner, a view that doesn't show what it used to.

Check the things that break without anyone noticing. New leads should be arriving from forms and integrations. Rebuilt reports should show the numbers the team knows from the old CRM. Anyone who opted out since cutover should be marked in the new CRM.

Once the list stops growing, take a final full export of the old CRM and store it with the archive of records you chose not to migrate. Then close the old account.