Migrate from Gladly to Intercom

Gladly Customer Profiles map to Intercom Contacts. Each profile carries a unique Customer ID with a unique email and unique mobile number. When Gladly profiles are merged, the absorbed profile's Customer ID performs a 301-redirect to the surviving ID, but Gladly's Work Sessions Report retains the old Customer ID. We export both the current and all historical Customer IDs for every profile and map the full conversation history to the surviving ID in Intercom to prevent orphaned agent handle-time data.

Gladly's hard architectural constraint — one open Conversation per Customer Profile — means each Gladly Conversation must split into one or more Intercom Conversations by topic or issue type when multiple distinct customer issues exist within a single thread. We design the split logic during scoping: each channel segment or topic-tagged segment becomes a separate Intercom Conversation attached to the mapped Contact. The customer must be briefed that this will increase the apparent ticket count in Intercom relative to Gladly's conversation count.

All Gladly Conversation Items — individual messages across email, SMS, voice call summaries, and chat — map to Intercom Conversation Parts. We preserve the original timestamp (external_created_at), channel metadata, and agent attribution. For voice items, the call summary and disposition text map to a note-style Conversation Part in Intercom. Recording URLs, if exported from Gladly, attach as file URLs in the relevant Conversation Part.

Gladly Topics (taggable labels applied to Conversations for routing and analytics) map to Intercom Tags. We export all Topic assignments per Conversation and apply them as corresponding tags on the split Intercom Conversation. Tag-based routing rules in Gladly do not migrate as automation; we document them for manual rebuild in Intercom's Workflow builder.

Gladly Workflows encode routing logic, spam filtering, required disclosure rules, and agent handoff as configuration rather than data records. There is no bulk API endpoint to export Workflow definitions. We audit and document every active Gladly Workflow during discovery and deliver a written Workflow specification — trigger, conditions, and actions — for the customer's Intercom admin to rebuild in Intercom's Workflow builder. This is a manual step that sits outside the data migration scope.

Gladly User records (name, email, role, and permissions) map to Intercom Admin records. We export all active and inactive users and match by email to the Intercom destination workspace. Any Gladly User without a matching Intercom Admin is placed in a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId references are required on Intercom Conversation assignments.

Gladly exports CSVs via UI and API for standard reports including Work Sessions, Conversation Volume, and Topic distribution. Intercom's reporting model differs in attribution logic, grouping, and metric definitions. We export available Gladly CSV reports and deliver them as-is to the customer for reference. Intercom reporting dashboards require manual rebuild by the customer's admin using Intercom's analytics tools. CSAT historical data migrates as a custom attribute on each Contact if available.

Gladly Answers articles with category hierarchy, metadata, and inline images map to Intercom's Help Center Articles. We export article content and category structure via Gladly's API and create Articles in Intercom's Help Center, preserving internal and external links. Images migrate as attachments. Multilingual content and translations migrate as separate article versions per locale. Note that AI-generated response rules native to Gladly Answers do not migrate; Fin AI in Intercom operates independently.

If the customer's Gladly instance uses custom objects (flagged during discovery), we audit the full source schema including all custom fields, data types, and lookup relationships. We pre-create the destination Intercom Custom Objects via Settings > Data > Custom Objects before any data import, matching field names and data types to Intercom's supported attribute types. Custom object data migrates after standard Contact and Conversation data because Custom Object definitions in Intercom may include Contact lookups that must resolve at insert time.

Gladly exposes a webhook system with configurable events, retry policies, and ping events. We export the webhook configuration (event types, target URLs, and payload templates) as a JSON document during discovery. Intercom's outbound webhook configuration differs in event model and payload structure. We deliver a written webhook inventory for the customer's admin to reconfigure in Intercom's Settings > Integrations > Webhooks post-migration. Active webhook integrations should be disabled on both ends during the migration window to prevent event delivery to stale endpoints.