---
title: "Intercom vs Helpshift (2026): Architecture, TCO & Migration Guide"
slug: intercom-vs-helpshift-2026-architecture-tco-migration-guide
date: 2026-08-25
author: Raaj
categories: [Intercom, Migration Guide, Help Desk]
excerpt: "Intercom is a per-seat, AI-first web platform. Helpshift is SDK-driven and mobile-first. Compare architecture, TCO, API limits, and the full migration path."
tldr: "Intercom is built for web-first, AI-driven SaaS support with per-seat pricing. Helpshift is built for in-app mobile/gaming support with issue-based pricing. Migration requires custom API scripting and identity reconciliation."
canonical: https://clonepartner.com/blog/intercom-vs-helpshift-2026-architecture-tco-migration-guide/
---

# Intercom vs Helpshift (2026): Architecture, TCO & Migration Guide


# Intercom vs Helpshift (2026): Architecture, TCO & Migration Guide

**Intercom is a per-seat, AI-first customer platform built for web and omnichannel support at scale. Helpshift is a mobile-first, SDK-driven platform built for in-app messaging, device telemetry, and issue-based automation — primarily in gaming and consumer mobile apps.** If you're comparing them, you're deciding between two fundamentally different support architectures, not two flavors of the same tool.

This guide breaks down the real architectural differences, data models, total cost of ownership math, API constraints, compliance considerations, and what a production migration between these platforms actually involves.

> [!NOTE]
> **Mid-2026 context:** On May 12, 2026, Intercom rebranded the company to **Fin**, while Intercom remained the product name and API namespace. Salesforce signed a definitive agreement to acquire Fin for approximately $3.6 billion on June 15, 2026 — pending regulatory approval and expected to close in Salesforce's Q4 FY2027. Pricing, API endpoints, and product behavior have not changed as a result of the rebrand or acquisition. Helpshift continues operating independently. Confirm live pricing with both vendors before signing.

## Who Each Platform Is Built For

This is the decision that matters most. Getting it wrong means fighting the platform's architecture for the life of the contract.

### Intercom: Web-First, AI-First Omnichannel Support

Intercom is a **conversation-centric customer platform** designed for SaaS, e-commerce, and mid-market/enterprise teams that need live chat, email, ticketing, a help center, and AI-driven resolution under one roof. Its primary delivery channel is the Messenger widget — embedded on web and mobile — but it also covers email, WhatsApp, SMS, phone, and Slack.

The platform's center of gravity is its AI agent, **Fin**, powered by a proprietary model called Apex. Fin resolves customer queries end-to-end across every supported channel. Public customer stories reflect this focus: AI21 Labs reports 82% support automation efficiency and a 39% lower average response time, while Amplitude credits automation and consolidation with saving $1 million.

Intercom's data model is **object-oriented**: Contacts (users and leads), Companies, Conversations (with conversation parts), Tickets, Articles, Segments, and Tags all exist as separate API-addressable entities with rich relationships between them. A B2B support engineer can see a user's entire history, their company's MRR, custom attributes, and product usage in a single view.

**Best fit:** B2B SaaS, web-first businesses, teams that want AI resolution at the center of their support motion, organizations already integrated with Salesforce/HubSpot CRM workflows.

### Helpshift: Mobile-First, SDK-Driven In-App Support

Helpshift is a **mobile-first support platform** built around native SDKs that embed directly into iOS, Android, Unity, Unreal Engine, React Native, and Windows PC apps. Its core use case is **in-app messaging** — players or users never leave the app to get help.

The platform was built for gaming studios and high-volume consumer mobile apps. It includes a patented QR-based access system for console support, Discord automation, and device-level telemetry collection that web-first platforms don't offer. Helpshift is a Unity Verified Solutions Partner. Public reference stories skew heavily toward gaming: Rovio reports 91% deflection across 23 games, and Zynga reports 2x agent productivity and 185% more contacts handled.

Helpshift's data model is **issue-centric**. Every customer problem or inquiry directed to an agent or bot creates an **Issue** — the fundamental unit of work, billing, and reporting. When a user opens the Helpshift SDK inside a mobile game, they start a discrete Issue. Once resolved, it's closed. The next time they write in, a brand new Issue is created. Every issue payload automatically captures device telemetry: app version, OS version, device model, battery level, carrier data. This is designed for high-volume consumer triage where a bug might be specific to "iOS 17.4 on an iPhone 13 running App Version 2.1."

