The decision to switch CRMs is usually made in frustration: the old one is clunky, the automations never worked, the vendor raised prices. The migration is then done in a weekend by exporting a CSV and importing it into the new system. Six months later someone needs the note from a customer's last call, or proof that a contact consented to text messages, and it is gone.
A CRM migration is a data project first and a software project second. Here is how to run it so the second system starts with everything the first one knew.
Inventory what you actually have
Before touching the new system, list what the old one holds. Not just contacts. Specifically:
Contacts and companies, with every custom field you added over the years.
Notes and activity history. Calls, emails, texts, and the free-text notes that carry the real relationship.
Pipeline and deal records. Every open estimate, its stage, its value, and its history.
Consent records. When and how each contact opted in to email and to SMS, and what language they agreed to. This is the item most often lost, and it is the one you cannot reconstruct. A marketing text without a provable consent record is a liability, and a migration that drops the record turns your whole list into that.
Tags and segments. Every tag, what it means, and who applies it.
Automations. Every workflow, its trigger, and its steps. These will not migrate; you are rebuilding them, and you need the spec.
Integrations. The website form, the phone system, the booking calendar, the invoicing tool. Each one is a connection to re-establish.
Attachments. Photos, signed agreements, PDFs attached to contacts or jobs.
Write it down as a spreadsheet. This is the migration plan.
Clean before you move
Moving a messy database into a new system produces a messy new system with a fresh coat of paint. Use the migration as the forcing function for the data hygiene you have been putting off.
Merge duplicates in the old system before export. Standardize phone formats. Retire tags nobody uses. Close or archive dead deals. Decide what to do with contacts who have never engaged and have no consent record: often the answer is to migrate them into a "no marketing" segment rather than delete them, since they may have job history worth keeping.
Map the fields
For every field in the old system, decide where it lands in the new one. Most fields map directly. The ones that do not are the custom fields and the dropdowns, where the old system's "Lead Source: FB" needs to become the new system's "Source: Meta Ads."
Consent deserves special handling. Bring over the consent status, the date, the source (which form, which page), and if the old system stored it, the disclosure text. If the new system does not have fields for all of that, create them. Do not reduce it to a yes/no.
Notes and activity history are the hardest. Some systems export them as a single text blob per contact. Some export a separate activity file. Some do not export them at all through the standard tool and require the vendor's help or an API script. Find out before you commit to a cutover date.
Run a test migration
Export everything, import into the new system, and check. Not a sample; check specific contacts you know well. Does the customer who booked three times last year have three jobs? Does the contact who opted out of texts show as opted out? Do the open estimates show the right stage and value?
Fix the mapping, wipe the test import, and run it again. Two or three cycles is normal. This is the step people skip, and it is where the real problems surface while they are still cheap.
Rebuild the automations deliberately
Do not recreate every old workflow. Many of them were broken, redundant, or never fired. Take the list from the inventory, keep the ones that produced results, and rebuild them in the new system one at a time, testing each with a real contact before turning it on for everyone.
The pipeline stages should be designed fresh rather than copied, using what you learned from the old system's data about where deals actually stall.
Cut over on a quiet day
Pick a day with low volume. Freeze changes in the old system, run the final export and import, repoint the website forms and the phone integration, and start working in the new system. Keep the old system in read-only mode for at least a few months so anyone who needs an old record can find it.
Tell the team what changed and what did not, in writing, before the day. Most migration failures are not technical; they are a team that went back to the old spreadsheet because nobody showed them where the new pipeline was.
If you would rather not run the migration yourself, talk to us before you export anything.
Frequently asked questions
Can the new vendor do the migration for me?
Often, and it is worth asking. But they migrate what you tell them exists. The inventory is still yours to do, and you should verify the result.
What about contacts who never gave consent?
Migrate them with the consent field empty and exclude them from marketing until they opt in through a new form. The job history is still valuable.
How long should I keep the old system?
Until you have gone through one full seasonal cycle without needing it. For most service businesses that is close to a year.
We are on spreadsheets, not a CRM. Same process?
Same process, simpler inventory. The consent question is even more important, because spreadsheets rarely record it at all. This is where a managed CRM build-out usually starts.