Migration
Zoho CRM to HubSpot migration service
Zoho is rarely replaced because it stopped working. It is replaced because the suite around it sprawled and nobody can say where a customer record really lives any more. The rows are the easy part — custom modules, subforms, Deluge functions and Blueprint states are the ones HubSpot has no direct slot for.
The mechanics
The Zoho half of this move is the half that needs judgement
Both platforms hold companies, people and deals as real records, so the standard modules cross without drama. What does not cross is everything an admin added on top over the years: a module invented for a process nobody else has, a subform holding rows inside a record, a script that quietly fixes data on save, and a Blueprint that has been enforcing the sales process for so long that nobody remembers what it enforces.
Custom modules are the first decision, and part of it is commercial. Zoho lets any administrator create a module, so a long-running org usually has several — installations, properties, policies, matters, whatever the business actually sells. HubSpot's equivalent is a custom object, and custom objects belong to its Enterprise tier. If that is not the subscription you are buying, each module has to land somewhere real instead: as a property set on an existing object, as a second deal pipeline, or as associated company and contact records. Every one of those choices changes the export and the reporting, which is why it is settled before the first extract rather than during the load.
Subforms have nowhere obvious to go. A Zoho subform stores repeating rows inside one parent record — assets on an account, attendees on an event, items on a request. HubSpot has line items on a deal and associations between records, and nothing that nests a table inside a record. So each subform resolves into one of three shapes: line items when the rows are products, associated records when the rows are real entities with a life of their own, or a flattened summary property when the rows are only ever read by a human. Picking the wrong one is recoverable; not picking at all means the rows are simply left in the export.
Deluge is where the effort actually sits. Deluge is Zoho's scripting language, and in a mature org it turns up in more places than anyone expects: custom functions on workflow rules, buttons, scheduled jobs and Blueprint transitions. HubSpot workflows are a configured list of actions — enrol, set a property, create a task, change an association, send a notification — so anything genuinely procedural has to go somewhere else. Some becomes a custom code action inside HubSpot, some becomes a job in an automation platform you own outright, which is the territory of workflow automation proper, and a fair share turns out to be patching a schema problem that the rebuild removes anyway. Reading the functions is unavoidable. There is no converter, and a vendor promising one is selling a data transfer.
Matching, and the ID that makes reconciliation arithmetic. HubSpot deduplicates contacts on email address and companies on domain. Zoho enforces neither, so an export carrying two contacts on one address — or a block of records with no address at all — is exactly where an import merges people you meant to keep apart. The defence is cheap: carry the Zoho record ID into a dedicated HubSpot property on every record before anything loads through HubSpot's CRM imports API (opens in new window). Counts then reconcile by joining on a key instead of by eye, and any integration you keep has something stable to key on afterwards.
| Zoho CRM artefact | How Zoho models it | Where it lands in HubSpot | The decision it forces |
|---|---|---|---|
| Custom modules | A module any admin can create, with its own fields, layouts and relationships | A custom object on Enterprise; otherwise properties, a second pipeline, or associated records | Which of those destinations each module gets — decided by subscription tier and by how the records are actually used |
| Subforms | Repeating rows stored inside a single parent record | Line items, associated records, or a flattened summary property | Whether the rows are products, real entities, or reference text a person only reads |
| Leads module | Its own module, converted once into an account, contact and deal | A contact carrying a lifecycle stage — HubSpot has no separate lead table | Which lead statuses become which lifecycle stage, and how already-converted leads stay out of the import |
| Custom fields and picklists | Per-layout fields, with values that can differ between layouts of the same module | Properties on the object, with one option set per property | How layout-specific option lists are merged without losing the distinction the layouts were carrying |
| Multiple layouts on one module | Different fields and rules presented on the same module | No equivalent — one property set applies per object | Whether each layout becomes a property, a separate pipeline, or conditional logic on a form |
| Blueprint | Enforced states and transitions, with fields captured during a transition and limits on who may move it | Deal stages, stage requirements, permissions and workflow tasks | Which enforcement genuinely has to be reproduced, given that HubSpot flags where Zoho blocks |
| Workflow rules and Deluge functions | Rule triggers calling scripted custom functions, buttons and scheduled jobs | Workflows, custom code actions, or jobs in an automation platform outside the CRM | Which logic belongs in the CRM at all, and which was only ever compensating for the old schema |
| Formula and rollup fields | Values computed on read, including across related records | Calculation properties, workflow-maintained properties, or static values | Which derived values must stay live and which can be frozen at their cutover reading |
| Tags | Free-form labels attached to records across modules | Multi-checkbox properties or lists — there is no tag primitive | Which tags were segmentation worth keeping and which were one person's shorthand |
| Quotes, sales orders and invoices | CRM modules, often kept in step with Zoho Books or Zoho Invoice | Quotes and line items in HubSpot, or left with the finance system and integrated | Whether billing stays in the Zoho suite after the CRM leaves, and which system then owns the number |
| Roles, profiles and territories | Hierarchical record sharing plus territory-based assignment | Teams and permission sets, with a flatter visibility model | Which restrictions exist for a real reason, and which are habit inherited from the org chart |
| Email Opt Out and Campaigns lists | A flag on the CRM record, plus unsubscribe lists held separately in Zoho Campaigns | Subscription types, plus the marketing versus non-marketing contact designation | Which imported contacts are marketable at all — a decision with billing consequences in HubSpot |
Consent lives in two places in Zoho, and both have to arrive. The opt-out flag sits on the CRM record; the unsubscribe list usually sits in Zoho Campaigns, a different application with its own database. Export both, merge them, load the result as HubSpot subscription state, and reconcile the counts against the obligations set out in the FTC's CAN-SPAM compliance guide (opens in new window) before any sending is enabled. Nothing goes out until those numbers agree.
Sequence
How the work is ordered when the source is Zoho
Inventory the suite, not just the CRM
Modules, subforms, layouts, functions and Blueprints on one page — and beside them every other Zoho app and Flow connection that writes into the CRM. Those connections are what keeps an abandoned org alive after cutover.
Give every artefact a destination first
Each custom module, subform and derived field gets a named landing spot before anything is exported. Import into a property that does not exist yet and the value is dropped without an error.
Sample load, then reconcile on the ID
A few hundred records first, joined back on the Zoho record ID. Deduplication behaves differently on each side, so this is where unintended merges surface while they are still cheap to undo.
Blueprint states, deal stages, and what enforcement means afterwards
A Blueprint is a process engine rather than a pipeline, and that difference is the one most likely to surprise a team in its first week on HubSpot. Zoho can refuse a transition, demand fields during it, and restrict who is allowed to make it. HubSpot has stages, properties that can be required before a deal advances, and workflows that can create a task or set a flag. So a Blueprint decomposes rather than transfers: states to stages, transition fields to stage requirements, actor rules to permissions plus a review step, and the residue to a workflow that raises an exception after the fact. Where a business genuinely cannot run on flagging instead of blocking, that is worth knowing while the engagement is being scoped — not on cutover day.
What happens to the rest of Zoho One
Most teams leaving Zoho CRM are not leaving the suite. Books, Desk, Campaigns, Forms, Sign and Analytics can all stay, and often should for a while, connected to HubSpot through their APIs or through an automation layer that both sides can see. What cannot be deferred is anything still writing into the old CRM: Zoho Flow connections, embedded web forms, chat, and any Campaigns sync keep creating records in an org nobody is watching. If that integration layer is being rebuilt at the same time, the Zapier to n8n migration page covers that half of the job — retries, error handling and ownership of the connections rather than objects and record history.
Cutover, reconciliation and disposing of the export
Cutover runs per pipeline rather than all at once. Record counts are compared in both directions, opt-out counts are compared separately, and a delta load picks up everything created during the freeze window. The Zoho org stays live and read-only for a lookback period, because the record timeline and audit trail do not migrate and are still worth being able to open. One step is easy to skip: the export itself is a complete copy of your customer database, sitting in a folder, on a laptop, probably in a shared drive as well. Destroying those working files at the end of the project — deliberately, everywhere they were copied, along the lines of NIST's media sanitization guidelines (opens in new window) — is part of the work, not an afterthought.
Where this sits next to the rest of the work
If you are coming from Salesforce rather than Zoho, the destination is the same but almost nothing else is: record types, formula fields, Apex and a lead object that converts one way. That crossing has its own mapping problem, and our Salesforce to HubSpot migration page covers it on its own terms. If the source is Copper rather than Zoho, there is no artefact layer to re-home at all — the difficulty moves to the Related Records graph and the Gmail side panel the team lives in, which the Copper CRM to HubSpot migration page takes on. If the destination is GoHighLevel rather than HubSpot, the same Zoho artefacts land on a contact-centric platform with no company record to hold an account, and our Zoho CRM to GoHighLevel migration page maps that flattening. If all the team really uses is the deal pipeline, our Zoho to Pipedrive migration page covers the leaner destination. Moving the other way — off HubSpot and toward an agency-style platform — is the HubSpot to GoHighLevel migration page. And if the conclusion of all this is that the org is worth keeping and the real problem is how it was configured, our Zoho CRM automation consulting page covers the opposite decision to this one: workflow rules, Blueprint and Deluge repaired in place, with no crossing at all. Once you have landed and the question turns to how the portal should be run — workflows, lifecycle stages, property hygiene — our HubSpot automation consulting page covers that build, the sales and marketing automation page covers the same ground as an outcome, and how engagements work explains how a scope gets agreed before any of it starts.
The honest part
What does not survive the crossing
More moves than most teams expect, because the standard modules line up well on both sides. Some of it does not move at all, and a firm that says otherwise has not opened your org. Knowing which is which before you commit turns the lookback period into a decision rather than a discovery.
| What | Treatment | Why |
|---|---|---|
| Standard module field values | Moves | Accounts, contacts and deals load cleanly once the destination properties and every picklist option exist first |
| Open deals and stage position | Moves | Stage, amount, closing date and owner land on a deal once pipelines and users have been created |
| Calls, tasks, events and notes | Moves deliberately | They load as engagements on the matching record, which is worth doing for open business and rarely worth doing for all history |
| Attachments and linked files | Moves deliberately | Files transfer and re-associate, but volume drives the effort, so this is scoped rather than assumed |
| Subform rows | Rebuilt or flattened | Nothing in HubSpot nests a table inside a record, so each subform becomes line items, associated records, or summary text |
| Blueprints, workflow rules and Deluge | Rebuilt | A different execution model entirely: configured actions instead of scripts, and flagging instead of blocking |
| Record timeline and audit trail | Stays behind | The change history belongs to the org that recorded it, which is the argument for keeping the old org readable rather than importing everything |
| Zoho Analytics reports and dashboards | Rebuilt | Reports are rebuilt against the new property names, and anything measuring duration or change rather than current state is exported and archived first |
| Flow connections, web forms and chat | Replaced | Anything still writing into the old org keeps creating records there after cutover, and nobody notices for weeks |
You own the result outright: records in your own portal, workflows documented against the trigger that starts them, a field map showing where every Zoho field went, a written note of what each custom module and subform became, and an equally written note of what was left behind on purpose. If your own team would rather run the load, we will build the artefact map and the scaffold and stay on as backup — and if the honest answer on the call is that Zoho still fits you better than HubSpot would, that is what you will hear.
Questions
What Zoho teams ask before committing
What happens to our Zoho custom modules in HubSpot?
They become custom objects if your HubSpot subscription includes them, and something else if it does not, because custom objects sit on the Enterprise tier. The usual alternatives are a property set on an existing object, a second deal pipeline, or associated company and contact records. That choice changes the export, the field map and the reporting, so it is made before anything is exported rather than discovered halfway through the load.
Do Deluge functions convert into HubSpot workflows automatically?
No. Deluge is a scripting language and a HubSpot workflow is a configured list of actions, so each function is read, its real purpose identified, and rebuilt as workflow actions, as a custom code action where the subscription allows one, or as a job in an automation platform outside the CRM. Functions that only ever patched a gap in the old schema are retired instead of rebuilt, and that is the cheapest work in the project.
Does a Zoho Blueprint survive the move?
Not as a single object. Blueprint states become deal stages, fields captured during a transition become stage requirements, and actor restrictions become a permission plus a review task. What HubSpot will not do is refuse a transition the way a Blueprint does, so any step that depended on hard enforcement becomes a workflow that flags the exception, or it is dropped deliberately and written down.
We run Zoho Books, Desk and Campaigns as well. Do those have to move too?
No, and moving the whole suite at once is rarely the right call. The CRM can leave while the other apps stay, connected to HubSpot through their APIs or through an automation layer. What cannot be left alone is anything still writing into Zoho CRM: Flow connections, web forms, chat and Campaigns syncs keep creating records in the org you stopped watching unless they are repointed as part of the cutover.
How do email opt-outs carry across when the list lives in Zoho Campaigns?
As their own reconciliation, not as one more column in the contact import. Zoho keeps an opt-out flag on the CRM record while the unsubscribe list sits inside Campaigns, so both are exported, merged, and loaded as HubSpot subscription state before any sending is switched on. The counts have to agree first, because the first campaign from a new portal is exactly where a missed unsubscribe turns into a complaint.
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.
Not sure which migration is right? See the CRM migration services overview.