HubSpot Service Hub to Intercom Migration (2026 Guide)

Why Teams Migrate from HubSpot Service Hub to Intercom

A HubSpot Service Hub to Intercom migration moves your support operation from a CRM-integrated service layer to a messenger-first customer data platform (CDP). You are shifting from CRM-centric service — where support is one function inside HubSpot's unified CRM — to communication-centric engagement where support, onboarding, proactive messaging, and AI operate from a single messaging platform.

Teams make this switch for specific platform reasons:

• Intercom's Messenger for in-product communication with persistent conversation history.
• Fin AI for automated resolution — an LLM-powered agent that resolves conversations autonomously using your Articles and custom actions. Significantly more capable than HubSpot's rule-based chatflows, which rely on static decision trees.
• Proactive messaging and Product Tours for customer lifecycle engagement.
• A simpler agent experience — moving from HubSpot's CRM-heavy interface (too many objects, properties, and CRM noise for agents who only handle support) to Intercom's conversation-focused Inbox.

For a deeper comparison of both platforms' architectures, see Intercom vs HubSpot Service Hub (2026): The Operations Lead's Guide.

This migration is non-trivial because of three architectural differences:

• CRM-integrated service vs. messenger-first CDP. HubSpot's contact model is CRM-shaped (lifecycle stages, deals, marketing attribution). Intercom's is engagement-shaped (last seen, custom events, session data). The migration translates between paradigms, not just platforms.
• Engagement model vs. conversation parts model. HubSpot separates the ticket container from content (engagements linked via Associations API). Intercom keeps the thread inside the conversation as parts. Each HubSpot engagement becomes an Intercom conversation part with type-specific transformation.
• Cross-object Workflows vs. conversation-scoped Workflows. HubSpot Workflows span objects — trigger on a contact property change, update a ticket. Intercom Workflows are conversation-scoped. Cross-object automation has no Intercom equivalent.

The CRM Decoupling Decision: Keep HubSpot or Leave Entirely?

This decision shapes scope, timeline, and cost. Make it before any data work begins.

Scenario A: Decoupled Model — Intercom handles conversations, HubSpot CRM stays.

Scope narrows to migrating tickets (as Intercom Conversations and/or Tickets), service Workflows, knowledge base, and agent configuration. Contacts and companies remain in HubSpot CRM. Install Intercom's HubSpot integration app so agents see CRM context (contact properties, company data, deal info) in the Intercom Inbox sidebar.

• Pros: Narrower scope, faster migration, sales and marketing teams unaffected.
• Cons: Permanent integration dependency. CRM data visible via sidebar rather than natively. Cross-object Workflows must be split across two platforms.

Scenario B: Full Departure — leave HubSpot entirely.

Scope broadens to migrating tickets, contacts, companies, knowledge base, and all service data. CRM data (deals, lifecycle stages) moves to a replacement CRM or is archived.

• Pros: Eliminates HubSpot dependency and subscription costs. Single platform for customer engagement.
• Cons: Significantly longer timeline. Unified CRM activity timeline lost. Intercom's contact model is CDP-shaped, so lifecycle stages and deal data translate awkwardly.

Recommendation: If your team uses HubSpot CRM for sales and marketing (not just service), Scenario A is typically the right call. If HubSpot is only used for service, Scenario B is cleaner. If you're adopting Intercom partly for its CDP capabilities (custom events, product usage data, in-product messaging), Scenario B may be preferred even though it's harder.

Intercom plan considerations: Your Intercom plan affects this decision. Intercom's API access, Fin AI availability, and Surveys product vary by tier. As of 2025, Fin AI is available on Essential ($29/seat/month), Advanced ($85/seat/month), and Expert ($132/seat/month) plans, but custom actions, advanced Workflow branching, and higher API throughput may require Advanced or Expert. Verify which plan your migration requires before committing — discovering mid-migration that your plan lacks a needed API endpoint or feature forces a plan upgrade or architecture change.

HubSpot Service Hub to Intercom Object & Field Mapping

This migration requires translating CRM-shaped data into CDP-shaped data. Do not attempt a lift-and-shift.

