How to Migrate from Zendesk to Gorgias

Why merchants move from Zendesk to Gorgias in the first place

The reason this migration is so common is ecommerce. Zendesk is a general-purpose help desk; Gorgias is built for online stores, and it treats Shopify (or BigCommerce, or Magento) as a first-class citizen rather than a bolt-on. In Gorgias, a ticket arrives with the customer's order history, fulfillment status, and subscription details rendered right next to the conversation, and agents can refund, cancel, or re-ship without leaving the ticket. That "customer context on the ticket" is the single biggest gain, and it's why the migration is worth the effort rather than a lateral move. If you're still weighing the platforms, our primer on what Gorgias is covers the ecommerce-native model in depth.

The two categories that decide your whole plan

Everything in your Zendesk instance falls into one of two buckets, and the split is cleaner than most people expect.

Records are the historical facts of your support operation — tickets, users, tags, macros. These are rows of data, and rows of data move. The importer reads them out of Zendesk's API and writes them into Gorgias, preserving the relationships between them.

Configuration is the logic that acted on those records — the triggers that routed tickets, the automations that ran on a timer, the views that organized the queue, the reports that measured it. This is behaviour, not data, and it does not transfer. Gorgias' automation model is structured differently from Zendesk's, so even a "matching" rule has to be rebuilt in Gorgias' own grammar. There is no export file that turns a Zendesk trigger into a Gorgias Rule.

Hold onto that distinction and the rest of the plan falls into place.

What the native Zendesk importer moves

Gorgias' built-in importer (Settings → Historical imports → Zendesk) connects to your Zendesk account and pulls data across without a middleman. Per Gorgias' Zendesk import documentation, it moves five object types:

• Tickets — up to two years of your most recent data, with their conversation history. Note the status remapping: Zendesk pending and solved tickets import as closed in Gorgias, and everything else imports as open.
• Macros — your active macros come across, but with a real caveat covered below.
• Users — imported only if they're assigned to or have commented on a ticket, so dormant profiles are skipped.
• Tags — imported as long as they appear on a ticket that's included in the import.
• Ticket fields — mapped across, unless you're carrying a lot of them (see limits).

After the initial run, continuous sync keeps ticket history current and updates fields and macros, so you're not forced into a single hard cutover.

What you rebuild from scratch

Here's the half that surprises people. Your Zendesk configuration does not port — you recreate it inside Gorgias after the records land. The most important mapping to internalize: Zendesk triggers become Gorgias Rules, and you build them by hand. Some Zendesk trigger conditions have no Gorgias equivalent at all (Side Conversation triggers, for instance, map to nothing), so this is a rebuild-with-judgment exercise, not a lift-and-shift. Our guide to how Gorgias Rules work is the reference for translating that logic.

Two rows deserve a closer look. Macros import, but Gorgias only supports reply text and status-change actions — any macro that also set a tag, assigned an agent, or fired a webhook in Zendesk imports with an empty actions list, so you'll re-add those actions in Gorgias. (For how macros behave on the far side, see Gorgias macros explained.) And reports get their own row because even though the underlying tickets migrate, your historical analytics were computed inside Zendesk's reporting layer — once tickets land in Gorgias, trend lines and CSAT recalculate from Gorgias' own data model. Budget for a reporting "cold start."

The practical takeaway: treat the configuration rebuild as a fresh implementation of Gorgias, not a copy-paste — and a chance to shed the Zendesk quirks you're migrating away from.

Native importer limits vs a paid migration tool

The native importer is free and genuinely good, but it has hard edges worth knowing before you commit:

• Two-year window. Anything older than ~24 months doesn't come across the native path.
• The 250-comment split. Any ticket with more than 250 comments is split into multiple closed tickets in Gorgias — long escalation threads fragment.
• The 500-field cliff. If your Zendesk has more than 500 ticket fields, ticket fields are skipped entirely.
• Macro action loss and the status remapping described above.

When those limits bite — you need older history, you have monster threads, or you're carrying an unusually complex field schema — a paid tool is the honest alternative. Help Desk Migration is the widely used one; it moves tickets with attachments plus public and private notes, contacts, agents, macros, and knowledge base, offers a free Demo run to sanity-check mapping, and supports Delta migration (catch records created mid-run) and Interval migration (pause and restart up to five times). Its migrations are designed to be zero-downtime because they read one API and write another while both systems keep serving customers.

