Helpdesk migration
Field-level mapping, validation, and rollback between Aritic Desk and Intercom. We move data and schema; workflows are rebuilt natively in Intercom.
Aritic Desk
Source
Intercom
Destination
Compatibility
12 of 12
objects map 1:1 between Aritic Desk and Intercom.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from Aritic Desk to Intercom is a migration from ticket-centric support to conversation-centric messaging. Aritic Desk structures support around Tickets, Customers, Organizations, and Agents with SLA and CSAT tracking; Intercom uses Conversations, Users, Contacts, Teams, and Articles with AI-powered routing and outbound messaging. The structural difference that most affects migration is that Aritic Desk tickets map to Intercom conversations, but Aritic Desk response threads do not automatically map to Intercom message parts without custom sequencing logic. We extract the Aritic Desk native export or perform database extraction for self-hosted instances, transform ticket threads into Intercom conversation parts, and land Users and Contacts with their organization relationships intact. Macros migrate as plain-text templates with Aritic-specific tokens stripped. SLAs, Triggers, Automations, CSAT surveys, and Reports do not migrate as code; we deliver a written inventory for the customer's team to rebuild in Intercom's workflow builder.
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 Aritic Desk 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.
Aritic Desk
Ticket
Intercom
Conversation
1:1Aritic Desk Tickets migrate to Intercom Conversations with ticket ID preserved as a custom conversation attribute for cross-reference. Ticket subject becomes the conversation title. Ticket description becomes the first conversation part. Status (Open, Pending, Resolved, Closed) maps to Intercom's conversation state model with a custom status__c attribute retaining the original Aritic Desk status label. Priority and ticket type migrate as conversation tags. Response threads from Aritic Desk are reconstructed as sequential conversation parts with timestamps and author attribution preserved.
Aritic Desk
Customer
Intercom
Contact or Lead
1:1Aritic Desk Customers map to Intercom Contacts. The customer email, name, phone, and custom properties migrate directly. If the Aritic Desk Customer has no associated Organization, the record lands as a standalone Intercom Contact. Lifecycle or status flags from Aritic Desk migrate as custom attributes. We map the Aritic Desk customer ID to a custom contact attribute aritic_id__c for reconciliation.
Aritic Desk
Organization
Intercom
Company
1:1Aritic Desk Organizations map to Intercom Companies. Organization name, domain, industry, and size tier migrate. The link between Customer records and their parent Organization is preserved by attaching each migrated Contact to the corresponding Intercom Company via the company_id relationship. The Aritic Desk organization ID is stored as company_id__c for reconciliation.
Aritic Desk
Agent
Intercom
Team Member (User)
1:1Aritic Desk Agents migrate to Intercom Team Members. Agent name and email map directly; role (Admin, Agent) determines Intercom inbox assignment permissions. We map agent IDs to Intercom user records and flag any custom permission profiles that may require manual reconfiguration in Intercom's permission settings. Active and inactive status from Aritic Desk is preserved.
Aritic Desk
Knowledge Base Category
Intercom
Collection
1:1Aritic Desk KB Categories map to Intercom Collections. The category name, description, and default publish state migrate. Parent-child relationships between Categories in Aritic Desk are preserved as top-level Collection structure in Intercom. Locale and language settings from Aritic Desk migrate as Collection metadata.
Aritic Desk
Knowledge Base Section
Intercom
Section
1:1Aritic Desk KB Sections map to Intercom Sections nested within the parent Collection. The section name and order within category migrate. If Aritic Desk allows articles without a parent section, we assign those articles to a default section within the destination Collection and flag them for manual reorganization.
Aritic Desk
Knowledge Base Article
Intercom
Article
1:1Aritic Desk KB Articles map to Intercom Articles within the corresponding Section. Article title, body content, author, and creation date migrate. We strip Aritic-specific dynamic tokens and conditional content blocks used for personalization and flag each affected article for the customer's knowledge base team to review and restore personalization using Intercom's equivalent mechanism. Publish status migrates as draft or published.
Aritic Desk
Macro
Intercom
Saved Content (manual rebuild required)
1:1Aritic Desk Macros are text templates with dynamic placeholders like {{ticket.customer_name}} and {{ticket.id}}. We extract macro content as plain text and flag every macro with Aritic-specific tokens that require manual review and repopulation in Intercom's Saved Content feature using Intercom's {{requester.name}} and conversation variables. Macros with conditional logic based on Aritic-specific field names are documented separately for workflow rebuild.
Aritic Desk
SLA Policy
Intercom
SLA (documented, not migrated)
1:1Aritic Desk SLA policies (first response time, resolution time) and SLA schedules migrate as structured metadata documentation. Intercom's SLA configuration is platform-native and cannot be programmatically populated via its documented API. We deliver a written inventory of each Aritic Desk SLA with its thresholds, business hours, and applicable ticket filters, plus the recommended Intercom SLA equivalent settings for the customer's admin to configure post-migration.
Aritic Desk
CSAT Survey Response
Intercom
Conversation Rating (custom attribute)
1:1Aritic Desk CSAT scores linked to ticket records migrate with rating value, respondent email, and ticket reference preserved as custom conversation attributes. Intercom's native Conversation Rating feature captures post-resolution satisfaction independently; migrated CSAT responses land as historical data attributes rather than native ratings to avoid duplicating the survey trigger.
Aritic Desk
Attachment
Intercom
Attachment
1:1File attachments on Aritic Desk tickets and KB articles are extracted and uploaded to Intercom's file storage via the Intercom API. We flag files exceeding Intercom's size limit or unsupported file types for manual handling. Image attachments migrate with the original URL preserved as a reference attribute.
Aritic Desk
Tag
Intercom
Tag
1:1Tags applied to tickets and customers in Aritic Desk migrate as flat label arrays attached to the corresponding Intercom Conversation or Contact. We verify tag character encoding compatibility. Tag taxonomy and organizational hierarchy from Aritic Desk (if any) is preserved as a tag prefix convention in Intercom.
| Aritic Desk | Intercom | Compatibility | |
|---|---|---|---|
| Ticket | Conversation1:1 | Fully supported | |
| Customer | Contact or Lead1:1 | Fully supported | |
| Organization | Company1:1 | Fully supported | |
| Agent | Team Member (User)1:1 | Fully supported | |
| Knowledge Base Category | Collection1:1 | Fully supported | |
| Knowledge Base Section | Section1:1 | Fully supported | |
| Knowledge Base Article | Article1:1 | Fully supported | |
| Macro | Saved Content (manual rebuild required)1:1 | Fully supported | |
| SLA Policy | SLA (documented, not migrated)1:1 | Fully supported | |
| CSAT Survey Response | Conversation Rating (custom attribute)1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Tag | Tag1: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.
Aritic Desk gotchas
No public REST API for programmatic data extraction
Agent-seat billing model is migration-critical
Macros and triggers contain Aritic-specific dynamic tokens
KB articles may embed macros and dynamic content
Limited third-party integration ecosystem
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 export feasibility assessment
We audit the Aritic Desk instance for object counts (tickets, customers, organizations, agents, KB articles), active integrations, macros, SLA policies, triggers, and CSAT surveys. We confirm whether the instance is cloud-hosted (native export available) or self-hosted (database extraction required). If self-hosted, the customer provisions read-only database credentials. We document the full object inventory and flag any objects requiring manual extraction or rebuild. The discovery output is a written migration scope and export plan.
Data extraction and transformation
We extract data from Aritic Desk using the confirmed method (native export or database query). For self-hosted instances, we run targeted SQL queries against the Aritic Desk database to pull Tickets, Customers, Organizations, Agents, KB Categories, Sections, Articles, Macros, SLA policies, CSAT responses, and attachments. We transform each object into Intercom's API schema: Tickets to Conversations with thread reconstruction, Customers to Contacts, Organizations to Companies, Agents to Team Members, KB hierarchy to Collections, Sections, and Articles. Aritic-specific dynamic tokens in macros and KB articles are stripped and flagged. The transformation output is a set of staged JSON and CSV files ready for Intercom API ingestion.
Sandbox validation in Intercom
We run a sandbox migration into an Intercom test workspace using a representative sample of records (typically 50-100 tickets, 25-50 contacts, 10-20 KB articles). We validate that conversation threading reconstructs correctly, that contacts attach to the correct companies, that agents receive the correct inbox assignments, and that KB articles land under the correct collections and sections. The customer's team reviews the sandbox output and signs off before production migration. Any mapping corrections are applied to the transformation scripts before production runs.
Production migration in dependency order
We migrate into the production Intercom workspace in dependency order: Collections and Sections first (articles reference them), then Articles, then Companies, then Contacts with company links, then Team Members, then Conversations with message history, then attachments, then tags and custom attributes. CSAT responses land as conversation metadata after the conversation itself is created. Macros are delivered as a plain-text template inventory document rather than created in Intercom. Each phase emits a row-count reconciliation report. We handle Intercom API rate limits with exponential backoff and batch chunking.
Cutover, final validation, and automation rebuild handoff
We perform a final delta migration of any records modified during the migration window, then enable Intercom as the active system of record. We deliver the SLA inventory, macro inventory, trigger and automation documentation, and CSAT mapping document to the customer's team. We support a 72-hour hypercare window for reconciliation issues. We do not configure Fin AI Agent, rebuild workflows, or configure messenger styling as part of the standard migration scope; these are separate engagements.
Platform deep dives
Aritic Desk
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 Aritic Desk 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
Aritic Desk: Not publicly documented.
Data volume sensitivity
Aritic Desk 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 Aritic Desk to Intercom migration scoping. Not seeing yours? Book a call.
Walk through your Aritic Desk 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 Aritic Desk
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.