--- title: "Zoho CRM to HubSpot Migration: The Complete Technical Guide" slug: zoho-crm-to-hubspot-migration-the-complete-technical-guide date: 2026-09-25 author: Nachi Raman categories: [Zoho CRM, HubSpot, Migration Guide] excerpt: "Technical guide to migrating Zoho CRM to HubSpot: module-to-object mapping, API rate limits, custom module constraints, associations, and workflow rewrites." tldr: "Zoho CRM to HubSpot is a data model redesign: Leads and Contacts merge, custom modules hit a 10-object cap, layouts have no equivalent, and every workflow must be rebuilt." canonical: https://clonepartner.com/blog/zoho-crm-to-hubspot-migration-the-complete-technical-guide --- # Zoho CRM to HubSpot Migration: The Complete Technical Guide > [!NOTE] > **TL;DR — Zoho CRM to HubSpot Migration** > > A Zoho CRM to HubSpot migration is a data model translation project, not a CSV export/import job. Zoho's modular architecture — with separate Leads and Contacts, up to 200 custom modules, multiple layouts per module, and Deluge-scripted automation — does not map cleanly onto HubSpot's flatter, contact-centric object model. Standard modules translate with moderate effort, but custom modules (HubSpot caps custom objects at 10 on Enterprise), layouts, subforms, and workflows require redesign. Start with a full metadata capture from Zoho, not the export button. Expect 2–4 weeks for a clean instance under 100K records, and 4–8 weeks when custom modules, attachments, and workflow rewrites are in scope. A Zoho CRM to HubSpot migration is a structural redesign. Teams that underestimate the gap between Zoho's database-like modularity and HubSpot's opinionated, inbound-first architecture run into data loss, broken relationships, and orphaned attachments. If you export Zoho CSVs and push them through HubSpot's native import tool, you will lose historical attribution, corrupt relational lookup fields, and orphan attachments. The lowest-risk approach: extract Zoho metadata first, decide what becomes a HubSpot property vs. association vs. custom object, then load records in dependency order and rebuild automation rule by rule. ([zoho.com](https://www.zoho.com/crm/developer/docs/api/v8/module-meta.html?utm_source=openai)) For the architectural differences between these platforms, see [HubSpot vs Zoho CRM Architecture Guide (2026)](https://clonepartner.com/blog/blog/hubspot-vs-zoho-crm-architecture-guide-2026). For a platform-agnostic pre-migration checklist, start with [The Ultimate CRM Data Migration Checklist](https://clonepartner.com/blog/blog/the-ultimate-crm-data-migration-checklist-a-10-point-plan-for-a-zero-loss-transition). For workflow-specific guidance, pair this guide with the [Workflow Preservation Checklist & Conversion Reference](https://clonepartner.com/blog/blog/workflow-preservation-checklist-conversion-reference). ## How Do Zoho CRM Modules Map to HubSpot Objects? **Zoho CRM modules** are distinct database tables — Leads, Contacts, Accounts, Deals, and optionally up to 200 custom modules on Enterprise. **HubSpot objects** are a flatter set — Contacts, Companies, Deals, Tickets, and up to 10 custom objects on Enterprise. The core translations look straightforward until you examine the details. ### Standard module mapping | Zoho CRM Module | HubSpot Object | Key Differences | |---|---|---| | **Leads** | Contacts (lifecycle stage = Lead) | Zoho treats Leads as a separate module with its own fields. HubSpot has no Leads object — all people are Contacts differentiated by a lifecycle stage property. | | **Contacts** | Contacts (lifecycle stage = varies) | Zoho Contacts are post-conversion records. In HubSpot, they merge into the same object as Leads. Deduplication is your responsibility. | | **Accounts** | Companies | Near 1:1. Watch for Zoho's billing/shipping address split vs. HubSpot's single address. | | **Deals** | Deals | Pipeline stages need manual recreation. Zoho supports multiple layouts per deal type — HubSpot uses separate pipelines. | | **Tasks** | Tasks (engagements) | Zoho Tasks are a standalone module. HubSpot Tasks are engagement objects associated to Contacts/Companies/Deals. | | **Cases** | Tickets (Service Hub) | Requires Service Hub. Field sets differ significantly. | | **Campaigns** | Marketing campaigns | Entirely different architecture. Zoho Campaigns are CRM records; HubSpot campaigns are attribution objects without a CRM record model. Not directly importable. | ### The Leads–Contacts merge problem This is the single most common source of data quality issues in a Zoho-to-HubSpot migration. Zoho CRM separates Leads and Contacts into distinct modules — a Lead is a pre-qualification record that gets "converted" into a Contact + Account + Deal. HubSpot has no equivalent separation. Every person is a Contact, differentiated only by the `lifecyclestage` property. When migrating, you must: - **Merge Leads and Contacts into one pool**, setting lifecycle stage to `lead` or `subscriber` for unconverted Leads and `customer` or `opportunity` for converted Contacts. - **Deduplicate before import.** If the same person exists as both a Lead (unconverted) and a Contact (converted from a different Lead), you will create duplicates in HubSpot unless you match on email. - **Preserve the Zoho Record ID** as a custom property in HubSpot (e.g., `zoho_lead_id`, `zoho_contact_id`) for audit trails and post-migration lookups. ### Use external IDs for idempotent imports Create **external ID properties** early so reruns are idempotent and associations do not depend on names, email addresses, or company domains alone. HubSpot's import flow supports custom unique value properties for contacts, companies, deals, tickets, and custom objects — exactly what you need for repeatable cutovers. ([knowledge.hubspot.com](https://knowledge.hubspot.com/import-and-export/import-objects?webview=1&utm_source=openai)) ```text companies -> zoho_account_id contacts -> zoho_contact_id deals -> zoho_deal_id custom obj -> zoho__id ``` ## Why Zoho Layouts and Custom Modules Don't Map Cleanly to HubSpot ### Zoho layouts have no HubSpot equivalent **A Zoho CRM layout** is a set of fields, mandatory rules, and picklist values displayed conditionally within a single module — for example, a "New Business" layout and a "Renewal" layout within the Deals module, each showing different fields. HubSpot has no layout equivalent. Instead, HubSpot uses **conditional property logic** (showing/hiding sidebar sections based on a property value) and **separate pipelines** for distinct deal types. The migration consequence: fields that only appear on one Zoho layout must still be created as properties on the HubSpot Deals object, visible across all pipelines. You cannot scope a property to a single pipeline. HubSpot's Deals object accumulates every field from every Zoho layout, creating a wider, flatter record. You must consolidate all fields from all Zoho layouts into a single master property list in HubSpot, relying on conditional UI features to manage visual clutter. A subtlety worth noting: Zoho's Fields Metadata API does **not** include layout-specific mandatory fields or picklist values. A migration that only exports field metadata will miss part of the source logic. Pull layout metadata alongside field metadata via the Layouts API, then decide which layout differences are real business rules and which are purely UI choices. ([zoho.com](https://www.zoho.com/crm/developer/docs/api/v8/field-meta.html?utm_source=openai)) ### Custom modules hit HubSpot's object ceiling **Zoho CRM Enterprise** supports up to 200 custom modules — purpose-built record types like Properties, Contracts, or Inspections with their own fields, layouts, related lists, and automation. **HubSpot custom objects** are the equivalent, but they require Enterprise tier and are capped at 10 definitions per portal (expandable at $500/month per 10 additional). If your Zoho instance uses 15+ custom modules, you will hit this ceiling. Options: - **Merge** similar Zoho modules into a single HubSpot Custom Object with a "Type" property. - **Demote** minor Zoho modules into custom properties on the Contact, Company, or Deal record. - **Push** highly transactional data (like invoice line items) into HubSpot Custom Events rather than Custom Objects. - **Map** some Zoho modules to HubSpot's native objects (Tickets, Products, Line Items) where they align. - **Keep** some modules in an external system with a sync integration. > [!WARNING] > **Custom objects require HubSpot Enterprise.** Professional and Starter tiers cannot create custom objects. If you are migrating a Zoho instance with custom modules and your target HubSpot portal is on Professional, those modules cannot be replicated as custom objects — they must be flattened into properties on standard objects or handled outside HubSpot entirely. The honest assessment: if your Zoho CRM has more than 8–10 custom modules, this is a data model redesign project, not a migration. ## How Do Zoho Lookups and Related Lists Translate to HubSpot Associations? **Zoho CRM uses lookup fields** to create relationships between modules — a Deal has a lookup to an Account, a Contact has a lookup to an Account, and custom modules can have lookups to any standard or custom module. These lookups power **related lists**, which display child records on a parent record's detail page. HubSpot uses **associations** instead of lookup fields. Associations are bidirectional links between objects, optionally labeled with **association labels** (e.g., "Primary Contact," "Billing Contact"). The v4 Associations API supports typed labels with configurable cardinality. Key differences during migration: - **Zoho's lookup fields are directional** (child points to parent). HubSpot associations are inherently bidirectional — associating Contact A to Company B also associates Company B to Contact A. - **Zoho allows multiple lookups of the same type** on a single record (e.g., a Deal can have separate lookups to a "Billing Account" and a "Shipping Account"). HubSpot handles this with association labels — you associate the Deal to both Companies but label one "Billing" and the other "Shipping." - **Association labels require Professional or Enterprise.** Lower tiers lose the ability to distinguish relationship types. - **Zoho subforms** (embedded child records within a module) have no direct HubSpot equivalent. The closest option is a custom object associated to the parent, but this consumes one of your 10 custom object slots. ### Linking modules: when an association is not enough **Zoho multi-select lookups** create a separate **linking module** — a junction table that sits between two modules. On Enterprise and above, that linking module can hold up to 100 custom fields of its own. ([zoho.com](https://www.zoho.com/crm/developer/docs/api/v8/linking-modules.html)) HubSpot association labels can describe a relationship, but they cannot carry data. If the Zoho linking module has business fields — allocation percent, partner role, territory note, contract flag — you cannot flatten it into a HubSpot association label without losing that data. > [!WARNING] > **Do not map a Zoho linking module straight to a HubSpot label if the linking module contains business fields.** A label names a relationship. A linking module behaves like a junction object with its own columns. If you flatten the latter into the former, you lose data and reporting context. The rule: use HubSpot association labels for semantics-only relationships (billing contact, partner on deal). Use a HubSpot custom object for any Zoho junction that carries its own payload. ### Association creation is always a separate pass You cannot set associations during a HubSpot batch create call. The process is: 1. Create the source record (e.g., Contact) and store the resulting HubSpot ID. 2. Create the target record (e.g., Company) and store the resulting HubSpot ID. 3. Send a `PUT` request to the Associations API linking the two IDs with the correct association type (e.g., `contact_to_company`). Failure to map associations will result in orphaned Deals and Contacts that do not roll up to their Company records, destroying reporting accuracy. ## Zoho CRM API vs. HubSpot API: Rate Limits and Bulk Operations API constraints dictate your migration timeline. Both platforms enforce strict limits, but their execution models differ. ### Zoho CRM API (v8): credit-based model Zoho CRM's API uses a **credit-based system** with a rolling 24-hour window. Each API call costs credits — 1 credit for most reads, up to 10 credits for a batch insert of 100 records, and 500 credits for a Bulk Write job initialization. ([zoho.com](https://www.zoho.com/crm/developer/docs/api/v8/api-limits.html)) - **Enterprise edition**: 50,000 base credits + 1,000 per user license (100 users = 150,000 daily credits) - **Concurrency limit**: 20 simultaneous active requests per org/app on Enterprise - **Bulk Read API**: exports up to 200,000 records per job as a CSV download, does not consume standard API credits - **Bulk Write API**: imports up to 25,000 records per job via compressed CSV upload, asynchronous processing The **Bulk Read API** is your primary extraction tool. It runs asynchronously, returns results as a downloadable CSV, and supports criteria-based filtering. For datasets over 200,000 records, use the `page_token` parameter to paginate across multiple jobs. It is mandatory for any module containing more than ~50,000 records — standard REST extraction will hit concurrency limits and trigger `HTTP 429` errors. ```json // Zoho Bulk Read Job Request { "query": { "module": "Contacts", "fields": ["First_Name", "Last_Name", "Email", "Account_Name"], "page": 1 } } ``` ### HubSpot API: burst + daily cap model HubSpot uses a **burst rate limit** plus a **daily request cap**, both varying by subscription tier: | HubSpot Tier | Burst Limit | Daily Limit | |---|---|---| | Free / Starter | 100 req / 10 seconds | 250,000 / day | | Professional | 190 req / 10 seconds | 625,000 / day | | Enterprise | 190 req / 10 seconds | 1,000,000 / day | HubSpot's **batch endpoints** accept up to 100 records per create/update call. The CRM Search API has a separate, stricter per-second limit. The Associations batch read endpoint caps at 1,000 IDs per request. ```json // HubSpot Batch Create Contacts { "inputs": [ { "properties": { "email": "engineer@example.com", "firstname": "Bruce", "lifecyclestage": "lead" } } // Up to 99 more records ] } ``` Batching reduces API call volume by ~99%, keeping you well below the daily cap even when migrating millions of rows. For high-volume migrations, HubSpot offers an **API Limit Increase add-on** at $500/month that adds 1,000,000 daily requests and raises the burst limit to 250 requests per 10 seconds. You can purchase up to two packs. ### Practical throughput For a migration of 500,000 Contact records: - **Zoho extraction** (Bulk Read): 3 jobs × ~200K records = complete in minutes, no credit cost - **HubSpot loading** (batch create, 100 records/call): 5,000 API calls. At 190 req/10s on Enterprise, that's ~4.5 minutes of pure API time The real bottleneck on the HubSpot side is association creation. Each association requires a separate API call or batch. A dataset with 500K contacts, 100K companies, and 200K deals can easily require 800K+ association calls on top of record creation. > [!TIP] > HubSpot's native Zoho CRM connector is documented as a **data sync** setup, and HubSpot requires the Zoho **Modified By** field on synced objects. It can help during a parallel-run overlap period, but it does not replace historical activity migration, custom-object design, or workflow rewrite work. ([knowledge.hubspot.com](https://knowledge.hubspot.com/integrations/connect-hubspot-and-zoho)) ## How Do You Handle Picklists and Multi-Select Fields? **Picklist fields** (single-select dropdowns) in Zoho map to HubSpot **dropdown select** properties. Multi-select picklists map to HubSpot **multiple checkboxes** properties. The translation is conceptually simple but operationally messy. Pitfalls: - **HubSpot dropdown values must be pre-created** before import. If your Zoho picklist has 47 values and you import data containing a value not defined in HubSpot, the import silently drops that value — the field is left blank with no error. Via the API, HubSpot rejects the batch payload with a `PROPERTY_DOESNT_MATCH_OPTIONS` error. - **Internal values vs. display labels.** Zoho picklist options have both an API name and a display label. HubSpot properties have an `internal value` and a `label`. If these don't match exactly (case sensitivity matters), values won't map. For API writes, always use the internal value, not the display label. Extract Zoho field metadata via `GET /crm/v8/settings/fields` and programmatically map the API names to your HubSpot property definitions before running the ingestion. - **Multi-select separator.** Zoho stores multi-select values with a semicolon delimiter. HubSpot's import tool also expects semicolons for multiple checkboxes, so this aligns for CSV imports. Via API, you pass an array. - **Dependent picklists** in Zoho (where one picklist's values change based on another's selection) have no native HubSpot equivalent. You can approximate this with conditional property logic, but it must be rebuilt manually. - **Layout-specific picklist restrictions.** If Zoho restricts available picklist values per layout, the Fields Metadata API alone won't surface this. Pull layout metadata too. Build a property mapping spreadsheet before writing any migration code. For each Zoho picklist, list every active value, confirm the HubSpot internal value matches, and pre-create all options via the Properties API. ## Owner and Team Mapping **Record ownership** migrates by mapping Zoho CRM users to HubSpot owners. Both platforms tie records to individual users, but the mapping requires exact email-address matching. Steps: 1. **Export the Zoho user list** via the Users API (`/crm/v8/users?type=AllUsers`). Capture `id`, `email`, `full_name`, and `role`. 2. **Export the HubSpot owner list** via `/crm/v3/owners`. Capture `id`, `email`, and `teams`. 3. **Match on email.** Any Zoho user without a corresponding HubSpot owner must be invited to HubSpot first, or their records will import without an owner. 4. **Map Zoho roles/profiles to HubSpot teams.** Zoho uses Roles (hierarchical) and Profiles (permission sets). HubSpot uses Teams (flat or hierarchical on Enterprise). This is a manual mapping — there is no automated translation. > [!TIP] > **Handle deactivated users early.** Zoho retains records owned by deactivated users. If those users won't have HubSpot seats, decide on a fallback owner before migration — either a dummy "Historical User" in HubSpot or an active manager who inherits legacy records. Do not leave this decision for the data load phase. If your Zoho setup relies on territories or multiple owner-like user relationships, treat that as a permissions redesign rather than a straight field copy. HubSpot gives each record one default owner property; additional user references require custom HubSpot user properties. ## Migrating Notes, Attachments, and Emails Activity data is often the largest volume and the most fragile part of a CRM migration. ### Notes **Zoho CRM Notes** are standalone records linked to a parent module record via a related list. In HubSpot, notes are **engagement objects** of type `note`, associated to Contacts, Companies, or Deals. - Extract notes via Zoho's `/crm/v8/Notes` endpoint or from each module's related list. - Create them in HubSpot using the Engagements API (`POST /crm/v3/objects/notes`). - **Preserve the original timestamp** by setting HubSpot's `hs_timestamp` property. If you omit this, every note will show today's date, destroying the historical timeline. ### Attachments **Zoho stores attachments** as binary files accessible via the Attachments API (`/crm/v8/{module}/{record_id}/Attachments`). HubSpot does not have a native "attachments" object the way Zoho does. Files live in the File Manager and are linked through notes or custom properties. Migrating them requires a multi-step pipeline: 1. Download the binary file from Zoho's Attachment API. 2. Upload it to HubSpot's File Manager API (`POST /files/v3/files`), which returns a File ID. 3. Create a HubSpot **Note engagement** that references the file via `hs_attachment_ids`. 4. Associate the Note with the relevant Contact, Company, or Deal. Do not attempt to migrate attachments via CSV. The native import tools cannot handle binary data. Also audit Zoho **file-upload and image-upload fields** — those use a separate field-attachments download flow from the classic Attachments related list. ### Emails **Zoho CRM stores email activity** as records within the Emails related list of each module. Migrating email history to HubSpot means creating **email engagement objects** with the original sender, recipients, subject, body, and timestamp. Practical constraints: - HubSpot email engagements do not render threaded conversations the way Zoho does. Each email becomes a standalone timeline entry. - Zoho email extraction is slow — the list endpoint returns 10 emails per call, and full body retrieval uses a separate View Email endpoint. - If you omit the activity date, HubSpot will stamp the email at import time. - Existing activities cannot be updated via HubSpot's import tool — only created. Consider whether the cost of migrating full email history is worth the fidelity loss in HubSpot's non-threaded display. ## Workflow and Automation Rewrite **Zoho CRM workflows, Blueprints, and custom functions (Deluge scripts) cannot be exported or migrated programmatically.** They must be manually audited, mapped to HubSpot equivalents, and rebuilt. There is no tool that translates a Zoho Blueprint into a HubSpot workflow. The platforms' automation models differ fundamentally: | Concept | Zoho CRM | HubSpot | |---|---|---| | **Trigger-based automation** | Workflow Rules | Workflows | | **Stage-gated processes** | Blueprints | Deal/Ticket pipelines + workflows | | **Custom server-side logic** | Deluge functions | Custom coded actions (Operations Hub) | | **Approval processes** | Approval Rules | Approval workflows (limited) | | **Scheduled actions** | Schedules + custom functions | Scheduled workflows | HubSpot's workflow builder is more visual and easier for non-developers, but less programmable than Zoho's Deluge scripting. Complex Deluge functions that call external APIs, perform conditional data transformations, or interact with other Zoho apps must be reimplemented as HubSpot **custom coded actions** (Node.js or Python) — which require Operations Hub Professional or Enterprise. ([help.zoho.com](https://help.zoho.com/portal/en/kb/crm/automate-business-processes/workflows/articles/configuring-workflow-rules?utm_source=openai)) The recommended approach: 1. **Audit every active Zoho workflow, Blueprint, and custom function.** Document the trigger, conditions, and actions. 2. **Classify each as migrate, redesign, or retire.** Many workflows exist to work around Zoho limitations that HubSpot handles natively (e.g., some field-update automations become unnecessary with HubSpot's calculated properties). 3. **Rebuild in HubSpot only after data migration is complete.** Running workflows during the data load will trigger thousands of unwanted emails, task assignments, and webhook calls. For a structured approach to this audit, see [Workflow Preservation Checklist & Conversion Reference](https://clonepartner.com/blog/blog/workflow-preservation-checklist-conversion-reference). ## Migration Sequence: The Order Matters Load records in dependency order. If you create Deals before Companies exist in HubSpot, you cannot associate them. The correct sequence: 1. **Inventory Zoho metadata.** Pull modules, fields, layouts, related lists, workflows, and functions before exporting any records. This captures layout-specific rules and relationship structures that field metadata alone misses. ([zoho.com](https://www.zoho.com/crm/developer/docs/api/v8/module-meta.html?utm_source=openai)) 2. **Build the HubSpot target schema.** Create all properties, custom objects, pipelines, picklist options, and association definitions before importing data. 3. **Create external ID properties.** Add `zoho_account_id`, `zoho_contact_id`, `zoho_deal_id`, etc. so imports are idempotent. 4. **Load Users/Owners.** Ensure all target owners exist and are active in HubSpot. 5. **Load Companies** (from Zoho Accounts). 6. **Load Contacts** (merged Leads + Contacts, with lifecycle stages set). 7. **Create Contact → Company associations** using stored Zoho lookup IDs. 8. **Load Deals** with pipeline and stage mapping. 9. **Create Deal → Company and Deal → Contact associations.** 10. **Load Custom Objects** — schema first, then records, then associations. 11. **Load Notes, Tasks, Emails, and Attachments** with explicit historical timestamps. 12. **Run a delta sync.** Extract records created or modified in Zoho after the cutoff date, push updates to HubSpot to ensure parity. 13. **Validate.** Compare record counts per object, spot-check 50–100 records for field accuracy, verify association integrity, check picklist value coverage, and confirm owner assignment. 14. **Rebuild workflows** — only after data is validated and stable. > [!NOTE] > **Run a pilot batch first.** Import 500–1,000 records of each type, verify associations, check picklist values, and confirm owner mapping. Catching a field mapping error on 1,000 records is a 10-minute fix. Catching it on 500,000 is a rollback. > [!NOTE] > **A clean validation pass doesn't just compare row counts.** It compares counts by object, counts by stage or status, association counts by object pair, owner coverage, and sampled timelines with attachments. Every Zoho workflow should be marked as rebuilt, intentionally retired, or replaced. ## What About Native Migration Tools and Third-Party Platforms? Zoho has a built-in migration tool for importing *from* HubSpot, but **not the reverse**. HubSpot's native import accepts CSV files and can map columns to properties, but it does not support association creation, engagement imports, or custom object creation in a single pass. ([knowledge.hubspot.com](https://knowledge.hubspot.com/import-and-export/understand-the-import-tool?utm_source=openai)) Third-party tools like Import2, Trujay, and Data2CRM handle basic standard-module migrations (Contacts, Companies, Deals) but typically fall short on: - Custom module → custom object translation - Attachment migration - Note timestamp preservation - Multi-layout field handling - Workflow audit or rebuild For instances with under 10,000 records, no custom modules, and simple pipelines, a CSV export/import approach works. For anything more complex — especially with custom modules, attachments, or email history — API-driven scripted migration is the only reliable path. ## When to Redesign vs. Force a 1:1 Map Redesign when a Zoho construct exists to support a Zoho-specific UI or automation shortcut rather than a real business entity. Split layouts often collapse into one HubSpot object with better property hygiene. A relationship-heavy linking module often becomes a true custom object. Territory-driven visibility becomes a permissions and team model redesign, not a data map. Self-service makes sense when your Zoho CRM has fewer than 10,000 total records, uses only standard modules, has no custom modules, and has workflows simple enough to rebuild in an afternoon. A managed migration pays for itself when: - You have **custom modules** that require HubSpot custom object design - Your record count exceeds **50,000** and API rate limits need orchestration - **Attachments and email history** must transfer with timestamps preserved - **Workflow complexity** includes Blueprints, Deluge functions, or cross-module automation - You need a **zero-downtime cutover** with both systems running in parallel during validation Embracing HubSpot's flatter architecture rather than trying to force Zoho's complex modularity into an ecosystem not designed for it will produce a cleaner, more maintainable system — and a migration that does not haunt you six months later. > Migrating from Zoho CRM to HubSpot and need the data model translation done right? ClonePartner's engineering team will scope your instance, map every module, and deliver a validated migration with rollback capability at every stage. Book a technical scoping call. > > [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click) ## Frequently asked questions ### How long does a Zoho CRM to HubSpot migration take? A standard migration with under 100K records and no custom modules typically takes 2–4 weeks. Complex instances with custom modules, attachments, email history, and workflow rewrites can take 4–8 weeks. The timeline is driven more by data model redesign and workflow rebuilding than by the actual data transfer. ### Can I migrate Zoho CRM custom modules to HubSpot? Yes, but only on HubSpot Enterprise. Custom modules map to HubSpot custom objects, which are capped at 10 per portal (expandable at $500/month for 10 more). If your Zoho instance has more than 10 custom modules, you must consolidate, flatten some into standard object properties, or keep them in an external system. ### What happens to Zoho CRM Leads in HubSpot? HubSpot has no separate Leads object. Zoho Leads are imported as HubSpot Contacts with lifecycle stage set to 'Lead' or 'Subscriber.' You must deduplicate against existing Contacts before import to avoid creating duplicate records for people who exist as both a Lead and a converted Contact in Zoho. ### Do Zoho CRM workflows and Deluge scripts transfer to HubSpot automatically? No. Zoho workflows, Blueprints, and Deluge custom functions cannot be exported or automatically translated. Each must be manually audited, mapped to a HubSpot workflow equivalent, and rebuilt. Complex Deluge functions require HubSpot Operations Hub Professional or Enterprise for custom coded actions. ### Can HubSpot's native Zoho connector replace a full migration? No. HubSpot's Zoho connector is a data sync tool, not a migration tool. It can help during parallel-run overlap, but it does not handle historical activity migration, custom-object design, attachment transfer, or workflow rewrites.