Migrating your CRM: a step-by-step guide to switching without losing data

A CRM migration done properly follows seven stages. Plan the scope. Export the data. Map the fields. Run a staged import. Verify the results. Cut over the live system. Train the team. Skip any of these and you lose data, history, or the goodwill of the people who have to use it. Do all seven and the whole thing is unexciting, which is exactly what a migration should be.

Most CRM migrations fail for the same three reasons. The business underestimates the hidden complexity of its own data. It rushes the cutover to beat an artificial deadline. It treats training as an afterthought. Avoid those three mistakes and you will be fine. This article walks through how.

Why businesses migrate, and when it is the wrong call

Before you migrate, be honest about why. The good reasons are that your current CRM cannot do something critical, that the cost has grown unjustifiable, that integrations you need are missing, or that your team has effectively stopped using it and a fresh start will break the habit. The bad reasons are that a salesperson called, that a competitor is on a different platform, or that the new interface looks prettier. If you are not sure your current tool is wrong so much as underused, our guide to choosing a CRM for your small business is a useful sanity check before you commit to a migration.

The cost of a migration is not just the subscription. It is the forty to eighty hours of your time, the disruption to the sales pipeline, the retraining, and the period where two systems are running side by side. That cost is often five to ten thousand pounds in practical terms for a small UK business, once you count your own time at a realistic rate. If you cannot name a problem the new CRM will solve that is worth more than that, stay where you are.

Stage one: plan the scope

The biggest mistake is treating migration as a single big bang event. Break it into parts. At minimum you will migrate contacts, companies, deals or opportunities, and activity history. You may also have custom fields, files and attachments, notes, email integrations, tasks, pipeline stages, user permissions, and reporting.

Write a list of everything that lives in the current system. Against each item, note three things. Is it essential, useful, or nice to have? What is the complexity of moving it? What happens if we lose it? This list is the skeleton of your migration plan and you will refer to it constantly.

Agree a freeze window. You will need a period, typically a weekend, during which no new data enters either system. This is non-negotiable. Changes made during the import window are the number one source of data loss. Communicate the freeze to everyone who uses the CRM, including sales, support, and anyone feeding in form submissions.

Stage two: export the data

Most modern CRMs, HubSpot, Pipedrive, Zoho, Salesforce, offer CSV or native export tools. Use them. Do not rely on third-party scrapers if you can avoid them.

Export contacts, companies, deals, and activities as separate files. Each file should carry the unique identifier from the old system, which you will need later for mapping and deduplication. Also export custom field definitions, pipeline stages, deal stages, tags, and user lists. These are the building blocks the new system needs to recreate your setup.

Attachments and files usually require a separate process. Some CRMs export them as a zip, others require an API call per record. For a business with thousands of attachments, this is often the longest single step, and it is worth starting it days before the rest of the migration so it can run in the background.

Check your exports. Open the CSVs, count the records, and confirm the totals match what the CRM reports in its dashboard. If there are ten thousand contacts showing in the interface and nine thousand in the export, you have a problem and you need to find out why before you proceed.

Stage three: map the fields

This is where most migrations go wrong, and also where a careful two hours saves a painful two days later.

List every field in the source system. List every field in the destination system. Draw a line between them. Some will map directly, such as first name, last name, email, phone. Some will need a new field created in the destination, usually custom fields unique to your business. Some will not map at all and you will need to decide whether to create them, merge them into a notes field, or drop them.

Pay particular attention to picklists and dropdown fields. If your old CRM has a customer status field with the values Cold, Warm, Hot, Won, Lost, and your new CRM uses different labels, you need to transform the values during import. A CSV find-and-replace works for small lists. Larger ones need scripting.

Deal stages are the most dangerous. If your old pipeline has seven stages and your new one has five, the merging logic matters. Losing the distinction between Proposal Sent and Proposal Reviewed might cost you the insight that drives your conversion rate. Think carefully, and keep a historical record of the original stage in a notes field if in doubt.

Stage four: run a staged import

Do not import everything into the live new system in one go. Create a sandbox or test environment first, often a free trial account of the destination CRM, and import a subset, say one hundred records, to confirm the mapping works. Inspect the imported records in detail. Do the custom fields populate correctly? Are relationships between contacts and companies preserved? Do activity notes appear against the right records?

Only when the test import is clean do you move to the full import. Most CRMs recommend a specific order. Companies first, because contacts often belong to companies. Contacts second. Deals third, because deals reference contacts and companies. Activities last, because activities reference deals.

Deduplicate aggressively during import. Most tools offer a dedupe-on-email option. Use it. You do not want the migration to be the event that doubles the size of your contact list with duplicates.

Stage five: verify the results

Run checks. At minimum, confirm that contact counts match source and destination. Confirm deal totals by stage match. Spot-check twenty records across different segments, especially unusual ones like very old contacts, contacts with multiple companies, and deals with long histories.

Run the reports you depend on. If your weekly pipeline report shows different numbers in the new system than it did in the old, find out why before you go live. Sometimes the answer is a definition change, a deal amount field being interpreted differently, which is fine as long as you understand it. Sometimes it is a data error that needs fixing. The reports themselves should line up with the short list in our piece on small business analytics and what to track.

Ask two or three of your sales or customer-facing staff to check their own pipelines. They know their accounts better than any migration tool, and they will spot problems you will not.

Stage six: cut over the live system

The cutover itself should be boring. You have prepared, tested, verified. All you are doing is flipping the switch.

Pick a low-activity window. For most UK businesses this is Friday evening or a Saturday. Announce the freeze. Pause any integrations that push data into the old system, your contact form, your chat tool, your accounting link. Run a final delta export of anything that changed since your last import. Bring those deltas into the new system. Unpause integrations, now pointed at the new system. Confirm data is flowing correctly. Archive the old system, do not delete it, for at least three months.

Stage seven: train the team

The best migration is pointless if the team reverts to sticky notes and personal spreadsheets. Train before the cutover, not after. Record a fifteen-minute walkthrough of the new system showing how to do the five most common tasks, log a call, move a deal, create a contact, send a sequence, pull a report. Make that video available on day one.

Run a single live training session of thirty to forty-five minutes. Keep it focused on what has changed. Do not try to teach the whole system. Teach what is different from the old one. Take questions. Write down the ones you cannot answer and follow up within forty-eight hours.

Appoint a CRM champion on the team, someone other than you, who answers day-to-day questions. This single decision, more than any feature of the new CRM, determines whether adoption sticks. That person should document the new way of working, which is the same habit we recommend in how to systematise your business so it runs without you.

The common pitfalls

Custom fields are usually where time disappears. Each custom field has to be recreated manually in the destination, because they are unique to your business and the system cannot guess them.

Relationships between records, a contact belongs to a company, a deal belongs to a contact, are preserved only if you import in the right order and use matching identifiers.

History is often lost silently. Email history in particular rarely migrates cleanly, because the old CRM stored it linked to its own contact IDs, which mean nothing to the new system. Be realistic, you may keep the old CRM in read-only mode for six months for historical reference, and that is fine.

Automations never migrate. Every workflow, sequence, and trigger in the old system must be rebuilt in the new one. List them in advance, rebuild them in priority order, and test each one before cutover. A migration is usually a good excuse to revisit the whole automation stack, which we cover in how to automate your small business.

Plan a quiet weekend, not a heroic sprint

A well-executed CRM migration is a non-event. A badly executed one is three weeks of grief. The difference is almost entirely in the planning, not the execution.

If you want a second pair of eyes on your migration plan, or you are weighing up whether to migrate at all, our business audit can help you think it through. Or book fifteen minutes and we will talk it through directly.