HubSpot Object	Intercom Object	Transformation Rule	Known Limitations
Tickets	Conversations AND/OR Tickets	Route by pipeline: "Support" → Conversations, "Engineering Escalation" → Tickets. Create ticket types first if using Intercom Tickets.	Intercom requires ticket types as a prerequisite. No pipeline Kanban view in Intercom.
Engagements (email)	Conversation Parts (reply, public)	Preserve HTML body, map HubSpot Owner → Intercom Admin ID, Contact → Contact ID. Carry over timestamp.	Create-conversation endpoint does not support HTML in body; reply/note endpoints do.
Engagements (note)	Conversation Parts (note, internal)	Map author, preserve timestamp and body.	—
Engagements (call)	Conversation Parts (note, internal)	Include call metadata: duration, recording URL, disposition.	Some call engagements have no body — metadata only. Creates sparse entries.
Contacts	Contacts (role = "user" or "lead")	Core identity fields map directly. CRM fields (lifecycle stage, lead status) → custom attributes or stay in HubSpot.	role = "lead" for pre-signup visitors, "user" for known users.
Companies	Companies	Name and domain map directly. CRM properties (revenue, employee count) → custom attributes or stay in HubSpot.	CSV import does not support company data — API or integration app only. (intercom.com)
Ticket Pipelines	No direct equivalent	Pipeline stages → Intercom conversation state (open/closed/snoozed) + custom attributes for stage granularity.	No drag-and-drop pipeline UI in Intercom.
Properties (custom)	Custom Attributes	Intercom types: string, integer, boolean, date, list. Calculated and score properties migrate as static values only.	Must create typed attribute definitions before loading data. (intercom.com)
Knowledge Base	Articles	Categories → collections, subcategories → sections, articles → articles.	Up to three levels of collection nesting. (intercom.com)
Snippets	Macros	Macros can include actions: assign, tag, snooze, close.	HubSpot Playbooks have no direct equivalent — recreate as Saved Replies, linked Articles, or Workflow-based guided paths.
Workflows	Workflows (conversation-scoped)	See Workflow decomposition section below.	Cross-object Workflows have no Intercom equivalent.

Additional mapping notes:

• Intercom Tickets (distinct from Conversations) handle tracked, async issues with explicit operational states (submitted/in_progress/resolved/waiting_on_customer). If you choose Intercom Tickets, create ticket types first — Intercom requires them as a prerequisite. (developers.intercom.com)

• Multiple ticket-contact associations: HubSpot tickets can be associated with multiple contacts. Intercom conversations have one contact. Pick the primary requester and document others as internal note parts.

• Attachment size limits: Intercom enforces a 20 MB per file attachment limit and restricts certain file types (executables, scripts). HubSpot attachments exceeding these limits will silently fail during bulk load unless you pre-filter. Download attachments from HubSpot File Manager, validate size and type, then re-upload to Intercom, updating URLs in conversation bodies.

The property pruning exercise: HubSpot instances often have 50–200+ custom properties. Migrating all of them to Intercom creates permanent clutter. Audit every property and classify as: must-have in Intercom (needed for agent context, Workflow routing, or Fin AI targeting), stay-in-HubSpot (visible via integration app), or drop. This exercise typically reduces the migrated property count by 40–60%. See the Help Desk Data Migration Playbook for a framework on deciding what to leave behind.

Migration Approaches for HubSpot Service Hub to Intercom

a) CSV Export + Intercom CSV Import — HubSpot exports contacts, companies, and tickets as CSV. Intercom's CSV import supports contacts only (not companies or conversations). Useful as a supplementary method for people data, not a full migration path.

b) API-Based Migration — Extract via HubSpot CRM API v3 (batch endpoints, Search API with 10,000 result limit, Associations API v4, legacy Engagements API v1). Load via Intercom REST API. HubSpot enforces burst rate limits (100 requests per 10 seconds for private apps) and daily API caps (500,000 calls/day for most plans). Intercom allows 10,000 requests per minute per app, distributed into 10-second windows. Complexity: High on both sides.

c) Managed Migration Service — A provider handles multi-endpoint extraction, engagement assembly, timestamp handling, routing decisions, and CRM decoupling advisory. Strongly recommended for this migration path given compound complexity.

