Migration Checklist: Moving to Gorgias

Phase 0

Decide & Plan

Lock scope, owners, and the cutover window before any data moves.

• Document the business reason for moving to Gorgias. Capture whether the driver is Shopify-native customer + order context, ticket-volume-based pricing, multi-channel inbox consolidation, or AI Agent deflection. The answer shapes which data must come with you versus what can stay archived in the source system.
• Define migration scope by object: Tickets, Messages, Customers, Users, Tags, Custom Fields (Ticket + Customer), Macros, Rules, Views, Help Center articles + categories, Voice Calls + Recordings, Widgets. List each object explicitly as in-scope or out-of-scope. Gorgias separates Tickets from Messages (the array of public + internal_note items inside each ticket), so call out both.

  Risk if skipped: Treating Messages as a subordinate field rather than a first-class object causes the public/internal-note polarity to collapse during import.

• Decide historical-data depth for tickets, messages, and call recordings. Gorgias native Zendesk import caps at the most recent 24 months. Pick a hard date floor and document it.

  Risk if skipped: An undefined cutoff lets the import job exceed the planned cutover window by days.

• Pick the Gorgias plan tier — Starter, Basic, Pro, Advanced, or Enterprise. Tickets are billed per-ticket on Starter and Basic and bundled on Pro and above. Email import from Gmail or Outlook is Basic+ only. Confirm the chosen tier covers every channel + feature on the must-have list.

  Risk if skipped: Discovering a feature gap or per-ticket overage exposure after cutover forces an emergency tier upgrade.

• Document compliance posture: SOC 2 Type II, GDPR, DPA execution, EU data-transfer mechanism. Pull the Gorgias Data Processing Agreement and SOC 2 attestation for the security-review file. Confirm the cross-border transfer mechanism for EU personal data before importing customer profiles.

  Risk if skipped: Importing EU personal data without an executed DPA creates a privacy incident on day one.

• Assign a single accountable migration DRI plus named owners for data, channels, automation, and end-user enablement. Capture names, escalation order, and decision authority in one place.
• Define written success criteria. Spell out the row counts, open-ticket counts, Help Center article counts, and Statistics baselines that must reconcile before the migration is declared complete.
• Set the cutover date and the source-system freeze window. Schedule cutover for a low-volume support window away from peak retail moments. Communicate the freeze to the wider team at least two weeks in advance.
• Document explicit out-of-scope items. Examples: spam tickets, deleted tickets, blank tickets, archived KB drafts, social DMs older than the date floor. Recording exclusions kills future scope creep.

  Risk if skipped: Unstated exclusions become last-minute escalations when a stakeholder discovers their data did not arrive.

Phase 1

Pre-Migration Prep

Get the source clean and the Gorgias account ready before any data moves.

Phase 2

Source Export

Get the data out of the source in shapes you can transform.

• Export the full Tickets object from the source as CSV or JSON, including every standard and custom field. Include status, priority, channel, assignee, requester, created_at, updated_at, closed_at, tags, custom field values, and any source identifiers needed as external_id in Gorgias.
• Export the Messages collection per ticket, preserving public-vs-internal polarity and chronological order. Each message needs author, channel, direction (inbound/outbound), sent_datetime, and the public boolean (Gorgias uses public=true for customer-visible, public=false for internal_note).

  Risk if skipped: Losing the public flag during export turns internal notes into customer-visible messages — a privacy incident waiting to happen.

• Export the Customers object with email (primary match key), name, phone (E.164), language, and all custom fields. Include the source customer ID as external_id so upsert keying works on re-runs.
• Export agent / Users with email, name, role, and reporting structure. User exports drive agent-mapping decisions in Phase 3.
• Export Tags as a distinct list with counts. Tag counts confirm taxonomy decisions and surface near-duplicates one last time before import.
• Export Macros from the source with body text, placeholders, and tag associations. Gorgias Macro CSV import accepts four columns (name, body_text, tags, id) and only UTF-8 encoding. Macros are typically rebuilt, not migrated literally — variable syntax differs across platforms.

  Risk if skipped: Importing macros without translating variable syntax produces blank or broken placeholder text on every send.

