A CRM migration strategy settles three things before anyone exports a file: how you move, how much history comes with you, and what you are prepared to lose for a few weeks. This article answers which combination suits a company of 10 to 250 people moving onto the platform: which records you import (contacts, companies, opportunities), what you rebuild (pipelines, workflows, forms) and how long the old system stays switched on. It argues for one default. Move everyone in a single cutover, bring recent history only, and keep the old system open read-only for a short, fixed window. The day-by-day task list belongs to the CRM migration checklist; this page covers the choices that list depends on.
Three decisions make up the strategy
Every migration plan, however long the document, comes down to three answers. The first is the shape of the move: big bang, phased by team, or a parallel run where both systems stay live. The second is scope: which records and how many years of activity travel. The third is what gets rebuilt rather than moved, which in practice means automations, reports and templates.
Get those three right and the rest is execution. Get them wrong and no amount of careful field mapping saves the project, because the team will be working in a system shaped for the wrong job.
Decision one: big bang, phased or parallel
For a company this size, the default should be a single cutover. Everyone stops using the old system at the same moment and starts in the new one the next morning. It is the most uncomfortable option for a few days and the least painful over a quarter.
A phased move, one team at a time, works only when the teams never share a client. The moment sales and account management both talk to the same person, a phased move means one of them cannot see what the other said. That is how a client gets an upsell call the day after they complained.
A parallel run, where both systems stay live and people update both, is the option to avoid. It feels safe. In practice nobody keeps two systems equally current, so within days the two disagree and neither is trusted.
There is a version of running both systems that does work: a read-only overlap. From cutover morning, every update happens on the platform, and the old CRM stays open for lookups only. Two to four weeks is usually enough. Set the end date before you start, put it in the diary of whoever holds the old contract, and export a full backup before you cancel. Without an end date, the old system quietly becomes the place people check first.
Take a firm with 25 people who touch client records and suppose it runs both systems for ten working days. If each person spends about 20 minutes a day entering the same update twice, that is 25 people times 20 minutes times ten days: 5,000 minutes, roughly 83 hours of duplicated admin, or two working weeks of one person's time. And if the two systems still disagree on 40 deals at the end, someone loses another day deciding which version is correct.
Decision two: how much history to bring
The instinct is to bring everything. Resist it. Old data carries old mistakes, and every record you import is a record your team will search past for years.
A sensible default for a growing company looks like this:
- Every contact you are allowed to market to, plus every current client, whatever their age.
- Every open deal, with its full activity history.
- Two years of notes, emails and calls on active records.
- Closed deals summarised as fields, such as last purchase date, total value and reason lost, rather than as hundreds of individual records.
- Everything else in a read-only archive that opens without the old software.
Suppose the old system holds 60,000 contacts. Only 22,000 have had any activity in the last three years, and 4,000 of those are unsubscribed or bounced. Applying the default above would bring 18,000 marketable contacts, about 2,600 current and past clients, and 280 open deals. Roughly 39,000 records would go to the archive. A database a third of the original size is quicker to search, and an import of that size fits in an afternoon rather than a weekend.
Decision three: what you rebuild on the platform rather than move
Records move. Behaviour gets rebuilt. On the platform, contacts, companies and opportunities come across as CSV files. Pipelines are set up again with their stages, workflows are rebuilt in Automation, forms are rebuilt in Sites, and email templates are recreated in Marketing. Trying to copy any of these field for field from another CRM is wasted effort.
Treat this as an audit rather than a chore. List what the old system does automatically, and for each item ask whether anyone would notice if it stopped. In many companies a good share of the automations are left over from a campaign or a member of staff long gone. Rebuild the ones that protect revenue first: new lead follow-up, booking reminders, renewal prompts. Leave the rest until someone asks for them.
What most migration advice gets wrong
Most advice treats data loss as the main risk. It is a real risk, and the checklist handles it. But in a company with stalled revenue, the larger loss is quieter: a dip in follow-up during the weeks people are learning the new system.
For a fortnight after cutover, salespeople are slower. They cannot find the view they used, a notification goes somewhere new, a form now feeds a different inbox. New enquiries sit for hours instead of minutes. None of that shows up as missing data, and all of it shows up as lost deals.
So the strategy should protect speed of response before anything else. Inbound routing and first response are configured, tested and switched on before the bulk of the data moves. If the inbound side of the CRM system works on day one, a messy import can be fixed later without costing a single enquiry.
Imagine a company that normally answers new web enquiries within 15 minutes and moves CRMs without protecting routing. If average first response drifts to four hours for the first two weeks while the team learns where notifications now land, and enquiries run at 30 a week, that would be 60 leads answered late. Lose even a handful of them to a faster competitor and the cost outweighs anything an imperfect import could do.
The trade-off you are accepting
This strategy gives things up, and you should say so to the team before they discover it. Older activity is not on the timeline in the new system; to see a note from five years ago, someone opens the archive. A few long-serving salespeople will feel they have lost context. The single cutover also means a short freeze where nobody updates anything, and a week of slower working while habits form.
In return you get one system everyone trusts, a database small enough to keep clean, and automations that someone has deliberately chosen. For a company trying to restart growth, that trade is worth making. For a company whose value depends on long, detailed client histories, it may not be, and the next section covers that.
When a different strategy is right
Bring full history when your obligations require records to be retrievable inside the working system. Firms in regulated work, such as mortgage brokers, should agree the archive approach with whoever owns compliance before deciding scope. Some will choose to bring more history for that reason alone.
Choose a phased move when you genuinely run separate businesses under one roof, with separate clients and separate teams. Agencies and consultants that operate distinct brands sometimes fit this. Real estate firms with separate lettings and sales desks can too, as long as no landlord is also a seller. Phase by business, not by department, and only where clients do not overlap.
Moving the records onto the platform
Before cutover day, export contacts, companies and deals from the old system as CSV files, keep a secure backup, and clean the files: one date format, UTF-8 encoding, no line breaks inside cells. Create a custom field for every summary value you decided to keep, such as last purchase date or total spend, before you import, so the columns have somewhere to land.
Contacts and companies go in first, with a tag that marks where they came from:
- Go to Settings, then Custom Fields, and create the fields you need.
- Open Contacts and click Import Contacts.
- Upload the file and map the fields.
- Add a tag that identifies the source, such as old CRM import, then click Import.
- Review the imported data, build smart lists from the import tag and cross-check the counts against the old system.
Then build each pipeline and import the open deals into it:
- Go to Opportunities, then Pipelines, and click Create new pipeline.
- Enter the pipeline name and every stage exactly as the deal file names them, then click Save.
- Back in Opportunities, click Import and choose to import opportunities.
- Upload the file of open deals.
- Map each file column to an opportunity field, including pipeline and stage.
- Check the preview, start the import and compare the deal count with the old system.
Import open deals only. Closed deals stay as summary fields on the contact, as decided above. Protecting response speed means connecting forms, calendars, phone numbers and your sending domain to Conversations before cutover day, and rebuilding the revenue-protecting workflows next.
If you are still deciding what the CRM itself should achieve, settle the commercial side of your CRM strategy first, because it changes what history is worth keeping. The build and launch phases then sit around the migration itself.
Troubleshooting the import
Contacts import with blank fields. The column was not mapped, or the custom field did not exist yet. Create the field, then re-import the affected rows with the same email address so they update rather than duplicate.
Dates arrive wrong. The file mixed formats. Convert every date column to one format before upload.
Opportunities land in the wrong stage. The stage names in the file must match the stages you created in the pipeline. Rename in the file, not the pipeline, so the pipeline stays as designed.
People keep using the old system. The read-only window has no end date, or nobody announced it. Fix the date and remove edit access in the old CRM.
Frequently asked questions
Is a big bang migration too risky for a 100-person company?
It is less risky than the alternatives, provided the testing happens before the cutover rather than after it. The risk in a single cutover is concentrated in one day you control. The risk in a parallel run is spread across weeks and harder to see.
How do we decide which old automations to rebuild?
Ask what would go wrong if each one stopped. If the answer involves a client, a lead or a payment, rebuild it before launch. If nobody can say what it does, leave it switched off and wait to see who asks.
What should the archive look like?
A complete export in an open format, stored where the people who might need it can search it. Test that it opens and that a typical record can be found within a minute. An archive nobody can open is the same as no archive.
How long should we run both systems?
Do not run both as live systems. Keep the old one read-only for two to four weeks after cutover, for lookups, then back it up and cancel. Every update during that window happens on the platform.
Should we tell clients we are changing CRM?
Usually not, unless their experience changes, such as a new booking link or a different email address for replies. If it does, tell them a few days before, in plain terms, with the new details.