d) Hybrid: CSV for Contacts + API for Conversations — Import contacts via CSV (fast, handles dedup), then load conversation history via API. A practical middle ground when contact volumes are manageable.

e) Clean-Break Migration — Archive HubSpot, set up Intercom from scratch, skip historical conversation import. More common for HubSpot → Intercom than HubSpot → Zendesk because the import-side challenge makes full history migration riskier. Keep HubSpot accessible in read-only mode for 6–12 months.

Migration Architecture: HubSpot Extract → Transform → Intercom Load

Both sides are constrained. This is the compound bottleneck that defines this migration.

HubSpot Extraction

Use CRM API v3 batch endpoints (POST /crm/v3/objects/tickets/batch/read, 100 records per call). Use the Search API for filtered extraction (POST /crm/v3/objects/tickets/search), but note the strict 10,000 result limit — use date-range windowing on hs_createdate for larger datasets. Use Associations API v4 for relationships and the legacy Engagements API v1 for engagement details. (developers.hubspot.com)

The Engagement Assembly Step (3–5 API Calls Per Ticket)

This is the extraction bottleneck. For each ticket, the typical call pattern is:

1. Fetch the ticket object — 1 call (or batched, 100 per call)
2. Fetch associations — 1 call to Associations API v4 to get linked engagement IDs, contact IDs, and company IDs
3. Fetch engagement details — 1–2 calls to Engagements API v1 for the engagement bodies (email content, note text, call metadata). Tickets with 10+ engagements may require pagination.
4. Fetch contact details — 1 call if contact data is needed for author attribution and isn't already cached

Sort engagements chronologically and transform each into an Intercom conversation part. This orchestration across the Tickets API, Engagements API, and Associations API is why extraction dominates timeline. For a comparison of how this challenge plays out against a different target, see the HubSpot Service Hub to Zendesk Migration Guide.

Transformation Rules

• HubSpot Email Engagement → Intercom reply part (public, preserve HTML body, map author)
• HubSpot Note Engagement → Intercom note part (internal)
• HubSpot Call Engagement → Intercom note part with call metadata (duration, recording URL, disposition)
• HubSpot Meeting Engagement → Intercom note part with meeting metadata (title, time, attendees). Decide whether sparse meetings (timestamp-only) are worth importing.
• HubSpot pipeline stage → Intercom state + custom attributes
• Contact dedup: use external_id for idempotent create-or-update in Intercom. Keep user_id consistent if you mix CSV and API methods — Intercom identifies CSV imports in this order: Intercom ID → user_id → email. Inconsistent user_id values create duplicates even when the email matches. (intercom.com)

Intercom Load

Load contacts and companies first — conversations require a valid contact_id. Then create conversations with parts, apply tags, and upload attachments.

Intercom's Conversations API accepts a created_at field for setting original timestamps. Current docs describe this as a UTC Unix timestamp "recommended for migrating past conversations." Reply and note endpoints also support created_at. This makes historical timestamp preservation more viable than older migration guides suggest, but with two caveats:

1. HTML rendering differs across endpoints. The create-conversation endpoint does not support HTML in the body, while reply and note endpoints handle formatting differently by API version. Test rendering on a 20–50 record sample before bulk load. (developers.intercom.com)
2. Plan-level behavior may vary. Some teams report created_at being ignored or overwritten on certain plan tiers or API versions. This is why the timestamp test is non-negotiable before committing to full migration.

The Timestamp Test

Before committing to a full migration, run a small batch test (20–50 conversations) in Intercom. Verify whether created_at timestamps are preserved on both conversations and individual parts. If timestamps are not preserved on your specific Intercom plan, you have three options:

1. Store original dates in custom attributes (e.g., original_created_at) — timestamps visible to agents but not in conversation sort order.
2. Prepend original date to conversation body — visible in the thread but not machine-readable.
3. Pivot to a clean-break approach — skip historical import entirely.

Do this test in week 1. Teams that skip the timestamp test commonly discover the issue at week 6 during UAT and must re-run the entire conversation load — adding 2–3 weeks to the timeline.

Throughput Math

