The Definitive Guide to Migrating to Gorgias

Gorgias was founded in 2015 by Romain Lapeyre and Alex Plugaru and is headquartered in San Francisco, with engineering in Paris. It is an e-commerce-native helpdesk built around deep Shopify, BigCommerce and Magento integration, and reached an estimated $69M ARR in 2024 serving over 15,000 online merchants including Steve Madden, Glossier and BruMate.

The typical Gorgias customer is a direct-to-consumer brand running on Shopify with 2 to 50 support agents and a ticket volume that scales with seasonal commerce. Compared with Zendesk, Gorgias positions on faster setup and a tighter e-commerce data model — refunds, edits and cancellations happen inside the ticket without a tab-switch ⁹. Compared with Help Scout or Front, it positions on the depth of the Shopify product-catalogue and order-context integration.

The shapes of migration that actually land on Gorgias tend to fall into four patterns. First, Zendesk exits by Shopify-first merchants who want the order-context overlay; Gorgias ships a native Zendesk importer specifically for this shape ¹². Second, consolidation projects: a brand replacing Gmail-plus-Facebook-Messenger-plus-Aircall with one inbox.

Third, legacy replacements from Freshdesk, Help Scout, Intercom or Re:amaze, where the source schema is parallel but Rules and Macros do not map across. Fourth, growth-stage upgrades where a brand that started on a shared Gmail account hits 100+ daily tickets and needs ticket routing, SLAs and CSAT.

Each shape has a different difficulty profile: a Zendesk migration has clean object parity but two-year and 250-comment caps in the native tool ¹², while a homegrown-Gmail migration has no schema to map but every Macro and Rule has to be rebuilt by hand.

What makes migrating *to* Gorgias easier than the category average is the native Zendesk importer plus the partner-built Help Desk Migration (HDM) app, which covers 80+ source helpdesks and runs from inside Gorgias under Settings → App Store ³.

What makes it harder than the average is the ticket-based pricing model, which bills per billable ticket on the Starter and Basic plans and can punish teams that import two years of historical tickets without thinking through which ones become billable. Rules, Macros, AutoResponders, Flows and Help Center theme customisations do not import — they are rebuilt from documentation.

Teams that scope for that rebuild work up front finish on time; teams that assume the importer carries automations across do not.

Teams that scope for the automation rebuild up front finish on time; teams that assume the importer carries Rules and Macros across do not.

Gorgias is built around a small set of resources. The two load-bearing objects are Ticket and Customer, with Messages nested as an array inside each Ticket. Everything else — Views, Macros, Rules, Tags, Custom Fields, Voice Calls — orbits around those two ¹⁶.

Before you map a field on the source side, you need to know exactly which destination resource the row belongs on, what the create flow requires, and which value will serve as the upsert key. The table below summarises the objects you will touch in a Gorgias migration.

Customers use email (or another channel address — phone, Facebook ID, Instagram handle) as the de-facto unique identifier. Two tickets that arrive from the same email collapse onto the same Customer record automatically. The Customer object also supports an external_id field for round-tripping the source platform's primary key, which is the cleanest upsert pattern when you control the loader ⁴.

Tickets do not have a natural unique key beyond Gorgias's own auto-assigned id. The recommended pattern is to capture the source platform's ticket id in a Custom Field of type text on the Ticket object (with object_type=Ticket) and use it for reconciliation ⁴. Custom Fields exist for two object_type values only — Ticket and Customer — and the supported definition data types are boolean, number, and text ⁴.

Relationships in Gorgias are flat compared with a CRM. A Customer has many Tickets; a Ticket has many Messages and many Tags; a Macro can reference variables that pull from the Customer or Ticket context. There is no master-detail cascade — deleting a Customer does not delete their Tickets; the tickets are reassigned to a placeholder customer. There is no junction object pattern — tag many-to-many is handled internally ¹⁶.

Help Center articles are a separate top-level resource organised as top-level categories → categories → articles, with optional translations per article. They are not tickets and do not share the customer relationship; they are migrated through their own import path described in Section 4 and their own field set.

