Switch in stages, never in one weekend. Inventory everything the old system does, including the quiet jobs nobody mentions. Build an import you can run more than once. Carry consent and permissions across with the records, not after. Rebuild automations from the process rather than copying them. Then run both systems on real work, pick a switch-off date, and keep the old data readable afterwards.
Inventory what the old system actually does
Most migrations fail on the things that were never written down. The scheduled reminder that fires at 7am. The webhook pointing at an old form. The one report finance opens on the last working day of the month.
Before you touch data, build four lists: records, jobs, integrations and permissions. Walk the list with the people who use the system daily, not just the person who bought it.
| What to list | Why it breaks a switch | Where it usually hides |
|---|---|---|
| Record types and fields | Custom fields silently drop on import | Admin settings, not the main views |
| Files and attachments | Stored separately from records, so links break | Contracts, ID documents, signed quotes |
| Conversations | Email and SMS history is often the only record of a promise | Inbox threads tied to a user, not a contact |
| Automations and scheduled jobs | Reminders stop or fire twice during parallel running | Workflow builders, calendar automations |
| Integrations and webhooks | Forms keep posting to the system you turned off | Website forms, ad platforms, payment tools |
| Reports and saved views | Finance and sales lose their monthly numbers | Saved filters owned by individual users |
| Roles and permissions | Everyone gets admin "temporarily" and stays there | User list, rarely audited |
When not to migrate at all
If the current tool does the job and the complaint is really about process, switching will cost money and change nothing. Migrate when the system blocks work you need to do: roles it cannot support, data it cannot join, or subscriptions stacking up across tools that do not talk. TMMB Academy came to us with a fragmented funnel, rising software subscriptions and no single system, and the answer there was one portal with role-specific workspaces for admins, coaches, creators, sales, assistants and brands. That is a real reason to move. "The interface annoys me" is not.
Build an import you can run twice
A one-off import is a gamble. A repeatable import is a process you can test, fix and rerun until the numbers match.
Three rules make it repeatable. Give every record a stable external ID from the old system so a rerun updates rather than duplicates. Run against a sandbox or a test environment first. Reconcile with counts, not vibes: contacts in, contacts out, and a written explanation for every gap.
Expect to clean as you go. Duplicate contacts, dead email domains and half-finished deals are easier to resolve before they land than after. Decide deliberately what you are not bringing: archived leads from four years ago usually belong in a CSV export in cold storage, not in your new CRM setup and migration.
Carry consent and permissions across, not just the records
Marketing consent is data too. If your old system recorded who opted in, when, and to what, that evidence has to arrive with the contact record. Importing a contact without its consent state is how businesses end up emailing people who unsubscribed two years ago.
Be specific about what consent covers. Under UK PECR, automated marketing calls need the person's specific prior consent, and general marketing consent is not enough (ICO guidance). The same care applies to unsubscribe flags, do-not-contact markers and anything a client asked you to delete.
Permissions deserve the same discipline. Map old roles to new ones before launch and decide who can see financial data, client documents and message history. We build in the client's own accounts with clear permissions, which also means the client owns the code and the data at the end of it.
Rebuild automations from the process, not by copying
Copying twelve old workflows into a new tool copies twelve old assumptions. Write down what each automation is for, in a sentence, then rebuild only the ones that still earn their place.
Watch for double sends. While both systems are live, the same enquiry can trigger a reminder in each. Decide early which system owns outbound messages during the overlap, and switch the other to internal notifications only.
Volume costs money as well as attention. In Zapier, each successful action step counts as a task, triggers and filters do not, and at your plan limit new runs are held unless you pay for extra tasks (Zapier help centre). A parallel run can double your action count for a month, so budget for it or you will discover the limit on a Monday morning. If you are rebuilding anyway, that is the moment to ask whether those chains belong in workflow automation you own rather than rented steps.
Run old and new side by side before switching off
Parallel running is the part people skip and the part that saves them. Pick a slice of real work, route it through the new system, and keep the old one available but read-only where you can.
Test real cases and failure paths, not just the happy path. A booking that gets cancelled. A payment that fails. A client who replies to a three-week-old email thread. We test edge cases and failure paths before anything touches a customer, because the expensive errors are always the ones nobody rehearsed.
Set a switch-off date in writing and name the person who makes the call. Open-ended overlaps turn into two systems forever, which is the problem you started with.
What our own migration out of GoHighLevel taught us
We migrated our own CRM out of GoHighLevel into a system we built, and it is complete, confirmed by the owner on 2 October 2026. Doing it on ourselves changed how we scope it for clients.
The useful lesson is about counts. The owner deliberately reset the CRM on 26 September 2026, so the import counts describe what that migration carried across, not current inventory. Those records must not be reimported. Without that note written down, a future tidy-up would have pulled old data back in and corrupted the live set.
So keep a migration log: what ran, on what date, what it carried, and what is now out of scope forever. Treat it as part of the handover documentation, not a side note.
Go/no-go checklist before you switch off
- Record counts reconcile between old and new, with a written reason for every difference.
- Files open from the new records, not from old links.
- Consent and unsubscribe states are present and spot-checked against the old system.
- Every live form, ad platform and payment integration now posts to the new system.
- Outbound messaging has one owner, with no duplicate sends in the last two weeks of the overlap.
- Roles and permissions are set per person, with no blanket admin.
- Finance can reproduce last month's numbers in the new system.
- The team has been trained and has written documentation.
- A full export of the old system is stored somewhere you can read in two years.
- A named person owns the first two weeks after launch.
If you cannot tick all ten, you are not ready to turn the old system off. You are ready to extend the overlap.
Your next step this week
Spend an hour building the inventory table above for the system you want to replace, and ask two colleagues what breaks if it disappears on Friday. That list is the scope. If it points at a bigger problem than one tool, read how to choose a CRM for a service business before you commit, or compare approaches in our CRM migration guide. When you want a second pair of eyes on the plan, book a call and we will walk through it with you.