HubSpot extraction with engagement assembly yields ~50–100 fully-enriched tickets per minute (assuming average 4 API calls per ticket and 100 req/10sec burst limit). Intercom load requires one conversation + N parts = N+1 API calls. At ~10,000 req/min, you can load ~100–150 conversations per minute for tickets averaging 8 messages. For 150K tickets, plan 25–50 hours of combined extraction and load time (4–7 days running 12–16 hours/day).

A naive extractor averaging 5 HubSpot API calls per ticket will burn ~750,000 calls on 150K tickets. HubSpot's private-app daily cap of 500,000 calls means batching and call reduction are not optimizations — they determine whether you finish in a day or spill into the next. Strategies to reduce call count: batch ticket reads (100 per call), cache contact data across tickets sharing the same contact, and use the associations parameter on batch reads to reduce separate association calls. (developers.hubspot.com)

For details on Intercom's data model and API constraints during the load phase, see Zendesk to Intercom Migration: The 2026 Technical Guide.

Step-by-Step HubSpot Service Hub to Intercom Migration Process

1. Make the CRM decoupling decision. Determine if HubSpot CRM stays alongside Intercom or if you are doing a full departure.
2. Audit and prune properties. Classify every HubSpot custom property as must-have in Intercom, stay-in-HubSpot, or drop. Map surviving properties to Intercom custom attribute types.
3. Test Intercom API timestamp behavior. Create 20–50 test conversations with historical created_at values. Verify timestamps on conversations and parts. If they fail, pivot early.
4. Design pipeline-to-Intercom mapping. Map HubSpot stages to Intercom states (open/closed/snoozed for Conversations; submitted/in_progress/resolved for Tickets).
5. Make the Tickets-vs-Conversations routing decision. Determine which HubSpot tickets become Intercom Conversations vs. Intercom Tickets. If using Tickets, create ticket types first.
6. Create Intercom workspace architecture. Build custom attributes with typed definitions, set up teams and admin accounts, connect channels. Install the HubSpot integration app if using the decoupled model. Map HubSpot Teams → Intercom Inbox Teams (each Intercom team maps to a set of admins and can be assigned conversations via Workflows or manual routing).
7. Extract and load contacts and companies. Contacts and companies must exist in Intercom BEFORE creating conversations.
8. Extract tickets with engagement assembly. Pull tickets via batch/search endpoints with date-range windowing. Fetch associated engagements, sort chronologically, transform into conversation parts. Pre-filter attachments for Intercom's 20 MB size limit and allowed file types.
9. Load conversations/tickets with parts. Push assembled threads to Intercom while managing rate limits. Verify HTML rendering.
10. Upload attachments. Download from HubSpot File Manager, validate size (<20 MB) and type, re-upload to Intercom, updating URLs in bodies.
11. Migrate knowledge base. Move HubSpot articles to Intercom Articles. Optimize content for Fin AI consumption (see dedicated section below).
12. Set up Fin AI. Configure Fin with content sources, handoff rules, tone settings, and custom actions. Test resolution quality (see dedicated section below).
13. Decompose and rebuild Workflows. Classify HubSpot Workflows, rebuild conversation-scoped ones in Intercom, handle cross-object logic separately.
14. Operational cutover. Install Intercom Messenger on your product (JavaScript snippet or SDK). Route email channels to Intercom (update MX/forwarding rules). If using Intercom's Help Center, update DNS CNAME records for your help center domain. Set up redirect rules from old HubSpot KB URLs to new Intercom Articles URLs.
15. Validate. Reconcile record counts, verify timestamps and author attribution, test Fin AI, run agent UAT.

How to Decompose HubSpot Workflows into Intercom Workflows

Audit every active HubSpot Workflow that touches tickets. Classify each into one of four categories:

• Conversation-scoped, event-driven ("When ticket status changes to X, assign to team Y") → Rebuild as an Intercom Workflow. Intercom Workflows support branching, wait steps, and Fin AI integration — often a cleaner representation than HubSpot's multi-branch trees.
• Conversation-scoped, time-driven ("If ticket open 48 hours without response, escalate") → Rebuild as an Intercom Workflow with time-based conditions.
• Cross-object ("When lifecycle stage changes to Customer, tag all open conversations") → No Intercom equivalent. Stays in HubSpot CRM (if retained), moves to middleware (Zapier/Make), or is accepted as lost with stakeholder sign-off.
• CRM-only ("When deal closes, create CS task") → Not an Intercom concern. Stays in HubSpot or the replacement CRM.

