A CRM migration moves your records, relationships and history from one platform to another. Do it in order: decide what to leave behind, clean the data at the source, map every field and pipeline stage, run a small test import, then cut over during a short freeze. Rebuild reports and routing before anyone calls it done.
Platform switches tend to get planned as software projects. The vendor demo goes well, a contract gets signed, and the data move is treated as a weekend task for an admin. Then the new system opens with duplicate accounts, deals in the wrong stage and activity history stamped with the import date. The sections below follow the sequence that avoids that, from scoping through the first month on the new platform.
A CRM migration starts with what you leave behind
The first decision in any CRM migration is scope, and the right scope is smaller than most teams expect. Every old CRM carries dead fields, abandoned pipelines, test records and contacts nobody has touched in years. Moving all of it means paying to map, clean and store data that will only clutter the new system. Write down which objects, fields and date ranges actually move, and get sales, marketing and finance to sign that list.
Bad data has a measurable cost, which makes the case for trimming. Gartner says poor data quality costs organizations at least $12.9 million a year on average, a figure from its 2020 research, and that 59 percent of organizations do not measure data quality at all (Gartner). A migration is the rare moment when you have to look at every field anyway. Treat the scoping list as part of your wider marketing technology plan, since the CRM feeds email, ads and reporting downstream.
Clean CRM data at the source before a CRM migration
Cleanup belongs in the old system, before any file is exported. Salesforce's own import guidance tells admins to clean the import file first by removing duplicates, deleting unnecessary information, correcting spelling errors and enforcing naming conventions (Salesforce Trailhead). Merging duplicates in the source keeps one surviving record ID, which matters later when you rebuild associations.
Fixing data after it lands is harder than it sounds. HubSpot's import tool ignores blank cells, so a later import with an empty column will not clear a bad value that is already in the new CRM (HubSpot). Standardize picklist values such as industry, lead source and country now, while the CRM migration team still has one system to fix, and decide which system of record wins for each field. Treat consent fields as untouchable: the opt-in source and timestamp behind every marketing text are your proof of consent, as our guide to SMS vs email marketing explains. Our guide to CRM data quality lists the fields that break routing and AI agents first.
Field mapping is the real CRM data migration work
Field mapping decides whether the new CRM tells the truth. Every source field needs a destination, a data type and an owner, and every picklist value needs a match. Salesforce's Data Import Wizard does not import unmapped fields, formula fields cannot accept imported data because they are read-only, and a value that misses a restricted picklist falls back to the default or fails (Salesforce Trailhead). On the HubSpot side, new deals need a pipeline and deal stage that already exist in the account (HubSpot).
Build the mapping as a spreadsheet the business can read, with one row per field and a column for the transformation rule. Add a legacy ID field on every object in the new CRM and fill it with the old record ID, so you can trace any record back after cutover. Rebuild calculated scores such as lead scores or customer health scores in the new platform from their inputs, since a migrated number with no live formula behind it goes stale the day you switch.
Import limits shape the CRM migration plan
Tool limits decide how many passes the move takes, so check them before you set a date. Salesforce's Data Import Wizard handles up to 50,000 records at a time for common objects such as accounts, contacts and leads, while Data Loader handles up to 150 million records and supports scheduled, automated loads (Salesforce Trailhead). HubSpot's paid plans accept files up to 512 MB and up to 10,000,000 rows a day, with a cap of 1,048,576 rows per file, and free accounts are limited to 500,000 rows a day (HubSpot).
Order matters as much as volume. Load companies or accounts first, then contacts, then deals, then activities, so each object has a parent to attach to. HubSpot warns that an import without unique identifiers such as email, company domain or record ID creates duplicate records, and the associations you wanted never form (HubSpot). Keep the record IDs from step two in every file and the associations follow. Then write the CRM migration timeline backwards from these limits: number of files, number of passes, and the hours each pass needs, with a buffer for one failed load you have to repeat.
Salesforce to HubSpot migration has a native path with caveats
Teams moving from Salesforce to HubSpot can pull records through the native connector before they switch Salesforce off. HubSpot's integration imports leads, contacts, accounts, opportunities, tasks, campaigns, cases and events, and it requires a Professional or Enterprise subscription (HubSpot). The same documentation flags two catches: at the moment of import only the email address comes over for leads and contacts, with other fields filled by the sync that follows (unless an inclusion segment leaves the contact out, in which case they stay blank), and large imports can take several hours to protect your Salesforce API calls.
The connector also checks for changes roughly every 15 minutes, so while both systems are live, edits in either one can flow across (HubSpot). That helps during a phased move and causes trouble if nobody owns the field update rules. The HubSpot to Salesforce migration direction usually runs on Salesforce's Data Loader, the tool Salesforce points to for loads above 50,000 records (Salesforce Trailhead), with the same mapping and test discipline. Whichever direction the CRM migration runs, the platform choice now carries more weight, as we covered in headless CRM after Dreamforce 2026, because agents and integrations will read whatever data model you land on.
CRM migration cutover and the first 30 days
Run a test import before the real one, and run the real one during a short freeze. Salesforce recommends importing a small test file first to confirm the source data was prepared correctly, and suggests temporarily deactivating workflow rules and checking validation rules that would block records (Salesforce Trailhead). Announce a freeze window, set the old CRM to read-only, load in the planned order, then reconcile record counts and pipeline totals by stage against the source before reopening.
The first month is for proving the new CRM matches reality. Turn automations back on one at a time, re-test lead routing and assignment, and compare the open pipeline report with the last snapshot from the old system. Collect user complaints in one place for the first two weeks; most of them point to a mapping rule that needs one more fix, and early fixes cost far less than a quarter of reps working around bad data. Reconnect ad platform conversion feeds early, since a broken offline import quietly degrades bidding; our post on Google Ads lead quality covers that link. If you want a second pair of eyes on a CRM migration plan before you set the date, talk to our team.