**Best fit:** Mobile gaming studios, consumer mobile apps with high ticket volume, teams that need in-app SDK support with device telemetry, organizations handling COPPA compliance for younger users.

## Architecture and Data Model Comparison

The data model gap is what makes migration between these platforms genuinely hard. These aren't two ticket systems with different UIs — they model customer support fundamentally differently.

| Dimension | Intercom | Helpshift |
|---|---|---|
| **Core object** | Conversation (with parts) | Issue (with messages) |
| **Contact model** | Contacts (user/lead roles), Companies | Device profiles, user identity via SDK |
| **Identity anchor** | Email, external ID, Intercom user ID | Device ID, SDK user identifier, gaming platform IDs |
| **Channels** | Messenger, email, WhatsApp, SMS, phone, Slack | In-app SDK (iOS, Android, Unity, Unreal, React Native, PC), web, email |
| **AI agent** | Fin ($0.99/resolution) | AI Agent + Copilot (included in plan, limited bots on Starter) |
| **Ticketing** | Full ticketing with custom ticket types (up to 50 attributes per type) | Issues with states, tags, and custom metadata |
| **Help center** | Articles with collections, multilingual | In-app FAQs with tag-based filtering |
| **Company/org model** | First-class Company objects linked to Contacts | No direct equivalent — segmentation via custom fields |
| **Device telemetry** | Basic browser/OS via Messenger | Deep SDK telemetry: carrier, country code, network, device model, battery level |
| **Custom fields** | Rich attribute types on contacts, companies, tickets | Limited to Date, Checkbox, Drop-down, Single/Multi Line Text, Number |
| **Webhooks** | Supported — real-time event notifications for conversations, contacts, tickets | Supported — real-time callbacks for issue creation, updates, and state changes |
| **Compliance** | HIPAA on Expert plan, GDPR, SOC 2 | COPPA via fullPrivacy flag, GDPR, SOC 2 |

### The Identity Problem

This is where migrations get painful. Intercom identifies contacts primarily by **email address** or **external_id**, with an internal Intercom user ID as the canonical reference. A contact exists independently of any conversation — you can have contacts with zero conversations.

Helpshift identifies users through **SDK-generated device profiles**. A single person using two devices may appear as two separate profiles unless your app explicitly maps them with a consistent user identifier. Helpshift's newer User Hub APIs split identity into **core profiles** and **app profiles**, and those identities can include far more than email: `uid`, phone, Discord, WhatsApp, Google Play, Apple Game Center, Nintendo, PSN, Xbox Live, and Steam. For gaming support, that's a materially better identity surface than a standard SaaS contact object.

This mismatch means you can't do a 1:1 identity map. A typical mapping problem looks like this:

```yaml
source_helpshift:
  uid: player_98421
  apple_gamecenter_id: GC_88421
  email: player@example.com
  custom_issue_fields:
    platform: ios
    build: 6.3.1
    region: NA

target_intercom:
  external_id: player_98421
  email: player@example.com
  custom_attributes:
    apple_gamecenter_id: GC_88421
    platform: ios
    build: 6.3.1
    region: NA
```

That looks simple until you add merged users, anonymous sessions, shared inbox rules, account ownership, and historical tickets. It gets harder in the other direction when one Intercom Company needs to become multiple Helpshift app or player contexts. That's a schema redesign problem, not just an export problem.

## Pricing and Total Cost of Ownership

Both platforms use consumption-based pricing on top of a base cost, but they meter on completely different axes. **TCO** is not just subscription price — it includes usage fees, channel costs, integration work, migration labor, and contract risk.

### Intercom Pricing (Mid-2026)