The Fin AI redesign opportunity: Do not port HubSpot chatflows line by line. HubSpot chatflows are rule-based bots with static decision trees. Intercom's Fin AI is an LLM-powered agent that resolves conversations autonomously using your Articles and custom actions. Redesign the approach: Fin reads the customer message, searches Articles, and either resolves or hands off to a human via Workflow routing.

Fin's configuration involves more than "turning it on":

• Content sources: Select which Article collections Fin can access. Exclude internal-only or draft content.
• Custom actions: Configure API-based actions Fin can take (e.g., check order status, reset password) via Intercom's custom actions framework.
• Handoff rules: Define when Fin escalates to a human — by topic, sentiment, customer segment, or after N failed resolution attempts.
• Tone and persona: Set Fin's conversational style (formal, casual, brand-specific phrasing).
• Content exclusions: Prevent Fin from surfacing specific articles or topics (e.g., pricing changes not yet announced).

Fin's effectiveness depends directly on article quality — plan article improvement as part of the migration, not as a post-launch task. Teams that treat Fin setup as a checkbox ("turn on Fin") typically see 15–25% automated resolution rates; teams that invest in article quality and custom actions reach 35–50%+.

Timeline: Workflow audit and build takes 1–2 weeks for 10–30 active Workflows. Fin AI setup and chatflow redesign adds 1–2 weeks.

How to Migrate HubSpot Knowledge Base to Intercom Articles

This migration carries more weight than in a HubSpot → Zendesk move. Intercom Articles directly power Fin AI — article quality and completeness determine Fin's automated resolution rate.

Structure mapping: HubSpot KB categories → Intercom Article collections. HubSpot subcategories → Intercom sections. HubSpot articles → Intercom articles.

Extract content via HubSpot's CMS API or KB export. Load via Intercom Articles API for programmatic creation. If you have fewer than 30 articles, manual rewriting may produce better Fin AI results because each article can be optimized for Fin's consumption — clear question-answer format, self-contained answers, accurate information.

Article optimization for Fin AI:

• Titles should match customer phrasing. Instead of "Billing Configuration Options," use "How do I change my billing plan?" Fin matches customer questions to article titles.
• Each article should be self-contained. Fin extracts answers from individual articles — if the answer requires reading two articles, Fin may give an incomplete response.
• Use clear question-answer structure. Lead with the question, follow with a direct answer, then provide details.
• Avoid marketing language in support articles. Fin will surface it verbatim, which sounds wrong in a support context.

Embedded images in HubSpot KB articles are hosted on HubSpot's CDN. Download and re-host them or upload directly to Intercom, updating URLs in article bodies. Set up redirects from old KB URLs to new Intercom Articles URLs to preserve SEO equity — use 301 redirects at the DNS or web server level.

After migration, review each article with Fin in mind. Test Fin against your top 20 most common customer questions and identify article gaps.

How Long Does a HubSpot Service Hub to Intercom Migration Take?

Timeline varies by scenario and history-import decision.

Decoupled model + full history import (most common):

• Discovery & planning: 1–2 weeks (property pruning, Workflow classification, timestamp test, routing decision)
• Intercom workspace setup: 1–2 weeks (custom attributes, teams, channels, HubSpot integration app — runs in parallel)
• Workflow decomposition & Fin AI build: 1–2 weeks
• Contact/company sync: 2–5 days
• Conversation history migration: 5–15 days (longest, most variable phase)
• Knowledge base migration + Fin AI optimization: 3–7 days
• Validation & UAT: 1 week
• Go-live, channel cutover & monitoring: 1–2 weeks (includes Messenger installation, email routing, DNS changes)
• Total: 6–10 weeks

Full departure + full history: 8–12 weeks, plus replacement CRM timeline.

Clean-break (either scenario): 4–7 weeks. Removes the 5–15 day conversation migration phase entirely.

