How to Migrate Off Gorgias (When and How to Leave)
Deciding to leave Gorgias is rarely a snap judgment. For most ecommerce teams it builds slowly — a billing surprise at renewal, a run of instability during a peak sale, an AI Agent add-on that changed the math, or simply outgrowing the platform. Whatever the trigger, the mechanics of leaving are the same, and they are not glamorous: there is no native "export straight to my new help desk" button in Gorgias, so getting your history, tags, and macros out cleanly takes a deliberate plan. This is the honest playbook — the real reasons teams switch, exactly what the native export gives you and what it quietly leaves behind, when a paid migration tool becomes worth it, and how to sequence the whole move without torching your queue or your data.
The honest reasons teams leave Gorgias
Nobody migrates a live support operation for fun, so it's worth being clear-eyed about the triggers that actually justify the work.
Pricing and the ticket model. Gorgias bills on ticket volume, and its AI Agent capability is a separate line item. As volume grows or seasonality spikes, the bill can move in ways that are hard to forecast, and the automation add-on can change your unit economics faster than expected. If you're weighing the numbers, our breakdown of Gorgias pricing is a good gut-check before you commit to a switch.
Stability under load. Ecommerce support lives and dies by Black Friday and launch days. Teams that have felt slowness or outages during exactly the windows where every minute of queue matters tend to start shopping for alternatives — reliability under peak load is a legitimate, non-negotiable reason to move.
Outgrowing the fit. Gorgias is purpose-built for Shopify-first DTC brands, and that focus is a strength until it isn't. Teams that expand into B2B, add complex routing, or need deeper reporting sometimes find the platform's ecommerce-first shape working against them. (If you're still deciding whether Gorgias is right at all, start with what Gorgias actually is.)
None of these is a reason to move recklessly. But any one of them, sustained, is a reason to plan a move properly.
What the native Gorgias export actually gives you
Here's the part people underestimate. Gorgias can export your tickets to CSV, and that's genuinely useful for a backup or for analysis — but it is not a migration file, and its scope is narrower than the name suggests.
According to the Gorgias export documentation, a standard ticket-view CSV export includes ticket ID and link, tags, channel, priority, integration details, subject, creation and closed dates, survey score, assignee, customer name and email, response and resolution times, message counts, and custom fields. That's a solid metadata layer. But the same docs are explicit about what the export does not include: "Internal notes, ticket events, Facebook wall posts, Instagram media messages, and Instagram ad media messages aren't included in the export." Message bodies only appear in the analytics drill-down export, and even then only public messages — attachments aren't part of it.
The limits matter too. The drill-down export returns "most recent 30 days of data from the selected period, up to a maximum of 100,000 tickets," a single export caps at 1 million tickets, and the download link is only active for 14 days before you have to regenerate it. So if your plan is "I'll just CSV everything and re-upload it," you're quietly signing up to lose your internal notes, your social-channel conversations, your event history, and — for the message bodies you can get — anything older than a rolling 30-day window per export.
Macros are their own small trap. You can export them from Settings → Productivity → Macros → Export Macros as CSV, but the Gorgias macros documentation warns that on re-import "the Macro Actions related to the Macros won't be affected by these changes" — meaning the actions wired into a macro don't travel through the CSV. You get the reply text, not the automation behind it. (For what those actions actually do, see Gorgias macros explained.)
The migration tool that fills the gaps
Because there's no native Gorgias-to-competitor path, the practical way to move real history is a paid migration service. Help Desk Migration is the one Gorgias itself lists inside the app, and it's built to preserve the relationships a flat CSV can't. Per its Gorgias documentation, it transfers:
- Tickets — ID, subject, tags, status, priority, assignment, comments with their metadata, dates, AI intent, resolution, and custom fields.
- Customers — name, email, phone, language, timezone, notes, type, and custom fields.
- Agents, with mapping so you can reassign as needed.
- Macros with agent, contact, and ticket actions.
- Knowledge base — categories, top-level categories, and articles including translations.
It also runs a free demo (20 random tickets and 20 KB articles) so you can validate field mapping before you pay, plus delta migration (catch records created or updated during the full run) and interval migration (pause and resume), both of which let you move without freezing your live queue.
Be honest about its edges, though. Help Desk Migration's own Gorgias checklist notes that organizations, inline images (they arrive as attachments), CC fields, and attachments over 10 MB don't migrate, tickets with 30–40+ comments may need custom handling, and — critically — statistics don't transfer. Your historical reporting resets in the new system.
What moves vs what you rebuild
This is the table to internalize before you schedule anything. "Records" — the historical facts — move. "Configuration" — the logic that ran your queue — does not.
| Artifact | Native CSV | Help Desk Migration | Rebuild in new desk? |
|---|---|---|---|
| Ticket metadata (ID, tags, status, dates, custom fields) | Yes | Yes | No |
| Public message bodies | Partial (30-day window, drill-down only) | Yes | No |
| Internal notes | No | Yes | No |
| Ticket events / audit history | No | Partial | No |
| Social messages (FB/IG) | No | Varies by pair | No |
| Customers / contacts | Metadata only | Yes | No |
| Agents | Names only | Yes (with mapping) | No |
| Attachments | No | Yes (≤10 MB) | No |
| Macros (reply text) | Yes | Yes | No |
| Macro actions / automations | No | No | Yes |
| Rules / triggers | No | No | Yes |
| Views, routing, SLAs | No | No | Yes |
| Reports / statistics | No | No | Yes (cold start) |
The pattern is consistent across every help desk migration: your data can be moved by a tool, but your behaviour — rules, routing, SLAs, dashboards — has to be rebuilt in the destination's own grammar. Treat that rebuild as a fresh implementation, not a copy-paste, and it becomes the perfect moment to drop the quirks you were leaving Gorgias to escape.
The sequencing that avoids a bad cutover
A modern migration is not a lights-out event — because a tool reads from one API and writes to another, Gorgias keeps serving customers while records copy, and delta migration catches the stragglers. The real risk isn't downtime; it's rules firing on imported history. Sequence it like this:
- Audit and export a backup. Run the native CSV export as a safety net and to inventory what you have. Our guide to exporting data from Gorgias covers the mechanics.
- Disable Gorgias automation rules before any test run — the checklist calls for toggling off Automation → Rules so status changes don't fire mid-transfer.
- Run the free demo migration (20 tickets + 20 articles) and verify comment authorship, agent assignment, attachments, and article status.
- Run the full migration, using interval mode if your volume is high (budget roughly an hour per 100,000 tickets).
- Rebuild config in the destination — rules, macros' actions, routing, SLAs — and re-enable automations one at a time so a misfiring rule can't email every customer at once.
- Run a delta pass to sweep anything created during the cutover, then flip your channels over.
Where an AI layer fits after you land
Here's the reframe. The most laborious half of leaving Gorgias is rebuilding the behaviour — the macro actions and rules that don't port. If you're rebuilding that logic anyway, it's the ideal moment to ask whether every workflow needs to be a brittle rule, or whether some of it belongs to an AI agent that reasons over the ticket instead.
That's the seam where Macha fits, and it's worth being precise about what Macha is: an AI agent layer that runs on top of whichever help desk you migrate into — it is not a Gorgias alternative or a help desk replacement. It connects as a native integration (including back to Gorgias itself if you decide to stay), reads and writes the same tickets you migrated, drafts grounded replies from the knowledge base that came across, triages by intent, and looks up order or account status through a custom tool that turns a REST API into something the agent can call. Credits are consumed per AI action, not per resolution — the pricing page has the details. The clean division: let the migration tool move your records, rebuild the deterministic config that genuinely has to be rules, and hand the reasoning-heavy work to an agent.
FAQ
Can I export my data out of Gorgias myself for free? Yes, but with real gaps. The native CSV export gives you ticket metadata and (via the analytics drill-down) public message bodies for a rolling 30-day window, capped at 100,000 tickets per export. It excludes internal notes, ticket events, and social-channel messages, and the download link expires after 14 days. It's a fine backup, not a migration.
Is there a native way to move from Gorgias to another help desk? No. Gorgias has no built-in export-to-competitor path, which is why it lists a third-party service (Help Desk Migration) inside the app. A paid migration tool is the practical way to move ticket history, tags, macros, and KB with relationships intact.
What won't move even with a paid migration tool? Statistics and reports don't transfer, so expect a reporting cold start. Organizations, CC fields, attachments over 10 MB, and inline images (they become attachments) also don't migrate cleanly, and macro actions, rules, routing, and SLAs are configuration you rebuild in the new desk by hand.
Will migrating cause downtime? Not inherently. Migration tools read from Gorgias's API and write to the destination while Gorgias stays live, and delta migration catches records created during the run. The bigger risk is destination automations firing on imported history — disable them first and re-enable one at a time.
Do I have to replace my help desk to add AI after moving? No. An AI agent layer like Macha runs on top of whichever help desk you land on and doesn't replace it. It resolves and triages tickets using the knowledge base you brought across while the help desk stays your system of record.
Rebuilding your automation as part of leaving Gorgias? Start a free trial of Macha and connect it to your new help desk in minutes.
Add AI agents to your Gorgias
Macha resolves tickets end to end on Gorgias — no migration, no code.
Zendesk
Freshdesk
Gorgias
Front
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

