Helpdesk migration
Field-level mapping, validation, and rollback between UserEcho and Intercom. We move data and schema; workflows are rebuilt natively in Intercom.
UserEcho
Source
Intercom
Destination
Compatibility
8 of 11
objects map 1:1 between UserEcho and Intercom.
Complexity
CModerate
Timeline
2-4 weeks
Overview
UserEcho bundles four modules under one account EchoDesk, EchoForum, EchoSmart, and EchoChat each with its own data structure. Intercom uses a unified Conversation model for tickets and chats, a separate Help Center for articles, and Custom Objects with Data Connectors for non-standard data. We extract each UserEcho module separately, route EchoDesk tickets and EchoChat sessions into Intercom Conversations, convert EchoForum topics to Intercom Articles in Ideas format, migrate EchoSmart articles to the Help Center, and separate end-user profiles from agent seats to avoid inflating Intercom admin billing. UserEcho has no native bulk export endpoint, so we pull data through its API where available and supplement with UI endpoint access. Workflows, automations, and the EchoForum voting scoreboard do not migrate; we deliver a written inventory for your admin to rebuild or reconfigure in Intercom.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a UserEcho object lands in Intercom, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
UserEcho
EchoDesk Tickets
Intercom
Conversation (Ticket type)
1:1EchoDesk tickets carry status (open, pending, resolved, closed), priority, assignee, custom fields, and full reply threads. We extract the complete conversation history and reconstruct each thread in Intercom as a Conversation with message parts tagged by author (agent vs customer). EchoDesk status maps to Intercom conversation_state (open, resolved). Custom fields on EchoDesk tickets become custom attributes on the Intercom conversation.
UserEcho
EchoChat Sessions
Intercom
Conversation (Chat source tag)
1:1EchoChat transcripts include message text, timestamps, agent ID, visitor identifier, and open or closed status. We convert each session into an Intercom Conversation tagged with source=chat in the conversation part metadata. Agent and visitor identifiers are preserved as contact and teammate references. Closed status maps to Intercom's conversation_state=resolved.
UserEcho
EchoForum Topics
Intercom
Article (Ideas type)
1:manyEchoForum topics include vote counts, status tags (planned, under review, completed, declined), title, body, and nested comment threads. We map topics to Intercom Articles with article_type=ideas. Vote scores are preserved in a custom attribute echoforum_votes__c since Intercom Ideas does not have a native vote count field. Comment threads migrate as threaded article comments. The EchoForum status becomes a custom field echoed_status__c for admin workflow rebuilding.
UserEcho
EchoSmart Articles
Intercom
Article (Help Center)
1:1EchoSmart articles have publication status, two-level category assignments, and attachment references. We export article title, body (HTML), category hierarchy, and parent-child relationships. In Intercom, articles are created as Help Center articles inside Collections. Inline images are downloaded and re-uploaded to Intercom's image host to avoid broken image links post-migration.
UserEcho
UserEcho Users (Agents)
Intercom
Admin or Teammate
1:1UserEcho agent profiles (users with moderation or helpdesk access) map to Intercom Admins and Teammates. We export display_name, email, and role flag. Agent email becomes the Intercom teammate identifier. Active agent count at migration time is scoped against Intercom's admin seat billing to avoid inflated subscription costs.
UserEcho
UserEcho Users (End-users)
Intercom
Contact
1:1UserEcho end-user profiles map to Intercom Contacts. We export email address, display name, and any associated custom fields. Unsubscribed status from UserEcho maps to Intercom's unsubscribed_from_emails flag. Activity counts (ticket count, forum post count) from UserEcho become custom contact attributes for segmentation.
UserEcho
EchoDesk Categories
Intercom
Collection
lossyEchoDesk category taxonomy is two-level (parent and child). We preserve the hierarchy during extraction and map it to Intercom Collections with Sections inside. The customer chooses whether to create separate Collections per product line or a single Collection with Section-based separation.
UserEcho
EchoForum Categories
Intercom
Collection
lossyEchoForum categories are separate from EchoDesk categories in UserEcho even though the platform shares a user table. We route forum categories to a distinct Intercom Collection used for ideas and feedback content, separate from the help center collection.
UserEcho
Tags
Intercom
Tag
1:1Tags applied across EchoDesk tickets, EchoForum topics, and EchoSmart articles are exported as a flat list with their object associations. In Intercom, tags are recreated as labels on the corresponding Conversation or Article. Tag-object associations migrate as tag assignments on the target object.
UserEcho
Attachments
Intercom
Attachment
1:1Files attached to tickets, KB articles, and forum posts are downloaded individually with original filenames and MIME types preserved. We re-upload each file to Intercom's attachment endpoint linked to the corresponding Conversation or Article. Inline images embedded in EchoSmart article HTML are extracted and re-hosted in Intercom's media library to prevent broken image rendering.
UserEcho
EchoForum Comments
Intercom
Article Comment
1:1EchoForum nested comment threads are extracted in tree order and flattened into Intercom article comments under the parent topic article. Comment author (agent or customer) and created_at timestamp are preserved. Deeply nested comment trees beyond three levels are flattened with an indent indicator in the comment body to preserve readability.
| UserEcho | Intercom | Compatibility | |
|---|---|---|---|
| EchoDesk Tickets | Conversation (Ticket type)1:1 | Fully supported | |
| EchoChat Sessions | Conversation (Chat source tag)1:1 | Fully supported | |
| EchoForum Topics | Article (Ideas type)1:many | Fully supported | |
| EchoSmart Articles | Article (Help Center)1:1 | Fully supported | |
| UserEcho Users (Agents) | Admin or Teammate1:1 | Fully supported | |
| UserEcho Users (End-users) | Contact1:1 | Fully supported | |
| EchoDesk Categories | Collectionlossy | Fully supported | |
| EchoForum Categories | Collectionlossy | Fully supported | |
| Tags | Tag1:1 | Mapping required | |
| Attachments | Attachment1:1 | Mapping required | |
| EchoForum Comments | Article Comment1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
UserEcho gotchas
No native bulk data export capability
Per-agent billing with no free tier for full features
Multiple product names create confusion for data separation
Trial auto-downgrade to limited free plan
Intercom gotchas
S3 JSON export omits conversation transcripts
Workspace isolation prevents workflow migration
Fin AI resolution fees compound with automation success
Two-year conversation history limit on historical export
Private app rate limits share workspace quota
Pair-specific challenges
Migration approach
Account tier verification and module inventory
We confirm the active UserEcho plan tier and verify which modules are enabled (EchoDesk, EchoForum, EchoSmart, EchoChat). If the account has downgraded to the free tier during a trial period, we flag any data that requires a paid feature to access. We inventory all custom fields across enabled modules, category structures, and attachment volume to scope extraction complexity and timeline.
Multi-module data extraction
We extract data from each UserEcho module separately since there is no unified export. EchoDesk tickets with full reply threads are pulled via API where available. EchoChat transcripts, EchoForum topics with vote counts and nested comments, and EchoSmart articles with category hierarchy are each extracted as discrete datasets. Attachments are downloaded individually with filename and MIME type preserved. Inline images in KB articles are extracted for re-upload to Intercom's media host.
Intercom workspace provisioning and schema setup
We provision the Intercom workspace and configure the target schema before importing data. This includes creating Collections and Sections for the Knowledge Center, setting up Article types for Ideas (EchoForum) and Help Center (EchoSmart), and defining custom conversation attributes to receive migrated EchoDesk custom fields and EchoForum vote scores. If Custom Objects are required for non-standard data, we create the object schema with Data Connectors before any record import.
UserEcho user role separation and agent seat scoping
We parse the UserEcho user table to separate agents from end-users. Agent profiles are routed to Intercom Admins and Teammates; end-user profiles are routed to Intercom Contacts. We provide the agent seat count to the customer for Intercom billing provisioning before record import begins. Any UserEcho owner records without email matches in the destination are held in a reconciliation queue for manual provisioning.
Record import in dependency order with delta sync
We import data into Intercom in dependency order: Contacts first, then Admins and Teammates, then Conversations (tickets and chat sessions), then Articles (Ideas followed by Help Center). Tags are imported as object associations after their parent records are committed. Attachments are re-uploaded to Intercom after their parent conversations or articles are created. A delta migration captures any records created or modified during the migration window before cutover.
Cutover, validation, and automation rebuild handoff
We freeze new UserEcho writes during cutover, run the final delta migration, then enable Intercom as the system of record. We deliver a written inventory of EchoDesk routing rules, EchoForum status workflows, and any automation configurations requiring rebuild in Intercom Rules or Fin AI procedures. We do not rebuild automations as Intercom workflows within the migration scope; that work is handled by the customer's admin team or a follow-on engagement.
Platform deep dives
UserEcho
Source
Strengths
Weaknesses
Intercom
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across UserEcho and Intercom.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
UserEcho: Not publicly documented.
Data volume sensitivity
UserEcho doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during UserEcho to Intercom migration scoping. Not seeing yours? Book a call.
Walk through your UserEcho to Intercom migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave UserEcho
Other ways to arrive at Intercom
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.