Key risks and failure patterns:

• Timestamp preservation fails on your plan. Likelihood: Medium. Impact: Must re-run entire conversation load or pivot approach. Mitigation: Test in week 1; pivot to clean-break or custom-attribute fallback immediately.
• HubSpot engagement extraction slower than estimated. Likelihood: High. Teams regularly hit the 500K daily API cap on day 1 and spill extraction into a second day. Mitigation: Use batch endpoints, cache contacts, use the associations parameter, start extraction early as a background job.
• Cross-object Workflows break agent workflows. Likelihood: Medium. Mitigation: Classify all Workflows in week 1; design middleware bridges (Zapier/Make) or accept loss with documented stakeholder sign-off.
• Fin AI resolution rate low post-migration. Likelihood: Medium-High for teams that skip article optimization. Mitigation: Invest in article quality during migration. Set realistic month-1 targets (25–35% automated resolution) and plan a 30-day optimization sprint post-launch.
• Duplicate contacts in Intercom. Likelihood: High if mixing CSV and API import. Inconsistent user_id or external_id creates duplicates. Mitigation: Set identity resolution rules before loading any data. Use a single identity key consistently. (intercom.com)
• Attachment failures during bulk load. Likelihood: Medium. Files exceeding 20 MB or restricted file types fail silently. Mitigation: Pre-filter attachments before upload; log failures for manual review.

Operational Cutover: Messenger, Email Routing, and Help Center DNS

Data migration is half the project. The operational cutover — switching live customer communication from HubSpot to Intercom — requires its own planning.

Intercom Messenger installation:

• Install the Messenger JavaScript snippet on your web app or marketing site. For mobile apps, integrate the Intercom iOS/Android SDK.
• Configure Messenger visibility rules (which pages, which user segments see the Messenger).
• Set Messenger business hours, away messages, and Fin AI availability.

Email channel routing:

• If you use a support email address (support@company.com), update forwarding rules to route inbound email to your Intercom workspace instead of HubSpot.
• Intercom provides a unique forwarding address per workspace. Update your email provider's forwarding rules or MX records.
• Test email routing in staging before cutover. Verify that reply-to addresses work correctly so customer email replies thread into the same Intercom conversation.

Help Center DNS:

• If migrating your knowledge base to Intercom's Help Center, set up a CNAME record (e.g., help.company.com → custom.intercom.help).
• Implement 301 redirects from old HubSpot KB URLs to new Intercom Article URLs. Map each old URL to its new equivalent.

Cutover sequence: Go live with Messenger + email routing simultaneously. Running both HubSpot and Intercom in parallel for incoming conversations creates confusion — agents must check two inboxes. A clean cutover (pick a date, switch all channels at once) is preferred over a gradual transition for most teams.

What Happens to My HubSpot CRM Data When I Move to Intercom?

Decoupled model: CRM data (contacts, companies, deals, lifecycle stages, marketing data) stays in HubSpot. Agents see it via the Intercom HubSpot app sidebar. Sales and marketing teams are unaffected. The unified activity timeline on HubSpot contact records will no longer show new support interactions (those happen in Intercom), but the integration app can log conversation data back to HubSpot. The native HubSpot app is one-way (Intercom → HubSpot) — for bidirectional sync, add HubSpot's Data Sync app or middleware. (intercom.com)

Full departure: CRM data must go somewhere — migrate to a replacement CRM, keep HubSpot in read-only mode on the Free plan (limited to 1M contacts, 5 users), or export and archive as CSV/JSON. Intercom is not a drop-in CRM replacement. Deal-centric context, lifecycle stages, associated-object reporting, and HubSpot's unified cross-team activity view do not survive as first-class Intercom objects.

Agent workflow change: HubSpot agents work in a CRM interface — contacts, companies, deals, tickets in a unified view. Intercom agents work in a conversation-focused Inbox. Agents accustomed to CRM context alongside tickets will find Intercom's Inbox narrower for CRM data but richer for conversation engagement (Messenger context, customer event history, Fin AI activity). Train agents explicitly on both the loss (CRM depth, deal visibility, lifecycle context) and the gain (conversation threading, AI-assisted responses, Messenger-based engagement).