• Export source automation rules (Triggers, Automations, Flows) as configuration screenshots or JSON. Gorgias splits automation into three engines: Rules (event-driven), AutoResponders (out-of-hours/holiday replies), and Macros (canned responses with variables). All three are rebuilt in Gorgias, not migrated — the export is documentation, not load data.

  Risk if skipped: Treating automation as migratable wastes a week before the team realizes everything must be rebuilt by hand.

• Export Help Center articles, categories, and translations with body HTML, status (draft/published), author, and folder structure. If migrating from Zendesk, HelpDocs, or Re:amaze, Gorgias has a direct importer. From other sources, prepare a CSV per Gorgias's article-import spec. Images and other media are handled separately.
• Export attachments as binary files plus a manifest mapping each file to its ticket and message. Gorgias's ticket message body_text and body_html are capped at 1 MB per message; the cap does not apply to attachments. Keep binaries separate from message bodies.

  Risk if skipped: Embedding base64 attachments inline pushes message bodies over the 1 MB cap and truncates the text content on import.

• Export voice call recordings as audio files with a manifest mapping each recording to its ticket. Voice calls become ticket attachments in Gorgias. Confirm file format and retention policy match the source.
• Capture configuration screenshots of source Views, SLA policies, dashboards, and CSAT survey settings. These are rebuilt in Gorgias's Views, Statistics, and survey integrations — they do not transfer.
• Document the exact UTC timestamp of every export for delta calculation at cutover. The delta between Phase 2 timestamps and the cutover freeze defines what must be re-exported in Phase 5.

Phase 3

Transform & Map

Turn raw exports into Gorgias-shaped payloads.

Phase 4

Sandbox Test Migration

Catch every problem in the sandbox before it costs you in production.

• Load a 1–5% representative sample of each object into the Gorgias sandbox using the chosen import path. Sample must include open and closed tickets, multi-message threads, internal notes, attachments, tagged tickets, and at least one ticket per channel type.
• Validate field-by-field on 10 random sandbox tickets that values arrived correctly. Open each ticket and verify subject, status, requester, assignee, tags, custom fields, and message order.
• Confirm the public-vs-internal polarity on every message in the sample. Spot-check 20 messages flagged internal in the source: are they internal_note (public=false) in Gorgias? Spot-check 20 customer-visible messages: are they public=true?

  Risk if skipped: A polarity bug discovered in production leaks internal commentary to customers on every reopened ticket.

• Test attachment upload and confirm files render in Gorgias ticket view. Test at least one .png, one .pdf, and one large file approaching but under 1 MB body cap.
• Test datetime handling: load tickets with timestamps in the past, near present, and at DST transitions. Verify created_datetime, updated_datetime, and closed_datetime all render correctly in the agent UI and in Statistics.

  Risk if skipped: Hidden timezone bugs surface only at DST boundaries — catch them in the sandbox, not in production.

• Test special characters: emoji, RTL languages, accented characters, em-dashes, CJK characters in subjects and message bodies. Encoding bugs surface here before they hit customer-facing messages.
• Test customer dedup on email match. Import two customers with the same email but different names. Confirm Gorgias merges them and decide which attributes win.

  Risk if skipped: Surprise merges in production overwrite the wrong customer name on the first ticket received post-cutover.

• Time a full-volume sample load and extrapolate to production throughput. Native Zendesk import averages 720 tickets per hour. Multiply your ticket count by your per-ticket work and confirm the result fits in the cutover window.

  Risk if skipped: Discovering the cutover window is too short on the day of cutover forces an emergency reschedule.

• Test Macro CSV import with the four required columns (name, body_text, tags, id) in UTF-8. Confirm tags referenced in the CSV already exist in Gorgias — the import fails silently otherwise.

  Risk if skipped: Missing tags abort the macro import without a clear error and you discover incomplete macro library on first agent shift.

• Test Help Center article import with at least one multilingual article. Confirm translation linkage and folder placement match the source structure.
• Have a senior agent or support lead spot-check 25 random sandbox tickets for correctness. Domain experts catch issues automated reconciliation misses — wrong tag context, ambiguous status mapping, missing custom field values.
• Get written sandbox sign-off from the migration sponsor before proceeding to Phase 5. No production cutover without explicit sign-off on the sandbox results.

