Data export, ticket history, macros, and a no-downtime cutover — in the right order.
Switching helpdesks sounds more disruptive than it usually is, but only if you do it in the right order. The teams that have a bad time are the ones who spin up a new tool, redirect their support inbox, and then realize three weeks later that six months of ticket history is inaccessible and their top-20 macros have to be rebuilt from scratch. The teams that have a good time do a data export first, run both platforms in parallel for one to two weeks, and close the old account only after everything is verified.
This guide covers the mechanics: what to export and from where, how to preserve macros and canned responses, what happens to customer email threads, how to stage the cutover without any support gap, and what you lose permanently if you skip steps.
A helpdesk migration has four distinct data categories, each with a different level of portability:
| Data type | Portability | What to do |
|---|---|---|
| Closed ticket history | Exportable | Export as CSV or JSON before canceling. Most platforms retain data 90 days after account closure — do not rely on this. |
| Open / in-progress tickets | Manual transfer | Resolve or manually move to new system before cutover. Do not let them sit in a limbo inbox. |
| Macros / canned responses | Semi-portable | Export the list; rewrite variable syntax for new platform. Priority: top 20 by send frequency. |
| CSAT and analytics history | Platform-locked | Export to spreadsheet for your own records. New platform starts fresh from migration date. |
| Customer contact records | Exportable | Export name, email, tags, and notes. Import to new platform or CRM as a starting dataset. |
| Attachments | Manual / API only | Bulk attachment export usually requires the API or a paid migration tool. Decide if it is worth the effort. |
The honest truth about CSAT history: no mainstream helpdesk offers a CSAT import that another platform can consume. Your historical CSAT scores stay in the platform that collected them. Export them to a spreadsheet before you close the account and treat the migration date as a reset point in your reporting.
Do this before you do anything else. An export takes minutes and gives you a recovery option if the migration goes wrong.
Go to Settings → Data Exports. Gorgias lets you export tickets, customers, and satisfaction surveys separately. Choose a date range (export everything: the full account history). The ticket export includes ticket ID, customer email, channel, subject, status, creation date, first response time, and resolution time. Message bodies are in a separate messages export. Run both.
Gorgias does not include attachments in the CSV export. If you need attachments, use the Gorgias REST API: GET /api/tickets/{id}/messages includes attachment URLs you can batch-download. For most migrations, searching closed ticket CSVs is sufficient; full attachment retrieval is only needed if regulatory compliance requires it.
Go to Admin Center → Account → Tools → Reports. Zendesk offers a JSON export (complete, including comments and custom fields) and a CSV export (flatter, easier to open in Excel). Choose JSON for completeness. The export is emailed to the account owner as a download link; it can take up to 24 hours for large accounts. Request it the day before you need it.
Zendesk’s JSON export format is well-documented and directly supported by migration tools including Help Desk Migration and Mover.io if you want to import history into the new platform rather than just archive it.
Go to Admin → Account → Export Data. Freshdesk exports contacts, companies, tickets, and solutions (knowledge base articles) as separate ZIP files. Ticket bodies are included. Attachments are referenced by URL in the export but not bundled.
Macros (also called canned responses, saved replies, or quick responses depending on the platform) are the most underestimated part of any helpdesk migration. A well-tuned macro library represents months of refinement. Losing it means agents spend the first two weeks of the new system typing out replies that should be one-click sends.
GET /api/macros returns all macros with their body text and variable list. Alternatively, manually copy the macro body text into a spreadsheet while you are still in the platform.GET /api/v2/canned_responses returns all canned responses with their body and folder.Every platform uses different variable syntax for dynamic fields. This requires human review, not just copy-paste. Common mappings:
| Variable | Gorgias syntax | Zendesk syntax | Freshdesk syntax |
|---|---|---|---|
| Customer first name | {{ticket.customer.firstname}} |
{{ticket.requester.first_name}} |
{{contact.name}} |
| Ticket ID | {{ticket.id}} |
{{ticket.id}} |
{{ticket.id}} |
| Agent name | {{ticket.assignee.name}} |
{{agent.name}} |
{{agent.name}} |
| Order ID (Shopify-specific) | {{ticket.customer.shopify_orders[0].name}} |
Not native | Not native |
Prioritize the macros your team actually uses. Pull a 90-day send-count report from the old platform and rebuild the top 20 by volume first. The long tail of rarely-used macros can wait until week two of the new system.
The most common migration mistake is switching the email routing and the support inbox at the same time, with no overlap period. Do not do this. Instead, set up the new helpdesk completely — channels connected, macros rebuilt, automation rules configured, agents trained — before a single real ticket is routed to it.
During setup, use a test email alias (e.g., support-test@yourdomain.com) to send synthetic tickets to the new platform and verify that:
Once the new system is verified with test tickets, execute the cutover in this order:
The two-week parallel read window is the safety net. Customers who reply to old ticket threads after your cutover will have their emails delivered to whichever inbox your email provider is currently routing to. Once routing is switched, those replies go to the new system automatically. The parallel window is for your agents to look things up, not for dual-routing tickets.
Being clear about the hard limits avoids false expectations going into the migration:
If the reason you are switching is to get off per-ticket billing — Gorgias overage, Zendesk seat creep, or just the unpredictability of volume-sensitive pricing — the migration sequence above still applies, but there is one additional step: the AI needs to be trained on your store’s specific policies before it handles live tickets.
For a Shopify store, that typically means providing:
Run the AI on test tickets for a week before switching live routing. Review every response the AI generates during the test period and correct any factual errors or tone mismatches. An AI that has been correctly calibrated to your policies will handle 60–80% of your inbound volume without human review; an AI that has not been trained on your specifics will produce plausible-sounding but incorrect answers that erode customer trust.
Running on Gorgias per-ticket billing and considering flat-rate AI support?
Hatchloop’s founding support plan is a flat $99/month for Shopify stores — unlimited AI resolutions, native order lookup, no ticket overages. We handle the migration setup as part of onboarding.
Check each item before canceling your old subscription.