Unlike flat-rate alternatives (see our [Crisp vs Intercom comparison](https://clonepartner.com/blog/blog/crisp-vs-intercom-2026-architecture-tco-migration-guide/)), Intercom uses **per-seat pricing plus AI resolution fees**:

| Plan | Annual (per seat/mo) | Monthly (per seat/mo) |
|---|---|---|
| Essential | $29 | $39 |
| Advanced | $85 | $99 |
| Expert | $132 | $139 |

On top of seats, Fin AI Agent charges **$0.99 per successful resolution** — a conversation resolved end-to-end without human escalation. There's a minimum of 50 outcomes per month. Fin AI Copilot (the agent-assist feature) is included on Advanced and Expert plans. Advanced includes 20 Lite seats and Expert includes 50 Lite seats.

Channel costs that can significantly inflate TCO: WhatsApp carries a per-message fee structured around Meta's conversation pricing tiers; SMS is billed per message at carrier-variable rates; phone is billed per minute. At scale, these channel fees routinely exceed base seat costs for teams with high WhatsApp or SMS volumes — get per-message rates in writing before signing. Vendr data from 401 Intercom purchases puts the median annual spend at $36,000, with a range from approximately $6,000 to $218,000.

Hidden cost centers are usually usage, not base seats. Fin outcomes, phone, SMS, WhatsApp, and campaign usage can overtake subscription cost at scale. Plan gating also matters: regional data hosting is only available for Advanced and Expert new contract workspaces.

### Helpshift Pricing (Mid-2026)

Helpshift uses **issue-based pricing** — you pay based on the number of customer issues created per month. Helpshift describes its pricing as "solution-based and modular," driven by interaction volume, solutions activated, capabilities used, and geography/language coverage.

Published Starter tier pricing:

| Plan | Base Price | Included Issues | Overage |
|---|---|---|---|
| Starter | $150/month | 250 issues/month | $0.45/issue |
| Growth | Custom | Custom | Reduced per-issue |
| Enterprise | Custom | Custom | Custom |

Helpshift does not charge per agent seat on any plan. All plans include access to the AI Agent and Copilot, though Starter limits you to two custom bots. Higher-volume customers get reduced per-issue pricing through custom contracts.

### TCO Scenarios

**Scenario 1: 10-seat team, 3,000 conversations/month**

For a team where Fin resolves ~50% of conversations:
- **Intercom (Advanced):** 10 × $85 + (1,500 × $0.99) = $850 + $1,485 = **~$2,335/mo** (before channel fees)
- **Helpshift (Growth):** Custom pricing applies at this volume, but at Starter overage rates: $150 + (2,750 × $0.45) = **~$1,388/mo**

**Scenario 2: 50-seat team, 30,000 conversations/month**

At this scale, both platforms move to enterprise/custom pricing. Intercom's per-seat costs dominate: 50 × $85 = $4,250/mo in base seats alone, before AI resolutions. At 50% automation, add 15,000 × $0.99 = $14,850/mo in Fin outcomes — bringing the floor to roughly $19,100/mo before channel fees. Helpshift's seat-free model means the bill scales with issue volume, not headcount. For large support teams handling high-volume mobile support, Helpshift can be significantly cheaper — but only if your use case is mobile/in-app.

> [!WARNING]
> Don't choose a platform based on pricing alone. Intercom's web-first data model and Helpshift's SDK-first architecture serve different use cases. Picking the cheaper option that doesn't match your channel mix will cost more in workarounds than you save on licensing.

## API Constraints That Shape Migration

Every production migration between these platforms runs through their APIs. Understanding the limits before you start scripting saves weeks of debugging.

### Intercom API

- **Version:** 2.15 (as of mid-2026)
- **Rate limits:** 10,000 API calls per minute per private app, 25,000 calls per minute per workspace total. Distributed across 10-second windows.
- **Auth:** Access tokens for private apps, OAuth for public apps.
- **Conversation parts limit:** When retrieving a single conversation, only 500 parts are returned. For long-running conversations, you'll lose history beyond that threshold. There is no pagination parameter to retrieve parts 501+; you must use the full Conversation Export if you need complete threads.
- **File URL expiration:** URLs for user-uploaded images and files expire after 30 minutes. You must download attachments immediately during export — don't store URLs for later processing. If you're exporting 100,000+ conversations, pipeline attachment downloads inline with the conversation fetch, not as a post-processing pass.
- **Search API:** Supports searching contacts, conversations, and tickets with filters. Cursor-based pagination. The Conversations Search API does **not** support filtering by `company_id`. The workaround is to retrieve all contacts associated with a company, then filter conversations by `contact_id` — this requires N+1 API calls per company and is rate-limit-sensitive at scale.
- **Bulk data export:** S3 export available for large datasets, covering up to two years of conversation data — but these exports do **not** include transcripts. Transcript exports also exclude internal notes. S3 exports produce JSON; plan your ETL pipeline accordingly.
- **Contact import matching:** CSV imports match by Intercom ID → user_id → email. If existing profiles are missing `user_id`, imports can create duplicates. To avoid duplicates: deduplicate on email before pushing to the Contacts API. Intercom will create a new contact for any email that doesn't match an existing record's email field, regardless of `external_id`.
- **Companies scrolling:** The Companies endpoint uses a scroll API that supports only one querying session at a time — don't run parallel company exports.
- **Salesforce integration depth:** Intercom has a native Salesforce integration (bi-directional sync of contacts/leads and conversation data). Post-acquisition, this integration is expected to deepen, but as of mid-2026 it operates as a standard third-party connector. Helpshift has no native Salesforce connector; integrations require a middleware layer (Zapier, custom webhooks, or iPaaS tools).

### Helpshift API

- **Base URL:** `https://api.helpshift.com/v1/{domain}/`
- **Auth:** Basic auth with API key. REST API access requires the integrations feature enabled.
- **Pagination:** Default 100 issues per page, configurable up to 1,000 per page, with a maximum of 100 pages per query. This caps a single filtered export at 100,000 issues. To retrieve more than 100,000 issues in a filtered dataset, you must partition by date range and chain multiple queries.
- **Rate limits:** Not publicly documented by Helpshift. In practice, aggressive scripts begin encountering 429 responses at approximately 60–120 RPM depending on payload size and workspace tier — treat this as an empirical floor, not a guarantee, and confirm your specific limit with your Account Manager before building a high-throughput export. Always implement exponential backoff with jitter in your extraction layer.
- **Export format:** Helpshift bulk exports produce JSON. Issue payloads include `id`, `state`, `created_at`, `updated_at`, `messages` array, `meta` (custom fields), and `tags`. The `messages` array contains author type, body, and attachment references — but attachment URLs require authentication to retrieve and are not pre-signed.
- **User Hub Bulk APIs:** Support importing/exporting end user data asynchronously. Limited to 10,000 payloads per single request. For larger datasets, batch into multiple sequential requests.
- **Archival window:** Resolved or rejected issues older than one year are automatically archived. Archived issues are **not accessible via the normal API**. If you're planning a migration, start historical extraction early — this is a hard data loss boundary, not a recoverable one.
- **Custom field constraints:** Custom Issue Fields are limited to Date, Checkbox, Drop-down, Single Line Text, Multi Line Text, and Number. Invalid or archived field keys are **silently dropped** in updates — no error is returned, and you will not know a field failed to write unless you read back the issue and verify.
- **Webhook support:** Helpshift supports real-time webhooks for issue creation, updates, assignment changes, and state transitions. This is relevant for migration cutover: you can use webhooks to capture live issues created after your extraction snapshot and replay them into the target system to close the gap.
- **GDPR data portability:** Processed weekly, not immediately.
- **SDK version support:** Current maintained SDK versions (as of mid-2026) include iOS SDK 10.x, Android SDK 10.x, Unity SDK 5.x, and Unreal SDK 3.x. Older SDK versions (iOS/Android 7.x and below) do not support User Hub identity APIs. If your app is running older SDKs, identity mapping during migration will be limited to device ID and custom user identifier fields only — email may not be available.

> [!TIP]
> Helpshift provides a public [Postman workspace](https://www.postman.com/helpshift/workspace/helpshift-public-workspace/) and sample export scripts on GitHub for both Python and Java. Use these as starting points — they handle pagination correctly and include exponential backoff logic.

> [!CAUTION]
> Do not treat export as a week-of-cutover task. If you are leaving Helpshift, start historical extraction at least 30 days before cutover — you'll lose API access to archived issues older than one year, and there is no recovery path. If you are moving regions inside Intercom, historical conversation data cannot be migrated into the new regional workspace and must be exported for record-keeping first.

## Migration: Helpshift to Intercom

This is the more common direction. Mobile-first companies that expand to web, add B2B sales motions, or need deeper CRM integration often outgrow Helpshift's issue-centric model. (If that B2B expansion relies heavily on Slack, you might compare [Thena vs Helpshift](https://clonepartner.com/blog/blog/thena-vs-helpshift-architecture-tco-migration-guide/) instead).

### What Migrates

| Helpshift Object | Intercom Target | Complexity |
|---|---|---|
| Issues + messages | Conversations (with parts) | High — model mapping required |
| User profiles | Contacts | Medium — identity reconciliation needed |
| FAQ articles | Help Center articles | Low — content export/import |
| Tags | Tags | Low — direct mapping |
| Custom metadata | Custom attributes | Medium — attribute types must match |
| Attachments | Conversation attachments | Medium — re-upload required |
| Bot flows | Fin/Workflows | No migration path — rebuild |
| Device telemetry fields | Custom attributes | Medium — no native Intercom equivalent |

### Bot Flow Rebuild Scope

"Rebuild required" understates what's involved. A typical Helpshift bot flow — branching QuickReply trees with conditional routing, custom metadata reads, and issue-state transitions — maps to Intercom Workflows using the Branching, Condition, and Action blocks. A simple 3-branch triage bot in Helpshift (platform → issue type → auto-tag) translates to roughly 8–12 Workflow nodes in Intercom. A complex flow with 10+ branches, custom field reads, and API Actions may require 40–60+ nodes. Budget 1–2 engineering days per non-trivial bot flow for rebuild and testing, not counting QA in production traffic.

### Step-by-Step

**1. Audit Helpshift custom fields and device telemetry.** Identify all custom fields and automatic device data (OS, app version, carrier, device model, battery level) in Helpshift. Create corresponding Custom Attributes in Intercom (e.g., `hs_app_version`, `hs_device_model`) to hold this data. Intercom caps each ticket type at 50 attributes — don't copy every Custom Issue Field one-for-one without planning. Drop fields with <5% population rate; they're noise in the new system.

**2. Export from Helpshift.** Use the `GET /issues` endpoint with `page-size=1000` and iterate through all pages. Include the `meta` parameter to capture custom metadata. For user data, use the User Hub Bulk Export API. Download all attachments during export — Helpshift attachment URLs require authentication and will dead-end within days if you just store the URL strings. Export produces JSON; validate the schema against your target Intercom attribute definitions before writing your transformation layer.

**3. Build the identity map.** Match Helpshift user profiles to Intercom contacts using the strongest shared identifier: email → external_id → internal user ID. Helpshift users are identified by `device_id` or SDK user identifiers; Intercom contacts require `email` or `external_id`. A single person on two devices may appear as two Helpshift profiles. Flag any profiles without a matching email — these need manual resolution or a fallback mapping strategy. Profiles on older SDK versions (7.x and below) may have only device ID and custom identifier; map these to `external_id` with a `hs_device_` prefix to preserve traceability.

**4. Create Intercom contacts.** Use the Contacts API to create or update contact records. Intercom deduplicates on email and external_id. To avoid duplicates: check for existing records by email before creating. If a record exists, update it with `PATCH /contacts/{id}` rather than creating a new one. Map Helpshift device telemetry data to the Custom Attributes you created in step 1.

**5. Import conversations with backdated timestamps.** Use the Conversations API to create conversations linked to the correct contact. Map Helpshift issue messages to Intercom conversation parts — the first message must be set as the initiator, with subsequent messages posted as replies. **You must explicitly pass the original `created_at` Unix timestamp** in your API payload. If you skip this, every historical Helpshift issue will appear in Intercom as if it was created on migration day, destroying your SLA reporting and analytics. Intercom accepts backdated timestamps via the `created_at` field in the API; this is not documented prominently but is supported in API v2.15.

**6. Handle attachments properly.** Helpshift stores attachments with authenticated URLs. You must programmatically download every attachment from Helpshift, stage it temporarily (e.g., on an AWS S3 bucket with a short-lived presigned URL), and push it to Intercom via the `/messages` endpoint as a native file block. If you map Helpshift attachment URLs directly into Intercom text fields, those links will break within days.

**7. Import help center content.** Export Helpshift FAQs and restructure into Intercom's Articles format with collections. FAQ content exports from Helpshift as JSON; Intercom's Articles API accepts HTML body content. This is usually the cleanest part of the migration.

**8. Rebuild automations.** Helpshift bot flows and automation rules have no export format compatible with Intercom Workflows or Fin. Document your current Helpshift bot logic — input triggers, branch conditions, custom field reads, output actions — before decommissioning. Use that documentation as the spec for Workflow rebuilds. Prioritize by traffic volume: rebuild high-traffic flows first and validate in a staging workspace before cutover.

**9. Use webhooks to close the live-data gap.** Configure Helpshift webhooks to capture issues created after your extraction snapshot. Replay these into Intercom during the cutover window. This prevents the "issues created during migration" gap that otherwise requires manual reconciliation.

**10. Validate.** Run conversation counts, spot-check message threading, verify attachment accessibility, and confirm identity mapping accuracy. A 5% sample audit is the minimum; audit 10% on larger migrations. Check specifically for:
- **Identity collisions:** the same person should not become two records because one system used email and the other used a device ID
- **Open-state continuity:** every open or pending case in Helpshift must exist in an actionable state in Intercom
- **Attachment accessibility:** confirm files are reachable via authenticated Intercom URLs, not dead external links
- **Reporting sanity:** trend lines matter more than pixel-perfect metric matching, because Intercom conversations and Helpshift issues are not the same object model
- **Silent field drops:** read back 100 imported conversations and verify custom attributes are populated — Intercom will not error on unmapped fields, it will simply omit them

**Timeline expectations:** For a dataset of 500,000 issues with attachments, expect 10–20 days of extraction (respecting rate limits), 3–5 days of transformation and identity mapping, 5–10 days of import (respecting Intercom rate limits at 10,000 calls/min), and a 5–7 day parallel-run period where both systems are live before full cutover. Total: 3–6 weeks minimum for a clean migration at that scale.

## Migration: Intercom to Helpshift

Less common, but it happens when a web-first company pivots to mobile-only or a gaming studio consolidates onto Helpshift after previously using Intercom for web support.

### What Migrates

| Intercom Object | Helpshift Target | Complexity |
|---|---|---|
| Conversations + parts | Issues + messages | High — structural mismatch |
| Contacts | User profiles | High — identity model is different |
| Articles | FAQs | Low-Medium |
| Tags | Tags/Labels | Low |
| Custom attributes | Custom metadata | Medium — field type constraints |
| Companies | No direct equivalent | Data loss — flatten to custom fields |
| Tickets | Issues | Medium |
| Fin/Workflow configs | Bot flows | No migration path — rebuild |

### Key Challenges

**Segmenting continuous threads.** Intercom conversations can be long-running threads that span multiple distinct support inquiries over months. Helpshift's model expects discrete issues. If you migrate a massive Intercom thread into a single Helpshift issue, it becomes unreadable in the agent dashboard. You must script logic to split Intercom conversations based on time-gaps — a 14-day gap between messages in an Intercom thread is a reasonable heuristic for treating it as a new Helpshift Issue. Apply this consistently: scan each conversation's parts array for gaps exceeding your threshold and emit a new Issue record at each break point.

**Company data loss.** Intercom's first-class Company objects — with their own attributes, segments, and contact associations — have no equivalent in Helpshift. You'll need to flatten company data into custom issue metadata or user profile fields. Concretely: create a Helpshift Custom Issue Field called `company_name` (Single Line Text) and `company_id` (Single Line Text), populate them from the Intercom Company object on each conversation, and accept that the relational structure — multiple contacts belonging to one company, company-level segments, company MRR attributes — is lost. There is no lossless migration path for Intercom Company data into Helpshift.

**Stripping HTML and rich text.** Intercom allows rich text formatting, inline images, and complex block elements in its messages. Helpshift's interface is optimized for plain text mobile chat. When pushing data into Helpshift's API, you must sanitize the payload: strip complex HTML using a library like BeautifulSoup (Python) or Cheerio (Node.js), convert inline images to external links, and flatten the text structure. If you push raw Intercom HTML into Helpshift, the mobile SDK will render raw markup to your end users.

**File URL expiration.** When exporting from Intercom, user-uploaded file URLs expire after 30 minutes. Your export script must download every attachment inline during the conversation fetch. If you're exporting 100,000+ conversations, pipeline your downloads — don't batch them after the full export completes or you'll find that most URLs are already expired.

**Identity mapping in reverse.** Intercom contacts are email-first. Helpshift users are device-first. You'll need to create Helpshift user profiles via the User Hub Bulk Import API (JSON, up to 10,000 payloads per request), mapping Intercom's `email` and `external_id` to Helpshift's `uid` and email fields. Then link imported Issues to those profiles using the Create Issue API.

**Field type constraints.** Helpshift's Custom Issue Fields are limited to six types: Date, Checkbox, Drop-down, Single Line Text, Multi Line Text, and Number. Invalid or archived field keys are **silently dropped** — no error is returned. Free-form Intercom ticket attributes, rich text fields, and array-type attributes may not transfer cleanly. Map every Intercom attribute to a Helpshift field type before import; reject fields that have no valid mapping rather than silently losing data.

**Bot rebuild scope.** A typical Intercom Workflow with 20–30 nodes maps to a Helpshift bot flow of roughly equivalent complexity — but the builder paradigms are different enough that direct translation isn't possible. Intercom Workflows support API Actions natively; Helpshift bots rely on webhook callbacks for custom logic. Any Workflow that calls an external API via Action blocks will require webhook infrastructure on the Helpshift side.

For a deeper dive on exporting data from Helpshift, see our guide on [how to export data from Helpshift](https://clonepartner.com/blog/blog/how-to-export-data-from-helpshift-api-limits-methods-portability/).

## Compliance, Data Residency, and Security

| Requirement | Intercom | Helpshift |
|---|---|---|
| **GDPR** | Yes — EU data hosting available | Yes |
| **HIPAA** | Expert plan only | Not documented as a standard offering |
| **SOC 2** | Yes (Type II) | Yes |
| **COPPA** | No specific tooling | `fullPrivacy` SDK flag prevents PII collection for users 13 and under |
| **Data residency** | US, EU, AU hosting options (Advanced/Expert for new workspaces) | US-hosted (AWS); no comparable public regional-hosting program |
| **SSO** | SAML on Expert plan | Available on Enterprise |
| **Webhooks (compliance events)** | Supported — conversation and contact events | Supported — issue lifecycle events |

If you're in gaming or building apps for younger audiences, Helpshift's COPPA compliance tooling — the `fullPrivacy` flag that strips mobile country code, carrier, and custom PII from SDK sessions — is purpose-built and has no real Intercom equivalent.

If you're in healthcare or financial services and need HIPAA, Intercom's Expert plan is the only option between these two.

**Data residency can make the decision for you.** Intercom publicly documents US, EU, and Australia hosting options, though regional hosting is only available for Advanced and Expert new contract workspaces — and moving regions means creating a new workspace, not flipping a switch. Historical conversation data cannot be migrated between regional workspaces; it must be exported before the move. Helpshift's public sub-processor list states that AWS hosts all production data and systems in the USA. If EU-local processing or data sovereignty is a hard requirement, you may need to evaluate self-hosted options like [Zammad](https://clonepartner.com/blog/blog/zammad-vs-helpshift-architecture-tco-migration-guide/) or get the exact answer in the Helpshift order form before signing — this is not covered by their standard documentation.

For teams concerned about Intercom's data residency post-Salesforce acquisition, see our [Intercom EU Data Hosting guide](https://clonepartner.com/blog/blog/intercom-eu-data-hosting-trap-the-us-to-eu-migration-guide/).

## When to Pick Intercom

- Your primary support channel is **web chat or email**, not in-app mobile messaging
- You need **CRM-grade contact and company data** with relational attributes
- You want **AI-first resolution** as the core of your support motion
- You need deep **native integration with Salesforce or HubSpot** — Intercom's native Salesforce connector handles bi-directional contact and conversation sync without middleware (if your CRM is Keap or ActiveCampaign, see our [FuseDesk vs Helpshift guide](https://clonepartner.com/blog/blog/fusedesk-vs-helpshift-2026-architecture-tco-migration-guide/)); Helpshift requires iPaaS or custom webhooks
- You're scaling a **B2B SaaS** operation where account-level context (company MRR, plan, usage) matters per conversation
- You need **HIPAA compliance**
- You need **EU or Australia data residency**

## When to Pick Helpshift

- Your primary support channel is **in-app messaging** inside a mobile or gaming app
- You need **native SDKs** for Unity, Unreal Engine, iOS, Android, or PC
- You operate at **high issue volume** where per-seat pricing would be punitive — at 50+ agents and 30,000+ issues/month, Helpshift's seat-free model is typically cheaper by a material margin
- You need **device-level telemetry** (carrier, network type, OS version, battery level) automatically captured in every support interaction
- You need **COPPA compliance** tooling — the `fullPrivacy` flag is the only production-ready solution between these two platforms for apps with under-13 users
- Your support includes **console gaming** and you need QR-based access
- You need to unify support, engagement, trust & safety, and community for a gaming operation
- **Salesforce acquisition uncertainty** is a procurement concern — Helpshift operates independently with no pending ownership change

## What the Salesforce Acquisition Means for This Decision

Salesforce signed the agreement to acquire Fin (Intercom) on June 15, 2026, for approximately $3.6 billion. The deal is pending regulatory approval. In the short term, nothing changes — pricing, APIs, and product behavior remain the same.

If you're signing a multi-year Intercom contract today, address these points explicitly in negotiations:

- **Price-protection clauses:** Salesforce acquisitions have historically been followed by pricing increases at renewal. Request contractual price caps for the duration of the term.
- **Roadmap specificity:** Salesforce's Agentforce platform overlaps functionally with Fin. Get in writing which Intercom-specific capabilities are on the committed roadmap vs. subject to change post-acquisition.
- **Data portability rights:** Ensure your contract explicitly grants the right to export all conversation data, contact data, and article content in machine-readable format (JSON/CSV) at any time, not just at contract termination.
- **Product definition language:** Specify that your contract covers access to "Intercom" as a standalone product. If Intercom features are folded into Salesforce Service Cloud and sold as a bundle, you want clarity on what that means for your pricing and access rights.
- **Current Salesforce integration:** As of mid-2026, Intercom's native Salesforce connector syncs contacts/leads and conversation data bi-directionally. Post-acquisition integration depth is expected to increase but no specific product commitments have been announced. Don't buy Intercom today primarily because of anticipated deeper Salesforce integration — buy it for what exists now.

Helpshift is unaffected by this acquisition and continues to operate independently. If platform ownership stability is a procurement criterion, that's a real and current differentiator.

## Making the Migration Happen

There's no native migration path between Intercom and Helpshift in either direction. Every production migration requires custom API scripting, identity reconciliation, and data transformation. The mismatch between Intercom's email-first contact model and Helpshift's device-first user profiles is the single hardest technical challenge — everything else (rate limits, attachment handling, field mapping) is engineering work; identity reconciliation is a data integrity problem that can't be scripted away.

The pattern is consistent across migrations at any scale: **extract → transform → identity map → import → validate → close the live-data gap → cutover**. The specifics — managing Intercom's 30-minute file URL expiration, Helpshift's 100-page API cap, the one-year archival window, silent field drops on invalid keys, conversation-part limits at 500, and timestamp backdating — are where the work actually lives.

If you're evaluating the broader Intercom landscape, our [guide to mastering Intercom in 2026](https://clonepartner.com/blog/blog/ultimate-guide-Intercom-2026/) covers the platform's AI, workflows, and data model in depth.

> **Planning a migration between Intercom and Helpshift?** Our engineering team handles the full pipeline: export, identity mapping, data transformation, import, and validation. Book a 30-minute call and we'll scope it live.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Is Intercom or Helpshift better for mobile game support?

Helpshift is purpose-built for mobile gaming with native SDKs for Unity, Unreal Engine, iOS, and Android, plus device telemetry, COPPA compliance, and console QR-based access. Intercom can embed a Messenger widget in mobile apps but lacks deep SDK integration, device-level telemetry, and gaming-specific features like player identity graphs.

### How much does Intercom cost compared to Helpshift?

Intercom charges $29–$132 per seat/month (annual billing) plus $0.99 per Fin AI resolution. Helpshift starts at $150/month for 250 issues with no per-seat fee — overage is $0.45/issue on the Starter plan. Growth and Enterprise tiers are custom-priced. For large agent teams with high volume, Helpshift's seat-free model can be significantly cheaper.

### Can I migrate data from Helpshift to Intercom?

Yes, but there's no native migration tool. You need custom scripts using both REST APIs. The hardest part is identity mapping — Helpshift uses device-based user profiles while Intercom uses email-first contacts. Issues map to conversations, attachments must be re-uploaded, timestamps must be backdated, and bot flows must be rebuilt from scratch.

### What are the API rate limits that affect migration?

Intercom allows 10,000 API calls per minute per private app and 25,000 per workspace, distributed across 10-second windows. Conversation retrieval returns a maximum of 500 parts, and file URLs expire after 30 minutes. Helpshift's rate limits are not publicly documented and are negotiated per-account — confirm with your Account Manager before building export scripts.

### What is the hardest part of an Intercom-to-Helpshift or Helpshift-to-Intercom migration?

Identity mapping. Intercom is built around email-first contacts and company objects. Helpshift is built around device-first user profiles, app profiles, and gaming platform IDs. Reconciling these identity models — plus handling attachment re-hosting, timestamp backdating, and field type constraints — is where the real engineering work lives.