The single best predictor of a clean Gorgias migration is how much work you do on the source side before the first import starts. Practitioners migrating from Zendesk consistently report that the import itself is reliable; what burns time is the post-import realisation that Rules, Macros and SLA policies were not in scope and need to be rebuilt under deadline.

The single best predictor of a clean migration is how much work you do before the first ticket lands in the new helpdesk.

Treat the source export as raw material that needs to be shaped to Gorgias's expected formats — email lowercased, phone normalised to E.164, tags converted to the casing they will live under in Gorgias Rules, message bodies sanity-checked against the 1 MB limit, attachments inventoried for re-upload ⁷.

Source-side prep

• Audit and dedup Customer records before export. Gorgias collapses tickets onto a Customer record by email (or phone/social handle); duplicate customers in the source produce orphaned ticket histories spread across two Customer records that have to be merged via the merge function after import.
• Normalise emails to lowercase and trim whitespace; strip role-based addresses (info@, sales@) that you do not want generating billable tickets in Gorgias.
• Inventory Macros, Rules and AutoResponders from the source platform. Export each one to a tracked document — these do not move and you will rebuild them from this spreadsheet during Section 5.
• Stamp a stable external id on every Ticket and Customer in the source export — the source platform's primary key — so re-runs and reconciliation are deterministic. This lands in a text Custom Field on the Gorgias side ⁴.
• Decide the historical scope. The native Zendesk importer caps at the last two years of data and splits any ticket with more than 250 comments into multiple closed tickets ¹². Help Desk Migration's third-party tool has no hard time cap but bills per record ³. Either path requires a deliberate decision before scope is signed.

Destination-side prep

• Provision a sandbox account via the Gorgias Partner Portal (partners.gorgias.com). New sandbox accounts default to Demo; email [email protected] with the account URL to convert to the partner plan for full-fidelity testing ¹⁵.
• Provision Users (agents) first with the correct roles — Admin, Agent, Lite — under Settings → Team. Only Admins can run imports, and only the Account Owner can transfer ownership ²². Owner-on-ticket assignment during import fails silently if the referenced agent does not exist.
• Pre-create every Custom Field on the right object (Ticket or Customer) with the right data type before importing. Custom Fields with the wrong object_type cannot be reused ⁴.
• Connect channels — email (direct integration or auto-forwarding), Shopify/BigCommerce/Magento, chat, Facebook, Instagram, WhatsApp, SMS, Aircall — *before* importing historical tickets, but with the source platform's matching channel disconnected so messages do not arrive twice ¹².
• Pre-create top-level categories and categories in the Help Center before importing articles via CSV. Articles target an existing category by name and fail if the category is missing.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours for a small DTC brand, longer for a multi-channel brand with social and voice — and communicate it to every department that touches the helpdesk. Train agents on Gorgias daily workflows, Macros, Views and the Customer sidebar (with Shopify order context) before go-live, not after.

A typical small-merchant migration runs one to three business days of elapsed time; a multi-channel brand with two years of Zendesk history runs five to fourteen days because the native importer processes around 720 tickets per hour and a 250,000-ticket history therefore takes roughly two weeks ¹². Build the runway accordingly.

Gorgias exposes load paths whose right choice depends on the source platform and dataset size. The native Zendesk Import covers the single most common source. The Help Desk Migration (HDM) partner app, accessible from inside Gorgias, covers 80+ other source helpdesks.

Native Zendesk Import

The Zendesk importer lives at Settings → Import data → Add account. It pulls tickets, macros, users, tags and ticket fields from Zendesk into Gorgias and, after the initial import, runs a continuous sync from the cut-off point forward ¹². Setup needs the Zendesk subdomain and Zendesk Admin credentials, and only Gorgias Admins can run it.

Limits to plan around: up to two years of the most recent ticket data, tickets with more than 250 comments are split into multiple closed tickets, deleted or blank Zendesk tickets are skipped, ticket statuses sync as open or closed only (no pending/on-hold equivalent), and the throughput averages 720 tickets per hour ¹².