What Can't Be Migrated from HubSpot Service Hub to Intercom?

Be clear with stakeholders upfront. This is a definitive list:

HubSpot Feature	Intercom Status	Mitigation
Cross-object Workflows	No equivalent	Stays in HubSpot, moves to middleware (Zapier/Make), or accepted as lost
Unified CRM activity timeline	No equivalent	Partially mitigated by HubSpot app sidebar in decoupled model
Playbooks	No equivalent	Recreate as Saved Replies, linked Articles, or Workflow-based guided paths
NPS and CES surveys	Not native	Requires Intercom's Surveys product (Advanced/Expert plans) or third-party tools
Calculated and score properties	Static values only	No dynamic recalculation in Intercom
Kanban pipeline board view	No equivalent	Conversation list views with filters; no drag-and-drop pipeline UI
Deal associations on tickets	No equivalent	Visible only via HubSpot integration app (decoupled) or lost (full departure)
HubSpot task objects	No equivalent	Use Intercom's conversation snooze + follow-up reminders or external task manager
Reporting dashboards	Must rebuild	Rebuild in Intercom Reports; cross-object reports can't be replicated without importing CRM data as custom attributes
Chatflow/bot configuration	Requires redesign	Rebuilt as Fin AI agent paths and Intercom Workflows — more capable but not a migration, it's a redesign
Custom survey question types	Limited	Intercom Surveys support text, rating, dropdown, NPS — fewer question types than HubSpot

Edge Cases and Known Challenges

• Engagement types with no body. Some HubSpot call and meeting engagements have minimal metadata (duration and timestamp only). Importing these as Intercom parts creates sparse entries. Decide whether to import them for the metadata or discard them. Recommendation: discard if fewer than 5% of total engagements; import as notes if they contain recording URLs.
• Multiple ticket-contact associations. HubSpot tickets can be associated with multiple contacts. Intercom conversations have one contact. Pick the primary requester (the contact who created the ticket, or the most recent email sender) and document others as internal note parts.
• HubSpot Owner → Intercom Admin mapping. Map each HubSpot Owner ID to an Intercom Admin ID. Former owners who no longer exist as Intercom admins require a fallback (e.g., a generic "Migration" admin account). Create this admin before migration and use it as the default author for unmatched owners.
• Long-thread QA. A single Intercom conversation GET returns at most 500 conversation parts. Long-thread validation cannot rely on one API read — paginate or verify from both sides. (developers.intercom.com)
• HTML rendering drift. Imported bodies render differently between the create-conversation and reply/note endpoints. Normalize HTML before bulk load (strip unsupported tags like <style>, <script>, and HubSpot tracking pixels) and test on a sample first. (developers.intercom.com)
• Inline images in email engagements. HubSpot email engagements often contain inline images as CID references. These won't render in Intercom unless converted to hosted image URLs during transformation.

Validation & Testing After Migration

• Record-count reconciliation. Tickets exported from HubSpot vs. conversations + tickets created in Intercom. Engagement counts may differ if sparse types were discarded — document the delta and the reason.
• Engagement assembly verification. For a sample of 50+ conversations (stratified by ticket age and engagement count), compare the HubSpot ticket timeline against Intercom conversation parts. Verify every email appears as a reply part, every note as a note part.
• Timestamp verification. Confirm conversations show original HubSpot dates, not migration-date timestamps. Verify per-part timestamps on both the initial message and subsequent replies.
• Author attribution. Customer messages show as contact-authored parts, agent messages as admin-authored parts. Check for the "Migration" fallback admin — if it appears on too many conversations, the owner mapping has gaps.
• Attachment verification. Verify attachments render correctly. Check for broken image links (CID references, expired HubSpot CDN URLs).
• HubSpot integration app validation (decoupled). Verify the sidebar shows correct CRM data for a sample of conversations. Test that new Intercom conversations log back to HubSpot contact records.
• Fin AI validation. Submit your top 20 most common customer questions and verify resolution quality. Identify article gaps. Test handoff behavior — confirm Fin routes to the correct team when it can't resolve.
• Agent UAT. Have 2–3 agents work in Intercom Inbox for 1–2 days. Test CRM context sufficiency (is the sidebar data enough?), Conversation/Ticket distinction (do agents understand which is which?), Fin handoff behavior, and macro/Saved Reply adequacy.
• Long-thread spot check. For tickets with 20+ engagements, verify from both the HubSpot source count and the Intercom UI or paginated API read. The 500-part retrieval ceiling can make a correct migration look incomplete during validation.
• Rollback plan. Keep HubSpot Service Hub accessible for 8–12 weeks post-migration. Rollback procedure: revert email forwarding rules to HubSpot, remove Intercom Messenger snippet, reactivate HubSpot chatflows, notify agents to return to HubSpot Inbox. Rollback should be executable within 2–4 hours.

