Helpdesk migration
Field-level mapping, validation, and rollback between LiveHelpNow and Intercom. We move data and schema; workflows are rebuilt natively in Intercom.
LiveHelpNow
Source
Intercom
Destination
Compatibility
9 of 12
objects map 1:1 between LiveHelpNow and Intercom.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from LiveHelpNow to Intercom is a structural migration that reshapes how customer interactions are organized. LiveHelpNow separates chat conversations from support tickets and manages knowledge base articles in a flat category hierarchy; Intercom unifies all customer interactions into a single Conversations object with a nested Help Center structure of Collections, Sections, and Articles. We resolve that model difference during scoping, restructure the knowledge base hierarchy, and map LiveHelpNow ticket statuses to Intercom open, closed, and snoozed states. Agent profiles migrate as Operators with Team membership preserved. Canned response folders become Message Templates with category grouping. Survey configurations do not migrate as logic; we deliver a written inventory of every LiveHelpNow survey trigger and routing rule for your team to rebuild in Intercom's resolution flows. Chat bot configurations, workforce management scheduling, and automations are outside migration scope and are delivered as configuration inventories for your admin to rebuild.
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 LiveHelpNow 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.
LiveHelpNow
Conversations
Intercom
Conversations
1:1LiveHelpNow chat conversations map directly to Intercom Conversations. Each conversation's message thread migrates with full message content, customer identity, operator name, and timestamps preserved. We map LiveHelpNow operator names to Intercom Operator references by email match. Read/unread status at the conversation level becomes the conversation open state in Intercom. If the customer uses both chat conversations and ticketing in LiveHelpNow, we consolidate related chat-ticket pairs into single Intercom conversations.
LiveHelpNow
Tickets
Intercom
Conversations (Ticket-type)
1:1LiveHelpNow support tickets map to Intercom Conversations with a ticket-type designation. Ticket status (Open, Pending, Resolved, Closed) maps to Intercom conversation state (open, closed, snoozed). We preserve the original LiveHelpNow ticket ID as a custom attribute lhn_original_ticket_id__c for audit traceability. Ticket priority from LiveHelpNow maps to a custom conversation priority attribute since Intercom's standard model uses assignment and SLA rather than a standalone priority field.
LiveHelpNow
Knowledge Base Articles
Intercom
Help Center Articles
1:1LiveHelpNow KB articles migrate as Intercom Help Center articles. The article body, title, author, and timestamps transfer directly. We preserve the original LiveHelpNow article URL in a custom attribute lhn_original_article_url__c. Multi-section assignment in Intercom means articles can belong to more than one Section, which is an enhancement over LiveHelpNow's one-category-per-article model that we flag during scoping for the customer's editorial decision.
LiveHelpNow
KB Categories
Intercom
Collections and Sections
lossyLiveHelpNow's flat category hierarchy maps to Intercom's two-level Collections and Sections structure. We take the top-level LiveHelpNow categories as Intercom Collections and second-level categories as Sections. If the customer has a deeper LiveHelpNow category tree, we flatten the third level and below into Section names or article tags. This restructuring is a configuration decision that we document in a written hierarchy map before migration runs.
LiveHelpNow
Agents
Intercom
Operators
1:1LiveHelpNow agent profiles (name, email, role, queue assignment) map to Intercom Operators. Agent status (active/inactive) carries over. Queue assignments from LiveHelpNow workforce management become Intercom Team membership. We match operators by email against Intercom Operator accounts and flag any LiveHelpNow agent without a corresponding Intercom account for the customer admin to provision before the migration continues.
LiveHelpNow
Canned Responses
Intercom
Saved Replies
1:1LiveHelpNow canned response templates in agent-owned or shared folders migrate as Intercom Saved Replies. The response content and folder structure transfer, with shared folder templates becoming team-wide Saved Replies and agent-owned templates remaining individual Saved Replies. We preserve the original LHN canned response ID in a custom attribute lhn_canned_response_id__c for reference.
LiveHelpNow
Custom Ticket Fields
Intercom
Custom Attributes (on Conversation)
1:1LiveHelpNow custom fields on tickets require pre-creation in Intercom as custom attributes on the Conversation object. We extract the LiveHelpNow field schema (field name, type, options for picklists) during discovery, create matching Intercom custom attributes, then map field values during migration. Field types map as follows: text to string, number to number, date to date, picklist to single select, multi-select to multiple select. Custom attributes without a matching Intercom type are created as string and documented for potential refactoring.
LiveHelpNow
Chat Transcripts (Archived)
Intercom
Conversation Parts
1:1Historical chat transcript messages attach to the corresponding migrated Conversation as Conversation Parts, preserving the full message timeline and operator attribution. Message timestamps become part timestamps in Intercom. This is the most volume-intensive object in most LiveHelpNow migrations; we pace transcript imports using Intercom's API rate limits and batch processing to avoid throttling.
LiveHelpNow
Tags
Intercom
Tags
1:1Tags on LiveHelpNow tickets and knowledge base articles migrate as Intercom Tags. Tag names transfer directly. Intercom tags apply to contacts, companies, and conversations, which is broader than LiveHelpNow's application scope; we map ticket tags to conversation tags and KB article tags to article tags during migration.
LiveHelpNow
Social Channel Messages
Intercom
Conversations (via channel)
1:manyLiveHelpNow surfaces Facebook, Twitter, and other social channel messages as ticket-linked conversations. We extract the message content and link it to the corresponding migrated ticket. Social-channel-specific metadata (Twitter handle, Facebook page reference) is preserved as custom conversation attributes where Intercom's channel model supports it. This is a one-to-many split if the same social message thread touches multiple LiveHelpNow tickets.
LiveHelpNow
Surveys
Intercom
Custom Attributes (contact survey results)
1:1LiveHelpNow survey configurations (triggers, questions, routing rules) are platform settings and cannot migrate. We export survey response data—the submitted answers—as contact attributes in Intercom. Each survey question becomes a custom contact attribute, and the response value populates on the corresponding contact record. The customer rebuilds survey triggers as Intercom workflows post-migration.
LiveHelpNow
Workforce Management Data
Intercom
Team Configuration Inventory
lossyAgent scheduling, availability windows, and queue routing rules are LiveHelpNow workforce management settings that have no Intercom equivalent. We export these as a structured JSON inventory document and a written mapping to Intercom's operator availability settings and team inbox routing so the customer's admin can configure availability and team assignment post-migration.
| LiveHelpNow | Intercom | Compatibility | |
|---|---|---|---|
| Conversations | Conversations1:1 | Mapping required | |
| Tickets | Conversations (Ticket-type)1:1 | Fully supported | |
| Knowledge Base Articles | Help Center Articles1:1 | Fully supported | |
| KB Categories | Collections and Sectionslossy | Fully supported | |
| Agents | Operators1:1 | Fully supported | |
| Canned Responses | Saved Replies1:1 | Fully supported | |
| Custom Ticket Fields | Custom Attributes (on Conversation)1:1 | Mapping required | |
| Chat Transcripts (Archived) | Conversation Parts1:1 | Fully supported | |
| Tags | Tags1:1 | Mapping required | |
| Social Channel Messages | Conversations (via channel)1:many | Mapping required | |
| Surveys | Custom Attributes (contact survey results)1:1 | Mapping required | |
| Workforce Management Data | Team Configuration Inventorylossy | Mapping required |
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.
LiveHelpNow gotchas
Cloudflare infrastructure dependency causes silent service outages
API rate limits are not publicly documented
Survey configurations do not export as logic
Knowledge base article IDs do not persist across export/import
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
Discovery and Intercom workspace provisioning
We audit the source LiveHelpNow account across ticket volume, conversation history depth, knowledge base article count and category structure, agent count and team assignments, canned response library size, custom field schema, and active survey configurations. We pair this with an Intercom workspace assessment: Starter ($74/agent/mo) covers most LiveHelpNow migrations; Advanced adds custom inbound channels and reporting tiers; Enterprise adds multi-brand support and advanced SLA configuration. The discovery output is a written migration scope document covering record counts, knowledge base restructuring decisions, custom attribute schema design, and Intercom edition recommendation.
Knowledge base hierarchy restructuring design
We design the Intercom Help Center structure before migration begins. This includes mapping LiveHelpNow categories to Intercom Collections and Sections, deciding whether to flatten or preserve the existing category depth, and identifying articles that should belong to multiple Sections in Intercom. We also map the LiveHelpNow KB article body format (HTML or markdown) to Intercom's article editor format. This step produces a written hierarchy map and an article-to-section assignment plan that we validate with the customer's content team before migration runs.
Custom attribute schema creation in Intercom
We pre-create all custom attributes in Intercom before any data migration begins. This includes custom attributes on Contacts (from survey responses and social channel metadata), custom attributes on Conversations (from LiveHelpNow custom ticket fields and original ticket ID), and custom attributes on Companies if the customer uses company-level custom fields in LiveHelpNow. Intercom's attribute type system (string, number, date, boolean, list) must match the LiveHelpNow field types to avoid data type errors during import. We validate attribute creation in a test Intercom workspace before running production import.
Agent and team provisioning validation
We extract every distinct LiveHelpNow agent with their queue assignments and match by email against Intercom Operator accounts. Any agent without a corresponding Intercom account is held in a provisioning queue for the customer admin to create. Team assignments from LiveHelpNow queue configurations are mapped to Intercom Teams, which control inbox routing. Migration cannot proceed past conversation import until all referenced operators exist in Intercom because operator email is required on conversation attribution.
Knowledge base article migration and URL cross-reference
We run knowledge base migration first as the most stable object with no external dependencies. Articles migrate into their assigned Collections and Sections, preserving author, timestamps, and body content. We generate a cross-reference table mapping each LiveHelpNow article ID to its new Intercom article ID. The customer reviews a sample of 20-30 migrated articles for content fidelity before we proceed to conversation migration. Any formatting corrections are made to the source articles and re-imported before cutover.
Conversation and ticket migration in dependency order
We migrate conversations and tickets after knowledge base and operator provisioning are complete. We run closed tickets first (historical archive), then open tickets, then chat conversations. Each phase emits a row-count reconciliation report comparing LiveHelpNow record counts to Intercom record counts. Chat transcript messages are chunked into batches of 100-200 records per conversation to respect Intercom's API rate limits. Custom field values are mapped during this phase using the pre-created custom attributes from Step 3.
Canned response, tag, and survey data migration
Canned responses migrate as Saved Replies with folder structure preserved. Tags apply to the corresponding migrated conversations, contacts, and articles. Survey response data populates as contact custom attributes. Workforce management scheduling data is delivered as a structured JSON file with a written configuration guide for the customer's admin to implement in Intercom's operator availability settings. We do not migrate chat bot logic or survey triggers; these are delivered as written inventories for manual rebuild.
Cutover, validation, and bot rebuild handoff
We freeze LiveHelpNow writes during cutover, run a final delta migration of any records modified during the migration window, then hand over to the customer's team to configure Intercom's chat widget, enable Fin AI Agent, and set up operator availability. We deliver the bot logic inventory document and the survey trigger inventory document as separate files. We support a three-day hypercare window to resolve data reconciliation issues. Chat bot rebuilds, survey trigger rebuilds, and workflow configuration are outside standard migration scope and are documented as separate tasks for the customer's admin or an Intercom implementation partner.
Platform deep dives
LiveHelpNow
Source
Strengths
Weaknesses
Intercom
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 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 LiveHelpNow and Intercom.
Object compatibility
3 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
LiveHelpNow: Not publicly documented.
Data volume sensitivity
LiveHelpNow 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 LiveHelpNow to Intercom migration scoping. Not seeing yours? Book a call.
Walk through your LiveHelpNow 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 LiveHelpNow
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.