The continuous sync ingests in three phases — last two weeks, then 730 days back to 2 weeks ago oldest-first, then forward — and the same email channel must not be enabled on both platforms during the import or messages duplicate ¹².

Help Desk Migration (HDM) partner app

Built by Relokia and accessed inside Gorgias at Settings → App Store → All Apps → Help Desk Migration ³. It supports 80+ source helpdesks including Freshdesk, Help Scout, Intercom, Kustomer, Re:amaze, Zoho Desk and Front. It runs a free Demo Migration on 20 tickets plus 20 articles so you can validate the mapping before committing, then a paid full migration that handles Delta migration, Interval, and re-migration while preserving relationships ³.

HDM covers Tickets and their comments (with privacy and publicity flags), Customer profiles, Agents, Groups, Tags, Custom Fields (text/boolean/dates/number/select/multi-select), Macros, and Help Center top-level categories, categories and articles including translations. Inline images and call recordings move as ticket attachments. Pricing is per-record and depends on dataset size and selected options ³.

CSV imports

Two narrow CSV import paths exist inside the UI: Macro CSV import under Settings → Productivity → Macros (4 columns: name, body_text, tags, id, UTF-8 encoded) ⁶, and Help Center article CSV import for knowledge-base content. Attachments must be uploaded separately and then referenced when creating the Ticket Message that owns them ²¹.

Mapping is where every helpdesk migration earns its scars. The schema decisions you make in your mapping spreadsheet determine whether Rules fire correctly on day two, whether SLA reports work on day five, and whether your support team trusts the Customer sidebar on day thirty.

Work resource by resource, in this load order: Users (agents) first so ticket owner references resolve, then Tags so ticket tag references resolve, then Customers so ticket customer references resolve, then Custom Fields, then Tickets-with-Messages, then Macros, then Help Center articles. Rules, AutoResponders and SLA policies are rebuilt in the UI after data lands.

Customers

Ticket history with Messages array (public + internal_note flag)

A Ticket in Gorgias is a header (subject, channel, status, assignee, tags) plus an ordered array of Messages. Each Message has a body_text and/or body_html (capped at 1 MB per body ⁷), a sender reference (a Customer or a User), a channel value matching the ticket's channel, and a critical public flag — public: true means the message is visible to the customer, public: false means it is an internal note.