Phase 5

Production Cutover

The tightly sequenced execution window.

• Confirm source-system freeze: no new tickets, no agent replies, no admin changes for the agreed window. Verify by checking the source's audit log for activity in the last hour.

  Risk if skipped: Source writes during cutover are invisible to the export and become permanent data loss.

• Take a final full export of source data covering the delta since the Phase 2 baseline. Re-run the same export scripts with a new timestamp filter to capture everything since the last export.
• Disable all destination Rules, AutoResponders, and active integrations on the Gorgias side before loading data. Loading tickets with Rules enabled causes Gorgias to fire customer-facing AutoResponders and agent assignments on every imported ticket — a notification flood.

  Risk if skipped: Forgetting to pause Rules generates thousands of misleading customer emails within minutes of the load starting.

• Load objects in dependency order: Users → Customers → Tags + Custom Fields → Tickets → Messages → Attachments. Parent objects must exist before children. Gorgias rejects ticket creation against a non-existent customer.
• Use idempotent upserts keyed off external_id (Tickets) and email (Customers) on every load. If a step fails partway, re-running with the same keys updates instead of duplicating.

  Risk if skipped: Non-idempotent loads duplicate every record on retry and the only fix is a full account reset.

• Capture import job IDs, row counts, and full error logs for every load step. Logs become the audit trail for the Phase 6 reconciliation.
• Cross-check destination row counts against source row counts after each step before moving to the next. Catch shortfalls before they compound across multiple object types.
• If a load step fails partway: stop, diagnose, fix the transform, re-run idempotently. Do not push through with partial data — partial loads create corrupt customer histories.
• Re-enable Rules, AutoResponders, and integrations only after all data loads complete and Phase 6 reconciliation begins. Confirm by checking the Settings → Rules toggle and the Channels status page.

Phase 6

Validate

Prove correctness before letting agents into the destination.

Phase 7

Post-Migration Cleanup

Close out the project and decommission the source.

• Announce go-live to all agents with login URL, training resources, and the first-responder escalation contact. Pin the announcement in the team chat for the first 14 days.
• Run final role-based training sessions: Agents, Admins, Reporting users. Pull from Gorgias Academy plus account-specific recordings of the rebuilt workflows.
• Set the source system to read-only and announce the read-only date to the team. Read-only state preserves the source for forensic lookup while preventing accidental writes that would diverge from Gorgias.
• Rebuild Statistics views, dashboards, and saved reports in Gorgias. Gorgias's Statistics + Performance + Revenue Tracking dashboards do not transfer from the source — rebuild against the migrated data.

  Risk if skipped: Without rebuilt dashboards, leadership has no visibility into the new system and falls back to source reports that no longer match reality.

• Re-establish all third-party integrations: Klaviyo, Yotpo, Recharge, Aircall, custom integrations. Each integration is reinstalled from Gorgias App Store or rebuilt as a custom integration in Settings → Integrations.
• Decommission any source-side integrations to avoid duplicate notifications or auto-replies. Disable each source-side Shopify, email, or chat integration explicitly — do not assume disabling the source app suffices.

  Risk if skipped: An orphaned source-side integration keeps firing for weeks and fragments customer history across both platforms.

• Schedule a 30-day post-migration retrospective with the migration team. Capture what went well, what surprised the team, and what to do differently next time.
• Document the source-system decommission date (typically 90 days after cutover). Decommission must come after the last retention window closes. Confirm with legal and finance that no compliance hold blocks decommission.
• Archive the source-system data exports to long-term cold storage. Tickets, customers, audit log, attachments, and CSAT history — all archived in case of later forensic need.
• Archive the source audit log separately, given the Gorgias 12-month audit retention limit. The audit log is the only artifact that cannot be reconstructed later — store it on durable, access-controlled storage.

  Risk if skipped: Losing the source audit log eliminates the only record of who did what before cutover.

• Close out the migration project formally: final status report, lessons learned, project closure memo. File alongside the sponsor sign-off and the reconciliation report.