A fair rule of thumb: if you're within two years of history with normal-sized tickets, the native importer is the right call. If you need deep history, private notes preserved end-to-end, or you're wary of the 250-comment split, price out a paid tool first.

The downtime and CSV question

Good news first: this is not a lights-out event. Because the native importer connects to Zendesk's API and continuous sync catches stragglers, your Zendesk instance keeps serving customers while records copy across. There's no mandatory blackout window.

The real risk isn't downtime — it's your new Gorgias Rules firing on imported historical tickets. If you build Rules before or during the import, a Rule can wake up and auto-reply to a customer about a ticket you resolved two years ago. The discipline that prevents it: import first with Rules paused, verify the data, then enable Rules one at a time so you catch a misfiring Rule before it hits every ticket.

One more honest note if you're considering a DIY export instead of the importer. Gorgias' own native CSV export — the reverse direction, useful to know for symmetry — is deliberately limited: with full message content it's capped at the most recent 30 days and 100,000 tickets, and it excludes internal notes, ticket events, and social messages (Facebook wall posts, Instagram media), keeping only public messages. That's a good reminder that flat CSV is a poor vehicle for real ticket history in either direction — API-based importers exist precisely because CSV drops the threading, notes, and events that make a ticket a ticket.

Where an AI layer fits — after the dust settles

Here's the reframe worth sitting with. The most laborious part of this migration is rebuilding behaviour — the triggers-turned-Rules that used to run your queue. If you're rebuilding that logic from scratch anyway, it's the ideal moment to ask whether every rule needs to be a brittle if-this-then-that Rule, or whether some of that work belongs to an AI agent that reasons over the ticket instead.

Macha is one such layer: it runs on top of the Gorgias you've just migrated into as a native connector — it does not replace Gorgias, and it is not a Gorgias alternative. Once you connect Macha to Gorgias, it reads and writes the same tickets you imported: drafting or posting grounded replies from your help center, triaging by intent so the right ticket reaches the right team, and looking up order or subscription status through a custom tool that turns your Shopify or backend REST API into something the agent can call — exactly the ecommerce context Gorgias surfaces on the ticket, now acted on automatically. Credits are consumed per AI action, not per resolution, so the model matches the automation work rather than the outcome — the full pricing breakdown has the detail, and it's worth comparing against Gorgias' own pricing when you plan the budget.

The clean division: let the native importer move your records, rebuild the Rules and SLAs that genuinely have to be deterministic, and let an agent take the reasoning-heavy work that used to eat your team's day.

FAQ

Does the Zendesk to Gorgias importer move my triggers and automations? No. Triggers, automations, views, SLAs, and CSAT surveys are configuration, not records — they don't transfer. Gorgias' native importer moves tickets, macros, users, tags, and ticket fields; you rebuild your Zendesk triggers as Gorgias Rules by hand after the data lands.

How much history does the native importer bring across? Up to two years of your most recent Zendesk data. If you need older tickets, or you have threads longer than 250 comments (which the importer splits into multiple closed tickets), a paid tool like Help Desk Migration is the alternative.

Do my Zendesk macros work the same in Gorgias? Partially. Active macros import, but Gorgias only supports reply text and status-change actions — any macro that also tagged, assigned, or fired a webhook imports with an empty actions list, so you re-add those actions in Gorgias.

Will migrating to Gorgias cause downtime? Not inherently. The native importer reads Zendesk's API while Zendesk keeps serving customers, and continuous sync catches records created mid-run. The bigger risk is new Gorgias Rules firing on imported historical tickets — import with Rules paused, verify, then enable them one at a time.

Can I add AI to Gorgias after migrating without replacing it? Yes. An AI agent layer like Macha connects to Gorgias as a native connector and runs on top of your migrated help desk — it doesn't replace Gorgias. It resolves tickets using your help center content and triages by intent, while Gorgias stays the system of record and Shopify context stays on the ticket.

Just moved to Gorgias and rebuilding your Rules from scratch? Start a free trial of Macha and connect it to your Gorgias in minutes.