When mapping from a source platform whose comments have a private/public flag (Zendesk's public, Freshdesk's private, Help Scout's customer_id presence), preserve the polarity carefully — flipping it converts internal triage discussion into customer-visible replies, which is the single most-cited Gorgias migration regret on Reddit and in vendor changelogs.

Help Center article import

Help Center content is migrated either via the HDM partner app — which preserves articles, categories, translations and inline media as attachments — or via the native Help Center CSV import path. The CSV import handles Top-level categories → Categories → Articles with fields title, body, author, folder, status, and translations.

Images, GIFs and other inline media are *not* preserved through the CSV path — they are re-uploaded after the article body is loaded, and most practitioners use this as the cue to audit and refresh visual assets.

Macros, Rules and AutoResponders — rebuild, not migrate

Macros have a narrow CSV import (4 columns: name, body_text, tags, id; UTF-8 encoded; formatting not preserved) ⁶. Tags referenced in the macro must exist before the import or the row is skipped. If an id matches an existing Macro the import updates it; if no id is provided a new Macro is created ⁶.

Rules and AutoResponders do not import. They are rebuilt manually in Settings → Automation → Rules and Settings → Automation → AutoResponders. Export every Rule from the source platform to a tracked spreadsheet — trigger, conditions, actions — and rebuild each one in the Gorgias UI. The Rules engine in Gorgias is condition-tree-based with actions covering tag assignment, ticket assignment, macro application, status change and HTTP integration calls. Flows (chat conversation logic) and Order Management (Shopify-aware automation) are similarly rebuilt under Settings → Automation.

SLA and CSAT history

Gorgias supports per-channel SLA policies under Settings → Productivity → SLAs that fire when a ticket meets condition criteria (priority, tag, channel). SLA configuration does not migrate — define each policy fresh in the UI. Historical SLA attainment from the source platform also does not migrate; the cleanest pattern is to export the source's last-quarter SLA report as a PDF and archive it, then start the SLA clock fresh in Gorgias from import day.

CSAT history is similar. Gorgias's native satisfaction survey and CSAT score are computed from the date you enable the survey forward; pre-import CSAT scores from Delighted, Trustpilot or the source helpdesk are not back-populated. Run the Delighted Gorgias integration via HTTP Integration (Settings → Integrations → HTTP, trigger on Ticket updated) to survey-send going forward; if you need the historical CSAT report preserved, archive it as a PDF.

Multi-channel inbox: email, chat, social, SMS, voice

Gorgias's multi-channel inbox is set up per channel and per integration after the historical import has finished, with the source-platform side of each channel disabled in lockstep ¹². The supported channels are email (direct Gmail/Outlook integration or forwarding), Help Center contact form, native Chat widget, Facebook Messenger, Instagram (DMs and comments), WhatsApp Business, SMS, and phone via Aircall.

The single most common channel-migration mistake is leaving the source platform's email integration enabled while Gorgias is also pulling that mailbox: every inbound email creates two tickets, one on each platform, and the continuous-sync layer duplicates the message back into the original ticket ¹². The sequence is: complete the Zendesk import → enable the new email channel in Gorgias → pause the Zendesk sync → disable the email channel on the Zendesk side → repeat per channel.

Shopify / BigCommerce / Magento customer + order context

The e-commerce integration is what makes Gorgias Gorgias. The Shopify integration is installed via Settings → Integrations → Shopify, connects to one or many Shopify stores, and at runtime pulls the customer's full order history, line items, fulfilment status and customer-lifetime-value onto the right-hand sidebar of every ticket. BigCommerce and Magento integrations follow the same pattern.

Order context is not migrated as data — it is queried live from Shopify on every ticket open via the integration. The implication for migration: the matching is by Customer email, so the customer-email normalisation work from Section 3 is what makes the Shopify sidebar populate correctly on day two. Tickets that ended up with the wrong email after import will show no Shopify context until the email is fixed.

Files, attachments and call recordings

Attachments require a multi-step process: the file is uploaded first, returns an id, and is then referenced when creating the Ticket Message that owns the attachment ²¹. HDM and the native Zendesk importer handle this multi-step pattern automatically; inline images embedded in article HTML need to be re-uploaded separately.

Call recordings from Aircall or Zendesk Voice are imported as ticket attachments by HDM rather than as native Voice Calls — historical voice analytics are therefore preserved as audio but not as searchable transcripts.

Audit trail, ownership and original timestamps

Ticket created_datetime and message timestamps are preserved on import when you go through the native Zendesk Importer or HDM ¹². The Gorgias audit log, accessible under Settings → Audit logs, captures events from import-day forward and retains them for up to 12 months as of the February 25, 2026 retention change ¹⁹²⁰. Pre-import audit history from the source platform is not migrated; export it before cutover if you need to retain it for compliance.

Ticket ownership (assignee) maps to a Gorgias User and resolves at import time against the email of the source-platform agent. Agents whose email does not match a provisioned Gorgias User end up with their tickets unassigned, which silently breaks downstream owner-based Rules. Match emails before the import or remap unassigned tickets in bulk after.

Validation is the bridge between the import finishing and your agents being allowed in. The most reliable signal is having team leads from each support channel verify the tickets they personally remember — they know what right looks like in a way no reconciliation script can match.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before agents get login access.

• Total tickets imported vs source — minus the deliberately excluded buckets (deleted Zendesk tickets, blank tickets, tickets outside the two-year window) ¹².
• Tickets per channel (email, chat, Facebook, Instagram, WhatsApp, SMS, phone, contact-form) — confirm the channel distribution roughly matches the source.
• Tickets per status (open, closed) and per tag — and confirm the pending/on-hold-equivalent tags are populated where the source had richer statuses.
• Messages per ticket — sum and compare; particular attention to the 250-comment-cap tickets that arrive as split chains ¹².
• Public-vs-internal message ratio — a sample of 50 tickets verified by hand catches polarity flips on the public boolean before they reach customers.
• Customers imported vs source — and a count of how many resolve to a Shopify customer via email matching once the Shopify integration is wired.
• Tags created vs source — case-sensitivity matters because Rules will fire only on exact matches.
• Macros imported vs source — and confirm the body formatting was acceptable for the templates that rely on visual structure ⁶.
• Help Center articles, categories and translations — and a manual check that inline media re-uploaded where the CSV path dropped it.
• Agent assignment — GROUP BY assignee_user and confirm no agent's queue is suspiciously empty (a sign of unresolved email mapping).

On top of reconciliation, run a manual spot-check protocol: pick 30 random tickets across channels and verify each one against the source UI — subject, status, all messages, internal-vs-public flag on each, attachments, tags, assignee. Pick five high-value VIP tickets and trace the full thread. If a non-trivial discrepancy shows up in three or more of the 30, halt the cutover, fix the root cause, and re-run the affected slice.

Gorgias does not offer a bulk-undo for imports. The audit log under Settings → Audit logs captures customer-created, customer-updated, ticket-created and ticket-updated events for the last 12 months ¹⁹²⁰ and is useful for tracing individual problems, but it is not a rollback mechanism.

The practical rollback strategy is: export the source platform's full ticket and customer dataset to S3 or your warehouse before the import starts, stamp every imported ticket with an *Import Batch* Custom Field, and if catastrophe strikes, bulk-close-and-archive by that batch value and re-run the cleaner pass.

Cutover sequencing per channel: (1) complete the historical import; (2) enable the corresponding channel in Gorgias (email, chat, Facebook, etc.); (3) pause the continuous sync from the source platform; (4) disable that channel on the source-platform side; (5) verify a test message round-trips through the new channel; (6) move to the next channel.

Repeat for every channel before turning off the source platform entirely ¹². Plan a 48-hour hyper-care window with the migration lead on call, and schedule the source-platform decommission 30 to 90 days post-cutover — never the same day.

Gorgias maintains a Partners directory at agencies.gorgias.com listing certified agencies tiered as Elite, Premium and Standard, most of which are simultaneously Shopify Plus partners offering end-to-end e-commerce implementation ². Migration-specific endorsement is concentrated around Help Desk Migration (HDM) by Relokia, which is installable directly inside Gorgias at Settings → App Store ³, and ClonePartner, which is explicitly validated by the Gorgias team for migration services and runs an engineer-led model with security review and process validation by the Gorgias compliance team.

On the ETL and iPaaS side, Airbyte, Fivetran, Stitch, Celigo, Integrate.io, Workato and Prismatic all ship Gorgias connectors. Their role in a one-time migration is typically the staging layer that pulls source-platform data into a warehouse, the transformation layer that normalises customer emails and tag casing, and — post-migration — the ongoing sync layer that mirrors Gorgias data into your warehouse for BI on top of platforms like Looker, Mode or Hex.

Bruin and the open-source ingestr CLI are common picks for warehouse-first DTC teams that want to copy Gorgias to S3 or Snowflake on a schedule; Workato and Celigo are common where the migration is bundled with broader e-commerce-stack integration rebuilds (ReCharge, Klaviyo, Yotpo, Loop Returns).

Managed-migration cost ranges vary widely. Help Desk Migration's pricing is per-record and scales with dataset size and selected options (inline images, call recordings, translations, custom mappings) — a small-merchant migration of 5,000 tickets often lands in the $300–$1,500 range, while a 250,000-ticket multi-channel migration with attachments and Help Center articles typically runs $5,000–$25,000 ³. Engineer-led shops like ClonePartner price separately for complex custom-field mappings and historical-data depth. Always run the free 20-ticket Demo Migration before signing scope.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Gorgias migrations and handles the customer email normalisation, ticket and message mapping, public-vs-internal polarity preservation, attachment re-upload, and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee based on ticket count and source platform, with separate line items for Help Center article import and historical voice / call-recording depth so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want the embedded HDM partner app, an official endorsed partner like ClonePartner, an iPaaS-first warehouse-bound approach, or a specialist migration vendor. Explore FlitStack →