Migrate from Zendesk to Gorgias

Zendesk Tickets map to Gorgias Tickets with a critical status transformation. Zendesk's six statuses (New, Open, Pending, On-Hold, Solved, Closed) collapse to Gorgias's two: Open means the ticket needs attention, Closed means the team is done. We map New, Open, Pending, and On-Hold to Open in Gorgias; Solved and Closed map to Closed. For Pending tickets, we apply a pending tag during migration so the customer's admin can create a Gorgias View to surface those tickets without rebuilding from scratch. Comments, internal notes, and channel origin (email, chat, Facebook, Instagram) transfer with the ticket. Attachments do not transfer via native import and must be reattached manually or via a post-migration script.

Zendesk End-Users (requesters) map directly to Gorgias Customers by email address as the dedupe key. User attributes (name, email, phone, external_id) transfer. Custom user fields migrate to Gorgias custom fields if the destination schema is pre-created. Users in Zendesk without any ticket activity (no ticket as requester or commenter) are not imported by Gorgias; we identify these orphaned users during scoping and present them as a separate list for the customer to decide whether to create them manually post-migration.

Zendesk Agents map to Gorgias Users. We map by email address with role preservation: Zendesk Admin maps to Gorgias Admin, and Zendesk Agent maps to Gorgias Agent. Role names differ — Gorgias does not use Zendesk's light-agent concept. If the customer uses light agents in Zendesk (agents with restricted view access but no ticket assignment), we flag this during scoping and discuss whether those users should map to Gorgias Agent or remain as a customer-side permission group to configure post-migration.

Zendesk Organizations map to Gorgias Customers at the organization level. The Zendesk organization domain name becomes the Customer's domain field in Gorgias. Users in Zendesk belonging to an Organization inherit that relationship in Gorgias via the customer's organization_id field. Cross-references between Organizations and their member Users are preserved through a lookup table we build during extraction.

Zendesk Brands (multi-brand support, Enterprise-only, up to 300 brands) do not have a direct equivalent in Gorgias, which is single-brand. We map all Zendesk Brands into a single Gorgias Team structure. During scoping, we identify which brand each ticket belongs to and tag tickets with the original brand name. The customer decides whether to route brand-specific tickets using tags in Gorgias or to maintain separate Gorgias accounts per brand as a workaround. This is one of the highest-impact gaps in the migration scope.

Zendesk Macros migrate to Gorgias Macros, but only the reply text and status change action types transfer. Any Zendesk Macro that includes field updates, assignee changes, group changes, tag additions, or conditional branching imports with an empty actions list. We audit the full macro library before migration, separate supported from unsupported macros, and flag unsupported macros in the migration inventory. Macros cannot be edited in Gorgias while the sync is active — the Zendesk original overrides any edits. We pause the sync before post-migration cleanup.

Zendesk Tags map to Gorgias Tags on a one-to-one basis. Tags that appear on no tickets in the import window are not imported — only tags applied to tickets within the two-year history window transfer. We preserve tag names exactly, including any naming collision handling (prefix deduplication if the same tag name exists in Gorgias). Tags used for brand routing in multi-brand Zendesk accounts transfer as plain string tags and are not automatically reorganized.

Zendesk Ticket Custom Fields map to Gorgias Custom Fields. The Gorgias API supports external_id for mapping back to the source system ID. If the customer has more than 500 ticket fields in Zendesk, Gorgias will not import them automatically — we handle this by extracting field definitions via the Zendesk API, creating matching custom fields in Gorgias via the API, and mapping values during ticket import. Managed field types (contact_reason, satisfaction_rating) are preserved as Gorgias managed types. Free-text, numeric, boolean, and date field types map to their Gorgias equivalents.

Zendesk Views are saved ticket filters with conditions, columns, and sort order. Gorgias Views serve the same purpose but use different condition syntax. We export every Zendesk View definition as structured JSON, translate the condition operators to Gorgias syntax (Zendesk uses 'is', 'contains', 'is not'; Gorgias uses different operator names), and deliver a written view recreation guide. Views cannot be imported automatically. This is manual post-migration work guided by the inventory document we produce.

Zendesk Triggers fire immediately on ticket events (created, updated, specific field change) and reference ticket fields, user fields, and conditions to execute actions (notify, add tag, assign). Gorgias Rules serve a similar purpose but use a different event model and action set. Triggers do not migrate as code. We export every active Trigger definition and deliver a written inventory with each Trigger's event, conditions, actions, and a recommended Gorgias Rule equivalent. The customer's admin rebuilds Rules post-migration based on this guide.

Zendesk Automations are time-based, running hourly on up to 1,000 tickets per batch with a 500-active-automation cap. Gorgias Rules are event-triggered rather than time-based, and Gorgias does not have an equivalent to Zendesk's hourly batch automation model. Automations do not migrate as code. We export every active Automation definition and deliver a written inventory with each rule's time condition, ticket criteria, and actions. For rules that depend on time delays (follow-up reminders, escalation timers), we recommend Gorgias's Snooze and Schedule features as the functional replacement and document the gap.

Zendesk SLA Policies define first-response and resolution targets by plan or ticket type. On Enterprise, SLAs are fully configurable; on lower tiers, SLA management is gated. Gorgias has SLA policy support at all paid tiers but uses a simpler model without the same plan-level granularity. We migrate SLA definition records (target hours, business hours configuration, holidays) as structured data, but the customer's admin applies them to tickets or ticket types in Gorgias post-migration. SLA breach notifications migrate as Rule equivalents in Gorgias.

Zendesk Help Center articles in Sections and Categories map to Gorgias Help Center articles. Zendesk does not offer a native full-KB export — we use the Help Center API endpoints to iterate over sections and articles, download HTML content and attachments, and reconstruct the KB structure in Gorgias. Dynamic Content items (multilingual variants) are pulled separately and mapped to Gorgias locale fields. This object is out of scope for Gorgias's native import tool and requires custom extraction and insertion work.

Zendesk ticket and Help Center attachments download via the API and re-upload to Gorgias. The Gorgias native import tool does not transfer attachments. We preserve attachment filenames, MIME types, and download URLs during extraction, and we provide a post-migration attachment script that re-uploads files to the matching Gorgias tickets and articles. The customer's admin can run this script post-migration, or we include attachment re-upload as an optional add-on scope.

Zendesk Dynamic Content holds multilingual placeholder-based text for macros and auto-replies. It is only available on Growth, Professional, and Enterprise plans. We export Dynamic Content items with their locale variants and map them to Gorgias's multi-language template structure. Placeholder syntax differs — Zendesk uses {{dc.name}} and Gorgias uses {{ticket.custom_field}} syntax, so we deliver a placeholder translation guide alongside the migration.