Migrate from Gladly to Gorgias

Gladly Customer Profiles map directly to Gorgias Customers by email address as the primary dedupe key. A critical migration risk is Gladly's profile merge behavior: when two profiles are merged, the absorbed Customer ID 301-redirects to the survivor, but the Work Sessions Report retains the old ID. We export both current and historical Customer IDs for every profile and store the original Gladly Customer ID in Gorgias external_id. We also write the historical ID as a custom string field gladly_legacy_customer_id__c on the Gorgias Customer record so that any reporting or integration referencing the old ID resolves correctly.

This is the core architectural conversion. Gladly enforces one open Conversation per Customer at any time; Gorgias creates discrete Tickets for each issue or channel interaction. We split each Gladly Conversation into one or more Gorgias Tickets based on the following logic: if a Conversation has multiple channel interactions (e.g., email followed by chat) we create separate Tickets by channel; if a Conversation covers multiple issue types identified by Topic labels, we create separate Tickets by Topic. The full message history within each original Conversation migrates as messages on the corresponding Ticket. The customer should expect a higher ticket count in Gorgias than the original Conversation count in Gladly because multi-issue threads are disaggregated.

Every individual message across all channels within a Gladly Conversation (email, SMS, voice voicemail, chat, social) maps to a Gorgias Ticket Message. We preserve the channel metadata (email, chat, phone, social_channel) from Gladly in the message record. Voice call recordings and voicemail transcripts attach as message attachments. Agent attribution migrates by resolving the Gladly User email to the Gorgias User record. The message timestamp sets the Gorgias created_datetime on the message.

Gladly Topics are taggable labels applied to Conversations for routing and analytics. We export all Topic assignments and map them as Gorgias Tags on the corresponding Ticket. If a Gladly Conversation has multiple Topics, all tags are applied to the corresponding split Ticket. Tag names are preserved verbatim. The customer should confirm during scoping whether certain Topics should drive ticket routing rules in Gorgias, which requires the customer admin to configure Rules based on Tag after migration.

Gladly User records (name, email, role, permissions) map to Gorgias User records. We resolve by email match. Any Gladly User referenced on a Conversation or Conversation Item without a matching Gorgias User is held in a reconciliation queue; the customer's Gorgias admin provisions the User before that portion of the migration runs. Role mappings (Gladly Agent, Supervisor, Admin) map to Gorgias User roles and permission sets.

Gladly exports standard reports as CSV via UI or API. The Work Sessions Report retains old Customer IDs after profile merges. We pull CSV exports for CSAT, handle time, first response, and volume reports, and map the customer identifiers to the new Gorgias Customer records. Aggregated metrics (CSAT scores, handle time averages) are migrated as read-only custom fields on the Gorgias Customer or as metadata notes on individual Tickets. Raw volume data requires a data warehouse or reporting tool beyond Gorgias's native analytics.

Gladly Answers articles, categories, and help center structure are exported as structured content. We deliver the article HTML, category hierarchy, and metadata as a written specification for the customer to import into Gorgias Help Center. Gladly's AI-generated response templates do not migrate; Gorgias AI Agent learns from the Help Center articles at setup, which is a customer-admin task. We do not rebuild Gladly Answers as Gorgias Help Center articles as code; we deliver the content and structure for manual import.

Gladly Workflows encode routing logic, spam filtering, required disclosures, and handoff rules as configuration-as-code with no bulk API export endpoint. We document every active Workflow during discovery: trigger conditions, routing rules, disclosure requirements, and SLA thresholds. We deliver a written Workflow inventory specifying the recommended Gorgias Rule or Macro equivalent for each. The customer's Gorgias admin or a consultant rebuilds the routing logic. Automations do not migrate as executable rules.

Gladly supports custom object definitions that store structured data linked to Customer Profiles or Conversations. We audit the customer's Gladly configuration for any custom objects during discovery. Custom object fields map to Gorgias Ticket meta fields (key-value JSON), custom Ticket fields (if the Gorgias plan supports them), or custom Customer fields depending on the object relationship. We pre-create the Gorgias schema before migration so that data lands in typed fields rather than unstructured notes.

Gladly exposes a webhook system with configurable events, retry policies, and ping events. We export the webhook endpoint URLs, event subscriptions, and payload configurations during discovery. The customer reconfigures these endpoints in Gorgias Settings > Webhooks after migration. We provide the full webhook specification (event types, payload structure) for reimplementation.

File attachments on Conversation Items (images, PDFs, voice recordings) migrate to Gorgias as Ticket attachments linked to the corresponding message. We preserve the original filename, MIME type, and size. Attachments are fetched from Gladly's media storage via API and uploaded to Gorgias during the message import phase. Large voice recording files may require extended migration time depending on volume.

Gladly CSAT survey responses attached to Conversations migrate to Gorgias as satisfaction_survey records on the corresponding Ticket. Survey scores, free-text responses, and agent attribution are preserved. If Gladly CSAT settings include custom questions, those are documented for the customer to reconfigure in Gorgias satisfaction survey settings.