CRM Migration: A Plan for Inventory, Mapping, Cleansing, Cutover and Rollback

A CRM migration moves your customer, company, deal and activity data from one system to another and rebuilds the rules that surround it. The data move is the visible part. The harder part is deciding what each field in the old system means and where that meaning lives in the new one.

Projects go wrong when the plan starts at import. Teams export everything, discover that three fields hold the same fact in different formats, and fix problems in the new system under deadline. Spending the first stage on inventory and mapping moves that work to a point where it is cheap.

Choose an owner on your side who can make decisions about data, not just relay them. Migrations stall when every question about a field has to be escalated, and the consultant or vendor cannot decide what your sales team calls a qualified lead. This person also approves the mapping sheet, which turns it from a technical document into a business agreement.

List every object (contacts, companies, deals, tickets, notes, emails, meetings, files), how many records each holds, and which fields are populated. For each field note who uses it, which reports or automations depend on it and whether it is a default field or a custom one. A field no report, workflow or person uses is a candidate for leaving behind.

Inventory the connections too: forms, email tools, billing, support desks and any integration that reads or writes the CRM. Those are the places where cutover breaks quietly, because a form that still posts to the old system will keep creating leads nobody sees.

Record the state of the source as evidence. Export counts and a sample of records before any cleansing, because later someone will ask whether a record was lost in migration or never existed. A dated snapshot answers that. It also gives you a baseline for the reconciliation you will run after the load.

Build a mapping sheet with one row per old field: its name, type and sample values, the target object and property in the new system, the transformation needed, and the owner who approved it. HubSpot's import documentation sets the shape of the files you feed it. Each file must be a CSV or Excel file with one sheet, and a header row whose columns correspond to properties in HubSpot. Files with non-English characters should be UTF-8 encoded.

The same documentation affects design choices. Imports can create new records, update existing ones or both, and updating requires a unique identifier in the file. HubSpot deduplicates contacts by email address and companies by domain name, so a contact without an email will not match, and shared company domains need thought. Some data cannot be updated by import at all: HubSpot states that existing emails, meetings, notes and tasks cannot be updated through it. Decide before the first load which records are created once and which will be re-run.

Test the awkward cases deliberately. Include records with missing emails, shared company domains, very long text, special characters, and dates in more than one format in the first test file. These are the rows that fail, and finding them in a test costs an hour, where finding them in production costs a week of manual repair and awkward questions from the sales team.

Clean in the source or in a staging copy, not after load. The common jobs are merging duplicates, standardising picklist values (one spelling of each industry or country), fixing dates into one format, removing records with no contact route and no history, and deciding what to do with contacts who unsubscribed or asked for deletion. Consent and opt-out status must travel with the record; losing it can mean emailing someone who already said no.

Set a cut line for age and activity. A policy such as "migrate contacts with a deal, a meeting or any activity in the last N years, archive the rest as a flat file" is easier to defend than a case-by-case argument. N is your decision, and a regulated business should confirm its retention duties with counsel or its professional body before discarding anything.

Keep a log of every bulk change you make: what rule was applied, to how many records, and who approved it. Merging two thousand duplicates is a decision with consequences for ownership and history, and the log is how you explain it later. Where a merge is uncertain, prefer to keep both records flagged for review over losing one.

Run a full test import into a clean account or sandbox, then have the people who use the data check named records against the old system: a customer with a long history, a company with several contacts, a deal mid-pipeline, a contact who unsubscribed. Fix the mapping, reload and repeat until the checks pass. HubSpot's import tool reports errors per import, so keep that log with the mapping sheet.

Plan cutover as a short freeze: stop edits in the old system, take a final export, load changes made since the test, repoint forms and integrations, and switch users over. Keep the old system read-only for an agreed period and keep the exports somewhere safe. Rollback in this setting rarely means switching back. It means you can still find any record you need, and that is only true if you decided what to retain before cutover.

Choose the cutover date to suit the business calendar rather than the project plan. A month-end close, a trade show or the first week of a campaign are poor times to move reps to a new screen. Many teams cut over on a quiet weekend and keep the first Monday free of meetings so that questions can be answered on the spot.

For the first weeks, compare counts and spot-check records daily: records by object, by owner and by lifecycle stage against the pre-migration totals, new leads arriving through each form, and workflow enrolments firing as expected. Differences you can explain are fine. Differences you cannot explain are the migration's defects.

Then hold a short review with users, because they will find the problems the counts cannot, such as a field that moved to a tab nobody opens. Log decisions and open items in the same place as the mapping sheet so the next change starts from a record, not from memory.

Keep one person responsible for the reconciliation, with a short written checklist and a date by which it ends. Without a stop date, post-migration monitoring either lingers for months or lapses unnoticed, and neither outcome tells you whether the new system is trustworthy. Close the project formally once the counts agree and the open issues list is empty.