Migrate HubSpot Service Hub to Zendesk by decoupling service from CRM, assembling engagements via 3–5 API calls per ticket, and rebuilding ticket-scoped Workflows.
Migrating from HubSpot Service Hub to Zendesk requires decoupling a CRM-integrated service layer into a standalone helpdesk, with no native migration path between the two platforms. The fundamental data model difference is that HubSpot stores ticket interactions as separate Engagement objects (emails, notes, calls) linked via associations across multiple APIs, while Zendesk stores them as inline comments on tickets—requiring multi-endpoint extraction and structural transformation. Custom work includes decomposing cross-object HubSpot Workflows into ticket-scoped Zendesk triggers, rebuilding SLA policies, pruning and remapping 50–200+ custom properties, and resolving multi-contact ticket associations into Zendesk's single-requester model. Teams must also make a critical upfront architectural decision—whether to keep HubSpot CRM alongside Zendesk or depart entirely—as this shapes every aspect of scope, timeline, and integration work.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not confuse sync with migration
HubSpot's official data sync supports one-way or two-way record sync and continues syncing updates after the initial load. The Zendesk-HubSpot integration writes Zendesk ticket events into the HubSpot contact timeline, but that integration is one-way from Zendesk to HubSpot. Neither of these is a historical ticket migration tool. (knowledge.hubspot.com)
The Property Pruning Exercise
HubSpot instances often have 50–200+ custom properties. Migrating all of them to Zendesk creates an agent workspace full of dead fields. Audit every property and classify it as must-have, nice-to-have, stay-in-HubSpot, or drop. This exercise typically reduces the migrated property count by 40–60%. Keep only what drives routing, reporting, or agent judgment in Zendesk. (developer.zendesk.com)
Rate limit math
HubSpot private apps on Professional/Enterprise enforce approximately 190 requests per 10 seconds (burst), though exact limits change — always check current API documentation. Batch endpoints (100 records/call) improve throughput for flat fetches, but engagement assembly requires per-ticket association and engagement calls. Realistically, expect 50–100 fully-enriched tickets per minute after accounting for multi-endpoint extraction. For 150K tickets, plan for 25–50 hours of extraction time. Zendesk's Ticket Import API handles up to 700 requests per minute on Enterprise plans and 400 on Professional — HubSpot extraction, not Zendesk import, is your bottleneck.
Error handling
HubSpot returns Retry-After headers on 429 responses — respect them. Log failed records with HubSpot's correlationId for debugging. Zendesk's Ticket Import API does not calculate SLA metrics for imported tickets — add an imported_from_hubspot tag to exclude them from current reporting. For very large closed-history loads, Zendesk supports archive_immediately so closed imported tickets bypass the active lifecycle and land directly in the archive. (developer.zendesk.com)
Rollback plan
Keep HubSpot Service Hub active and accessible for 8–12 weeks post-migration as a fallback and reference archive. Both systems run concurrently during validation — no new tickets go to HubSpot, but agents can reference historical data there. Tickets created in Zendesk during the overlap period stay in Zendesk only; the Zendesk-HubSpot integration can write activity back to HubSpot contact timelines if configured, but this is not a bidirectional ticket sync. Define the cutover point clearly: after validation, new inbound channels (email, chat, web form) point to Zendesk and HubSpot Service Hub stops receiving tickets.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of HubSpot Service Hub
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Zendesk can hold your support model
Walk your current workflow through Zendesk: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated HubSpot Service Hub → Zendesk timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
HubSpot Service Hub → Zendesk specifics
- CRM-integrated vs. standalone helpdesk
- Every HubSpot ticket is tied to CRM Contact and Company records with deal associations and a shared activity timeline. Zendesk tickets have a requester and organization — no native CRM.
- Engagement model vs. comment model
- HubSpot stores ticket interactions as separate Engagement objects (emails, notes, calls, tasks) linked via associations. Zendesk stores them as comments directly on the ticket. Reconstructing a full conversation thread requires multi-endpoint extraction.
- Cross-object Workflows vs. ticket-scoped triggers
- HubSpot Workflows can span objects — trigger on a contact property change and update a ticket. Zendesk triggers fire on ticket create/update events only; automations run hourly and check time-based conditions on tickets only. Neither can natively reference external CRM objects. (knowledge.hubspot.com)
- API-based migration
- Best default for any serious history move. Use HubSpot extraction APIs and the Zendesk Ticket Import API (POST /api/v2/imports/tickets). Preserves original timestamps and bypasses automations on imported tickets. Medium-high complexity due to multi-endpoint engagement assembly.
- Hybrid: CSV for contacts + API for tickets
- Import contacts and organizations via Zendesk CSV import (handles dedup by email), then import tickets with full engagement history via the Ticket Import API. The recommended pragmatic middle ground for most mid-size migrations in the full-departure scenario.
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full HubSpot Service Hub export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the HubSpot Service Hub export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in HubSpot Service Hub where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing -
Download attachments
from HubSpot's File Manager API. Note: Zendesk enforces a per-file attachment size limit of 50 MB on Suite Enterprise (20 MB on lower plans). If HubSpot attachments exceed the limit for your Zendesk plan, you must either compress, link externally, or skip with a logged warning.
-
Export everything first
Use HubSpot's data export to download contacts, companies, deals, tickets, and engagement history as CSV/XLSX. Store exports in a durable archive (cloud storage with retention policy). This is your compliance safety net.
HubSpot Service Hub → Zendesk specifics
- CSV export + Zendesk CSV import
- Good for staging flat contact and company data. Not sufficient for ticket conversations, because HubSpot's ticket content is assembled from separate engagement records rather than a single exportable thread. (developers.hubspot.com)
- Fetch ticket properties
- POST /crm/v3/objects/tickets/batch/read (100 records per call)
- Fetch ticket associations
- GET /crm/v4/objects/tickets/{ticketId}/associations/engagements to get linked contacts, companies, and engagements. Batch association reads support up to 1,000 inputs per request.
- Fetch each engagement
- GET /engagements/v1/engagements/{engagementId} (legacy Engagements API, still required for full engagement details). Email engagements have from/to/cc in metadata; notes have a body; calls have duration and recording URL. Each type needs a different transformation. (developers.hubspot.com)
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass HubSpot Service Hub → Zendesk field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the HubSpot Service Hub → Zendesk field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Zendesk has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
HubSpot Service Hub → Zendesk specifics
- HubSpot Tickets → Zendesk Tickets
- One-to-one. HubSpot pipeline stages (New, Waiting on contact, Waiting on us, Closed — plus custom stages) map to Zendesk statuses (New, Open, Pending, Solved, Closed — plus custom statuses on Suite Enterprise). Multiple HubSpot pipelines may map to separate Zendesk ticket forms, a shared form with a categorization field, or consolidate into groups and views. This is a design decision — get agent sign-off before implementation.
- HubSpot Engagements → Zendesk Ticket Comments
- The most important structural transformation. Each email engagement becomes a public Zendesk comment. Each note engagement becomes a private/internal comment. Call engagements become internal comments with structured metadata (duration, recording URL, disposition). Task and meeting engagements become internal comments or are discarded. Author attribution (HubSpot Owner → Zendesk Agent, contact email → Zendesk end-user), timestamp, and HTML body must be preserved per comment. Email engagement detail requires the sales-email-read scope. (developers.hubspot.com)
- HubSpot Contacts → Zendesk End Users
- Core identity fields (name, email, phone) map directly. CRM-specific fields (lifecycle stage, lead status, deal history) have no native Zendesk equivalents. In the decoupled model, these stay in HubSpot CRM visible via sidebar. In full departure, store critical fields in Zendesk custom user fields.
- HubSpot Companies → Zendesk Organizations
- Name and domain map directly. CRM properties (revenue, employee count, industry) go to custom org fields or are left behind.
- HubSpot Ticket-Contact Associations → Zendesk Requester
- HubSpot tickets can be associated with multiple contacts. Zendesk tickets have one requester. Pick the primary contact; handle additional contacts as CCs, followers, or internal notes.
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Zendesk sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Zendesk sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Zendesk's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Zendesk, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while HubSpot Service Hub stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Zendesk's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze HubSpot Service Hub and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep HubSpot Service Hub read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile HubSpot Service Hub and Zendesk record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Zendesk, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep HubSpot Service Hub read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
-
Verify data retention obligations
Industry regulations (HIPAA, SOX, FINRA) may require retaining customer communication records for 3–7+ years. Confirm your Zendesk instance holds the required history before deleting HubSpot data.
HubSpot Service Hub → Zendesk specifics
- Downgrade before canceling
- HubSpot's Free CRM tier retains your data in read-only mode indefinitely. If you might need to reference historical CRM data, downgrade to Free rather than canceling outright. This costs nothing and preserves deal history, marketing data, and the unified timeline.
- Cancel paid subscriptions at renewal
- Review your HubSpot contract for cancellation notice periods (typically 30–60 days before renewal). Annual contracts may have early termination fees.
- Revoke API keys and deauthorize integrations
- Remove all private app tokens, OAuth connections, and third-party integration authorizations from HubSpot to prevent orphaned data flows.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets | low | Tickets migrate one-to-one via Zendesk's Ticket Import API with original timestamps preserved, though pipeline stages must be mapped to Zendesk statuses or custom statuses. |
| Ticket Comments (Engagements) | high | Each HubSpot engagement type (email, note, call, task) must be extracted via separate API endpoints and restructured into Zendesk comments with correct visibility, author attribution, and chronological ordering. |
| Contacts / End Users | low | Core identity fields like name, email, and phone map directly to Zendesk end users, though CRM-specific properties such as lifecycle stage and lead status have no native equivalent. |
| Companies / Organizations | low | Company name and domain map directly to Zendesk organizations, but CRM properties like revenue and employee count require custom organization fields or are left behind. |
| Custom Fields / Properties | medium | Type matching between HubSpot and Zendesk field types is straightforward for basic types, but calculated and score properties can only be migrated as static values frozen at migration time, and dropdown options must be pre-created. |
| Ticket-Contact Associations | medium | HubSpot's many-to-many ticket-contact associations must be collapsed to Zendesk's single-requester model, with secondary contacts handled as CCs or followers, risking loss of association context. |
| Workflows / Automations | high | Cross-object HubSpot Workflows have no Zendesk equivalent and must be manually decomposed into ticket-scoped triggers, time-based automations, and external middleware, with no automated conversion path. |
| SLA Policies | medium | SLA policies must be manually recreated in Zendesk's more granular multi-policy system, and historical SLA compliance data does not transfer between platforms. |
| Knowledge Base Articles | medium | Articles can be migrated to Zendesk Guide, but HubSpot's knowledge base structure, custom templates, and content formatting may require rework to fit Zendesk Guide's theme and content block architecture. |
| NPS/CES Surveys and Playbooks | high | HubSpot's NPS/CES feedback surveys and Playbooks have no native Zendesk equivalents, requiring third-party tools or complete replacement with Zendesk's CSAT survey or marketplace apps. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
CRM Decoupling Architecture Decision
Every HubSpot ticket is tied to CRM Contact, Company, and Deal records with a shared activity timeline, so the team must decide whether to keep HubSpot CRM alongside Zendesk (requiring a permanent integration dependency) or depart entirely (requiring a replacement CRM and broader migration scope).
Engagement-to-Comment Transformation
Reconstructing full conversation threads requires 3–5 API calls per ticket across HubSpot's Tickets, Engagements, and Associations APIs to extract emails, notes, calls, and tasks, then restructure them as Zendesk public or internal comments with preserved author attribution and timestamps.
Cross-Object Workflow Decomposition
HubSpot Workflows can span objects—triggering on a contact property change to update a ticket—while Zendesk triggers and automations are strictly ticket-scoped, requiring each cross-object Workflow to be decomposed into ticket-scoped logic in Zendesk and CRM-scoped logic in HubSpot or middleware.
Multi-Contact Association Resolution
HubSpot tickets can be associated with multiple contacts, but Zendesk tickets support only a single requester, so teams must define rules to select a primary contact and handle additional contacts as CCs, followers, or internal notes.
Custom Property Pruning and Remapping
HubSpot instances often carry 50–200+ custom properties, and migrating all of them creates an agent workspace cluttered with irrelevant fields, requiring a property audit that typically reduces the migrated field count by 40–60% through must-have/drop classification.
Pipeline-to-Form/Group/View Mapping
Multiple HubSpot ticket pipelines with custom stages must be mapped to Zendesk's combination of ticket forms, groups, views, and custom statuses (Enterprise-only), which fundamentally changes how agents see fields, route tickets, and manage queues.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a HubSpot Service Hub to Zendesk migration take?
Decoupled model (HubSpot CRM stays): 4–7 weeks. Full departure (leaving HubSpot entirely): 6–10 weeks for the service migration plus the replacement CRM timeline. The main bottleneck is multi-endpoint engagement extraction from HubSpot, not the Zendesk import.
Can I keep my full HubSpot ticket history in Zendesk?
Yes. The Zendesk Ticket Import API (POST /api/v2/imports/tickets) preserves original created_at, updated_at, and solved_at timestamps. Each HubSpot engagement (email, note, call) is imported as a Zendesk comment with its original timestamp and author attribution. A flat CSV export alone will not recreate threaded history — you need API-based extraction.
What data is lost when migrating from HubSpot Service Hub to Zendesk?
Cross-object Workflows, the unified CRM activity timeline, Playbooks, NPS/CES surveys (native), calculated and score properties (as dynamic fields), active lists, deal associations on tickets, the Kanban pipeline board view, and historical SLA compliance data.
Can I keep HubSpot CRM and just move service to Zendesk?
Yes — this is the decoupled model and the most common approach. Migrate tickets and service configuration to Zendesk while contacts, companies, and deals stay in HubSpot CRM. Install the Zendesk-HubSpot marketplace app for sidebar CRM context. Sales and marketing teams are unaffected.
Can I migrate HubSpot Workflows to Zendesk triggers?
Ticket-scoped Workflows translate to Zendesk triggers (event-driven) and automations (time-driven). Cross-object Workflows that span contacts, deals, and tickets have no Zendesk equivalent and must stay in HubSpot CRM, move to middleware like Zapier or Make, or be accepted as lost functionality.