Most of a CRM moves. Contacts and companies, pipeline stages and deal history, notes, tasks, files and consent records all transfer. Conversations usually come across as a readable archive rather than live threads. Automations, templates, user roles and dashboards get rebuilt rather than copied. And a decent slice of the old data should be left behind on purpose. The real work is deciding the cut-off date and what earns a place in the new system.
What moves, what gets rebuilt, what stays behind
People picture a migration as one big file going from A to B. In practice there are three piles, and knowing which pile each thing sits in saves you most of the arguments later.
| What you have | What happens to it |
|---|---|
| Contacts and companies | Moves cleanly, as long as you agree on the unique field (usually email, sometimes phone) |
| Deals and pipeline stages | Moves, but stage names almost always get rewritten to match how you actually sell now |
| Notes, tasks and activity history | Moves as read-only records attached to the contact |
| Conversations (SMS, email, chat) | Exported as an archive you can search, not as live threads that keep replying |
| Call recordings | The audio files move, but the links inside the old platform break, so they need re-attaching |
| Documents and contracts | Move as files, then get re-linked to the right contact or deal |
| Appointments | Future bookings move, past ones become history |
| Tags and custom fields | Need mapping one by one, and the list usually ends up about half the size |
| Consent and marketing preferences | Must move, and should be treated as the most important field in the whole export |
| Automations and workflows | Rebuilt. Nothing copies across platforms |
| Email and SMS templates | The text copies, the sending logic gets rebuilt |
| Users, roles and permissions | Rebuilt, and this is a good moment to tighten them |
| Dashboards and reports | Rebuilt on the new data model |
| Phone numbers | Ported separately through the carrier, on its own timeline |
The two rows people underestimate are conversations and consent.
Conversations
An old thread is a record of what was said, not a live channel. Once you move, replies land in the new system. So the sensible answer is to import the message history as searchable text on the contact record, keep the old inbox readable for a set period, and send a short note to anyone with an open conversation telling them where to reply.
Consent and marketing preferences
If someone unsubscribed in the old system and that field does not carry across, you will email them again. If you run automated marketing calls, ICO guidance on PECR says you need the person's specific prior consent, and general marketing consent is not enough. That means the consent field is not a nice-to-have column. Check it before anything else, and check it again after import.
How to pick the cut-off date
You need two dates, not one.
The data cut-off is how far back you pull records from. Our rule of thumb: bring every customer you have ever had, every open deal no matter how old, and every other contact touched in the last twenty four months. Anything older than that which never became a customer and never replied is dead weight. Export it to a file, store it somewhere safe, and leave it out of the live system.
The freeze point is the moment the old system stops being the source of truth. Pick a quiet day, usually a Friday afternoon or a bank holiday weekend. Everyone keeps working in the old system right up to that moment, you take the final export, you import, and from Monday morning everything new goes in the new system. Running both for a fortnight sounds safe and is the fastest way to end up with two half-true databases.
What we did in our own migration
We moved our own CRM out of GoHighLevel into a system we built, and the owner confirmed it complete on 2 October 2026. Before that, on 26 September 2026, the owner deliberately reset the CRM. That reset was the point of the exercise. We did not want a clean copy of a messy database, we wanted a deliberate decision about what came with us.
One rule came out of it that we now apply everywhere. The import counts from a migration describe what that migration carried across on the day. They are not an inventory of what is in the system now. The moment you treat them as current stock, somebody looks at a number, decides records are missing, and reimports the old file. Those records must not be reimported. Write that down in the handover notes, because the person who gets tempted in six months is rarely the person who ran the migration.
If you are specifically coming off a rented platform, there is more detail in our guide on how to move off GoHighLevel to a CRM system you own.
Where the data lives afterwards
This matters more than the import itself. We build in your own accounts. Your hosting, your database, your domain, your email and messaging providers. You own the code and you own the data.
Running costs such as hosting, software, phone minutes and AI usage are paid directly to the providers from your accounts. We never sit in the middle of your bills. The practical effect is simple: if you stop working with us, nothing switches off, nobody holds your database hostage, and you can hand it to another developer with the logins you already have. That is the same argument we make about owning the code and accounts when you hire a developer.
A checklist before you press import
- Export everything from the old platform first, including conversations and files, and store a copy outside both systems.
- Agree the unique field that decides whether two records are the same person.
- Write the field mapping on one page. Old field name, new field name, what to do with anything that does not fit.
- Decide your data cut-off and get the owner to sign it off, not just the ops team.
- Deduplicate before import, not after. Merging in a live system creates orphan notes.
- Run a test import of about two hundred records and check fifteen of them by hand, picking your messiest accounts on purpose.
- Check consent and unsubscribe flags on that sample before anything else.
- Rebuild automations switched off, then turn them on one at a time over the first week.
- Set the freeze point and tell the whole team the exact hour the old system goes read-only.
- Record the import counts in a handover note, labelled as a record of the migration, not current inventory, with a line saying the file must not be reimported.
When a migration is not the answer
If your current platform does what you need and the only complaint is price, a migration will cost you more than you save in the first year. If your data is in good shape and you just want better reporting, a dashboard on top of what you have is cheaper. And if nobody in the business can say what the pipeline stages mean, fix that first, because a migration will copy the confusion into a new place.
Moving is worth it when you are paying for things you do not use, when the platform limits how you work, or when you want to own the system outright. Our CRM setup and migration page covers the build side, and what moves CRM migration cost up or down covers the money.
Your next step this week
Pull one export from your current CRM and open it in a spreadsheet. Count the custom fields and the tags, then mark the ones a new starter could explain in one sentence. Whatever is left over is what you leave behind.
When you want a second opinion on the plan, book the free 30-minute discovery call. We map how the business runs and where work gets stuck, then build a working demo from that call and show it on a second call of about an hour, and then you get the written scope and price. We do not promise a delivery date before a scope is signed, because until the field mapping is done, nobody honestly knows.