Should You Migrate HubSpot Service Hub to Intercom In-House or Use a Service?

In-house works when: Small volume (<10K tickets), simple setup (single pipeline, few custom properties), decoupled model with clean-break approach (no history import), and the team's primary goal is adopting Intercom's Messenger and Fin AI rather than preserving legacy data.

In-house doesn't work when: You need to preserve full history. This is one of the migration pairs where managed services are most strongly recommended. The compound challenge — multi-endpoint extraction + timestamp uncertainty + Tickets-vs-Conversations routing + property pruning + Workflow decomposition — compounds quickly. Teams that estimate 4 weeks for a DIY full-history migration routinely spend 8–12 weeks troubleshooting API rate limits and engagement assembly logic. The #1 time overrun: engagement assembly across HubSpot API endpoints (3–5 calls per ticket).

Why is this migration harder than HubSpot to Zendesk? Two reasons. Zendesk has a dedicated Ticket Import API with guaranteed timestamp preservation — Intercom does not. And Intercom has two interaction objects (Conversations and Tickets) requiring a routing decision that doesn't exist with Zendesk's single-object model. The result: complexity on both the extraction and import sides.

HubSpot Service Hub to Intercom Migration FAQ

How long does a HubSpot Service Hub to Intercom migration take? Decoupled model with full history: 6–10 weeks. Full departure: 8–12 weeks. Clean-break: 4–7 weeks. The conversation history migration phase (5–15 days) is the longest and most variable.

Can I keep my full HubSpot ticket history in Intercom? Yes, but only with an API-led migration. Intercom's Conversations API supports a created_at parameter for setting original timestamps on conversations, and reply/note endpoints also support it. Test this in week 1 to verify behavior on your plan — per-part timestamp handling may vary by plan tier and API version.

What data is lost when migrating from HubSpot Service Hub to Intercom? Cross-object Workflows, the unified CRM activity timeline, Playbooks, NPS/CES surveys (unless using Intercom's Surveys product on Advanced/Expert plans), calculated/score properties (become static), Kanban pipeline views, deal associations on tickets, HubSpot task objects, and chatflow bot configurations (require redesign as Fin AI paths).

Can I keep HubSpot CRM and just move service to Intercom? Yes — this is the decoupled model and the most common approach. Install Intercom's HubSpot app to surface CRM context in the Inbox sidebar. The native app is one-way (Intercom → HubSpot) — bidirectional sync requires HubSpot Data Sync or middleware.

Why is HubSpot to Intercom migration harder than HubSpot to Zendesk? Zendesk has a dedicated Ticket Import API with guaranteed timestamp preservation — Intercom does not. Intercom also has two interaction objects (Conversations and Tickets) requiring a routing decision that doesn't exist with Zendesk's single-object model.

What Intercom plan do I need for this migration? All Intercom plans (Essential, Advanced, Expert) provide API access and Fin AI. However, Advanced ($85/seat/month) and Expert ($132/seat/month) provide additional Workflow branching, custom actions for Fin, Surveys (for NPS/CES), and higher support limits. Most teams migrating from HubSpot Service Hub Professional or Enterprise will need Intercom Advanced or Expert to match feature parity.

How do I handle the operational cutover? Install Intercom Messenger (JavaScript snippet or mobile SDK), update email forwarding rules to route to Intercom, set up DNS CNAME for Help Center, and implement 301 redirects from old KB URLs. Do a clean cutover on a specific date rather than running both platforms in parallel.