Migration
CRM migration services for small business teams
Changing CRM is really two projects: moving the records, and rebuilding the automation that was running on top of them. The second one is where the surprises live, which is why this work gets scoped one platform pair at a time instead of sold as a data transfer.
Start here
Which move are you actually making?
Start from the pair, not the product. A move between two relational CRMs is mostly a field-mapping problem. A move from a relational CRM to a contact-centric one is a modelling problem, because records that used to be separate objects have to collapse into one. Each pair below has its own page.
| The move | What makes it difficult | Where the detail lives |
|---|---|---|
| Salesforce to HubSpot | Both are relational, but leads, record types, formula fields and validation rules have no HubSpot slot, so business logic is re-expressed rather than copied | Salesforce to HubSpot migration |
| Salesforce to Pipedrive | A downsizing move: custom objects, record types, validation rules and Apex have no destination at all in a fixed record model, so each one is re-homed or retired before the export | Salesforce to Pipedrive migration |
| Salesforce to GoHighLevel | The heaviest flattening of the lot: the lead table and the account record both disappear onto a single contact, custom objects and roll-ups have no graph to land in, and Flows, Process Builder and Apex are rebuilt as contact-scoped workflows or retired | Salesforce to GoHighLevel migration |
| Microsoft Dynamics to HubSpot | A mid-market exit from the Microsoft stack: business process flows span tables a HubSpot pipeline cannot, calculated columns and field-level security have no destination, and Outlook sync, SharePoint documents and Power BI reporting all have to be replaced or knowingly dropped | Microsoft Dynamics to HubSpot migration |
| Zoho CRM to HubSpot | Custom modules, Deluge scripts and Blueprint stages are rebuilt as HubSpot objects, properties and workflows, and the rest of Zoho One has to be decided on too | Zoho CRM to HubSpot migration |
| Copper CRM to HubSpot | A Google Workspace-native source: Related Records link almost anything to anything without saying why, so an undefined graph has to become typed associations, and the Gmail side panel the team worked in all day is replaced rather than carried over | Copper CRM to HubSpot migration |
| HubSpot to GoHighLevel | Companies and deals flatten onto a single contact, and association labels such as decision maker have nowhere obvious to land | HubSpot to GoHighLevel migration |
| GoHighLevel to HubSpot | The same crossing un-flattened: one contact record has to become companies, deals and contacts again, tags stop being logic and become typed properties, and contact-scoped workflows are rebuilt as enrolment-based ones | GoHighLevel to HubSpot migration |
| ActiveCampaign to GoHighLevel | Tags carry the account's logic and automations live in a separate builder that does not export, so each tag is rebuilt with the workflow that watched it, per-list consent collapses to per-channel flags, and the new sending domain has to be warmed up | ActiveCampaign to GoHighLevel migration |
| ActiveCampaign to HubSpot | HubSpot bills on marketing contacts, so every contact is classified as marketing, non-marketing or left behind before import; lists and tags become properties, and automations that do not export are rebuilt as workflows | ActiveCampaign to HubSpot migration |
| Keap to GoHighLevel | The logic sits on a Campaign Builder canvas that does not export, tags are the account's state, and underneath it all sit order forms, subscriptions and a referral partner ledger with no destination record | Keap to GoHighLevel migration |
| Keap to HubSpot | Tags hold the state and a campaign canvas holds the logic, and HubSpot has neither: every tag is classified into a typed property or a list, every campaign goal is named as a workflow trigger, and every contact is sorted into marketing or not before import | Keap to HubSpot migration |
| Asana to monday.com | Not a CRM at all: work management, where multi-homed tasks have to pick one owning board, subtasks stop after one level, and the shared custom field library becomes a column on every board | Asana to monday.com migration |
| Zendesk to Intercom | Not a CRM either: a help desk, where tickets become conversations, six ticket statuses collapse into three, and four separate automation features are rebuilt inside one workflow builder that an AI agent then answers on top of | Zendesk to Intercom migration |
| Zendesk to HubSpot | A case system folding into a CRM: six ticket statuses become stages you have to invent, four separate automation features land on one enrolment engine, and side conversations and light agents have no destination at all | Zendesk to HubSpot migration |
| Freshdesk to HubSpot | A support desk the company has outgrown: four ticket statuses become a pipeline you have to invent without over-building it, three automation rule types land on one enrolment engine, and time tracking and ticket splitting have no destination at all | Freshdesk to HubSpot migration |
| Intercom to HubSpot | A help desk folding into a CRM: conversations become tickets in a pipeline you design, transcripts land on the timeline rather than in the inbox, and every workflow that fired on a conversation event is rebuilt as one that enrols a record | Intercom to HubSpot migration |
| Insightly to HubSpot | The source runs delivery as well as sales: projects, milestones and activity sets are first-class records with no HubSpot object to receive them, so the post-sale half of the business needs a destination chosen before anything is exported | Insightly to HubSpot migration |
| Pipedrive to HubSpot | There is no custom object to inherit, so whatever the business tracks has been improvised as deal fields, a spare pipeline or a compound custom field HubSpot cannot hold | Pipedrive to HubSpot migration |
| HubSpot to Pipedrive | A suite shrinks to a pipeline: marketing emails, landing pages, sequences, tickets and custom objects have no slot, and many-to-many associations collapse to one organisation per person | HubSpot to Pipedrive migration |
| HubSpot to monday CRM | The destination has no fixed schema: every object becomes a board you design, associations become connect-boards links written in a second pass, and workflows become recipes that spend a monthly action allowance | HubSpot to monday CRM migration |
| Pipedrive to monday CRM | A fixed pipeline becomes boards you design: deals, people and organisations each get a board, their links are written as connect-boards columns, and automations are rebuilt as recipes | Pipedrive to monday CRM migration |
| Make.com to n8n | The automation layer rather than the CRM: every scenario is rebuilt in a different execution model, with error paths that actually exist | Make.com to n8n migration |
| Zapier to n8n | Linear Zaps become branching workflows, which is a rewrite rather than an import, and the retry behaviour changes with it | Zapier to n8n migration |
| Zapier to Make.com | Also a rewrite, but the destination is still hosted no-code: Paths become routers, Filter and Formatter steps stop being steps, and the meter changes from tasks to operations | Zapier to Make.com migration |
Leaving something heavy for HubSpot. This is the most common direction, and the easiest technically, because both sides are relational. The judgement calls are about logic that has no destination — a Salesforce record type, a Zoho Blueprint state — and those are settled by a person before any row moves. Heavy does not have to mean HubSpot, though: a team leaving Salesforce for the licence and admin saving rather than for a second suite usually wants a plain pipeline, and a Salesforce to Pipedrive migration is a harder mapping problem for exactly that reason — there are no custom objects on the far side to inherit the ones you are leaving. A Salesforce to GoHighLevel migration pushes that same logic to its limit: the account record goes too, so every account-level field is denormalised onto the contacts that belonged to it and somebody has to own keeping them in step. Coming from a lighter source inverts the question: a Pipedrive to HubSpot migration spends its judgement on what the deal fields and spare pipelines were standing in for, because Pipedrive never let those things be objects in the first place. When the source is Dynamics the motive is usually different again — a mid-market team leaving the Microsoft stack over seat cost and the administrator it takes to change a choice column — and a Microsoft Dynamics to HubSpot migration spends most of its effort on what the bundle was quietly doing: Outlook sync, SharePoint documents and Power BI reports that no longer have an environment to read. A Copper CRM to HubSpot migration asks the same question from the other direction: Copper let the team relate any record to any other without naming the relationship, so the judgement goes on deciding what each of those links meant before it can become a typed association. An Insightly to HubSpot migration is lighter still on the sales side and heavier everywhere else, because Insightly also runs the work after the sale: projects, milestones and activity sets are real records with nothing on the HubSpot side to receive them, so the first decision is where the delivery half of the business is going to live at all. Coming from an all-in-one is the hardest version of that question: a GoHighLevel to HubSpot migration has to un-flatten a single contact record back into companies, deals and contacts, and deciding which of those a tag was really describing is the whole project.
Leaving HubSpot for an all-in-one. Harder, because the data model changes shape. A deal associated with four contacts has to nominate one primary, and the other three become tags, fields, or nothing. That decision is the project, and the HubSpot to GoHighLevel migration page walks through it object by object. Leaving a marketing automation tool for the same destination is a different shape of problem: the ActiveCampaign to GoHighLevel migration page covers tags that only meant something because an automation was watching them, list consent that has to become channel consent, and a sending domain that starts with no reputation. Coming from Keap or Infusionsoft is different again, because the commerce objects come with it: the Keap to GoHighLevel migration page covers goals and sequences, contacts stranded mid-sequence, and what happens to order forms, subscriptions and referral partners. Leaving HubSpot for a plain sales pipeline is a different collapse again — what has no slot in Pipedrive is decided before the export, and the HubSpot to Pipedrive migration page leads with exactly that list. Leaving HubSpot for a set of boards inverts it once more — nothing lacks a slot, because the slots are yours to design — and the HubSpot to monday CRM migration page covers the board design, the two-pass load and the recipe rebuild.
Moving the automation layer instead. Sometimes the CRM is fine and the connective tissue around it is the problem. That is a different project with the same discipline — covered on the Zapier to n8n and Make.com to n8n pages, on the Zapier to Make.com page for teams who want to stay no-code, and in general terms under workflow automation.
Moving the mailing list instead. An email service provider is not a CRM, and the crossing has a different centre of gravity: duplicate people spread across separate audiences collapsing into one profile, per-audience consent becoming per-person suppression, and a sending domain that has to earn its reputation from nothing. The Mailchimp to Klaviyo migration page covers that port end to end — what happens to merge fields, segments, templates and journeys, and which half of your history actually travels.
Moving the work, not the customers. Some of these projects are not CRM moves at all. Taking projects, tasks, subtasks and dependencies out of a work-management tool has its own mapping problem, and the Asana to monday.com migration page covers it: which board owns a task that lived in three projects, what happens below the first level of subtasks, and how Rules become recipes on an action allowance. The support desk is the same kind of exception. Tickets, macros and a help centre are not customer records, and the Zendesk to Intercom migration page covers what makes that crossing its own project: a six-state ticket model landing in a three-state one, and an AI agent that will answer customers from whichever articles you decide to carry. The Intercom to HubSpot migration page covers the case where the help desk folds into the CRM instead — three conversation states expanding into a ticket pipeline you design, and a transcript that lands on a timeline rather than in an inbox. The Zendesk to HubSpot migration page covers that same consolidation from the heavier end, where six ticket statuses, four separate automation features and a Guide library all have to land somewhere inside Service Hub. Where the desk was right-sized for a smaller company and the company grew past it, the Freshdesk to HubSpot migration page covers the lighter version of the same crossing — four statuses, three automation rule types, and the discipline of not over-building the pipeline once nothing constrains it.
Method
What every CRM migration has in common
The pair decides the mapping; the order of work is the same either way. Records are counted before and after, the destination is built before anything is loaded, and nothing goes live in one move — cutover happens one pipeline at a time so a mistake costs a pipeline, not a quarter.
A field map before any export
Objects, properties, pipelines and automations listed on one page, each with a named destination. Anything with no destination is decided now rather than discovered mid-import.
Scaffold the destination first
Users, pipelines, stages, custom fields and every dropdown option created up front. Import into a field that does not exist yet and the value is dropped silently, with no error to catch.
Sample, reconcile, then cut over
A few hundred records first, counted in and counted out. Deduplication rules differ between platforms, and this is where unintended merges surface while they are still cheap to undo.
Carry the old record ID across
The cheapest insurance in any migration is a dedicated field on every destination record holding its identifier from the old system. It makes reconciliation arithmetic instead of guesswork, it is what any surviving integration keys on afterwards, and it costs one custom field. Platform import limits and behaviour are published — HubSpot documents its CRM imports API (opens in new window), and the equivalent exists on every platform on this page — so the constraints are knowable before the project starts, not during it.
Consent state is the one mapping that cannot be wrong
Opt-outs are data, and they are the data most likely to be lost in a move, because every platform records them differently: per-topic subscriptions in one, per-channel do-not-contact flags in another. An unsubscribe that fails to cross means the first send from the new system reaches people who already said no. Suppression state is reconciled as its own step with its own count, against the baseline in the FTC's CAN-SPAM compliance guide (opens in new window), and nothing sends until those numbers agree.
The honest part
What does not come across, whichever system you are leaving
Field values, open deals, notes and files move. Per-property change history, send-level email statistics and threaded conversation timelines generally do not, because they belong to the system that recorded them. Automations are never converted — they are rebuilt. A vendor promising otherwise has not read your account.
Because some history stays behind, the old system stays live and read-only for a lookback period after cutover. That is a deliberate decision made during scoping, not a discovery made in month two, and it is the reason each pair page carries its own explicit list of what moves, what is rebuilt, and what is left where it is.
The other thing that quietly stays behind is everything still pointing at the old system: embedded forms, meeting links in email signatures, the tracking script, the chat widget, and any integration still writing records. Miss one and the migration never actually finishes — new contacts keep arriving in the platform you stopped paying attention to. Inventorying those is part of cutover, not an afterthought.
Working together
How the work is scoped, priced and handed over
The first conversation is free and under an hour. After it you get a stage list — field map, scaffold, sample load, full load, rebuild, cutover — with a fixed price per stage, agreed before that stage starts. You can stop after any stage, and a field map you paid for is yours to hand to somebody else. How engagements work sets out the stages in detail.
You own the result outright: records in your own accounts, automations documented against the trigger that starts them, a field map showing where every property went, and a written note of what was deliberately left behind. If your own team would rather run the import, we build the map and the scaffold and stay on as backup.
If you are staying on the CRM you already have
Plenty of enquiries that start as a migration turn out to be a configuration problem instead, and the honest answer is sometimes that you should stay where you are. For that work the tool-level pages are the right read: HubSpot automation consulting for portals staying on HubSpot, GoHighLevel automation consulting for sub-accounts, snapshots and sending rails, and Pipedrive automation consulting for stage design and API work, and Zoho CRM automation consulting for orgs where workflow rules, Blueprint and Deluge have accumulated past the point anyone can explain them. If the problem is the pipeline filling rather than the platform holding it, sales and marketing automation covers capture, routing and follow-up across whichever CRM you keep. Grant-funded organisations weighing a move off a donor database that exposes no usable interface should start with AI automation for nonprofits, which sets out what each integration route actually supports before a migration is worth considering.
Questions
Questions asked before committing to a move
Which CRM should a small team actually move to?
It depends on what is breaking today. Teams leaving a heavy enterprise CRM usually land on HubSpot. Teams that want the mailbox, texting, funnels and pipeline inside one subscription usually land on GoHighLevel. Teams that want a plain sales pipeline and nothing else usually land on Pipedrive. If staying put is the better answer, you will hear that on the call.
Can you move a pair that has no page here?
Yes. The pages above cover the crossings we are asked about most often, not the limit of what we do. The method does not change with the pair: map the schema, scaffold the destination, load a sample, reconcile the counts, then cut over one pipeline at a time. An unlisted pair is scoped on the call like any other.
Will our existing automations still work after the move?
Not on their own. There is no converter between CRM automation engines, and one would be misleading if it existed, because enrolment triggers and re-entry rules differ per platform. Every automation worth keeping is read and rebuilt against the destination's triggers, which is also when the ones nobody has needed for a year get retired.
Timing
How long does a CRM migration take?
A small CRM migration takes days; a complex one takes weeks. Structure decides which, not record count: how many objects and custom fields need mapping, how many pipelines and automations must be rebuilt, how much messy data needs cleaning first, and how many integrations must be re-pointed. You get a stage-by-stage estimate before the first stage starts.
| Factor | Quick (days) | Complex (weeks) |
|---|---|---|
| Data objects to move | Contacts, companies and deals, each with an obvious counterpart in the destination | Custom objects, or records that change shape on the way across, such as companies and deals flattening onto a single contact |
| Custom fields and pipelines | One pipeline and a short field list where every field has a named destination | Several pipelines and long field lists, including fields with no destination slot that need a decision before the export |
| Automations to rebuild | A handful of workflows with simple triggers | Dozens of automations, each read and rebuilt against the destination's own triggers, because none of them convert |
| Data quality | Few duplicates and consistent values that load as they are | Duplicates, inconsistent values and free text where a dropdown belongs, all cleaned before load so the destination's deduplication rules do not merge the wrong records |
| Integrations to re-point | A website form and a meeting link | Embedded forms, tracking scripts, chat widgets and several integrations still writing records into the old system |
| User training | A small team whose daily routine barely changes | A larger team whose daily routine changes with the platform, such as losing an inbox side panel they worked in all day |
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.