Migrate from Zammad to Gorgias

Zammad Tickets map directly to Gorgias Tickets. The full article thread — customer replies, agent responses, internal notes, and attachments — migrates as message records on the ticket in chronological order. Zammad ticket state (new, open, pending, closed) maps to Gorgias ticket status (new, open, pending, resolved, closed). Priority mapping preserves Zammad's low/normal/high/very high priority tiers as Gorgias priority values.

Zammad Agent records map to Gorgias Agents. We resolve by email address as the dedupe key. Agent role and permission sets from Zammad (Agent, Admin, Manager) do not have direct Gorgias equivalents for granular permissions, so we preserve the role name in a custom field on the Agent record. Any Zammad Agent without a matching Gorgias user goes to the reconciliation queue for the customer's admin to provision before record migration resumes.

Zammad Customer records map to Gorgias Customers. The Zammad customer email becomes the primary identifier. We also migrate customer phone, language, and timezone where populated. Customer data from Zammad that does not map to a standard Gorgias Customer field migrates into custom fields on the Customer record.

Zammad's native Organization object has no direct Gorgias equivalent. We store the Organization name as a text custom field on the Gorgias Customer record. If the customer relies on Organization-to-User membership for reporting or filtering, we also map the Organization membership as a tag on each Customer (e.g., tag 'Acme Corp Member') so that Gorgias's tag-based filtering can replicate the Organization grouping logic. The customer chooses the tagging strategy during scoping.

Zammad Groups map to Gorgias Teams. The Group's email address and assignment rules migrate as Team settings in Gorgias. Group membership (which agents belong to which groups) translates to Team membership in Gorgias. Default Groups like 'Users' and 'First Level Support' require manual deactivation or renaming in Gorgias if they do not match the customer's team structure.

Zammad Roles with granular permission sets do not map to a native Gorgias role model. We preserve role names as a custom field on the Gorgias Agent record and document the permission mapping as a written handoff. The customer's admin reviews the documentation and assigns Gorgias roles (Admin or Agent) manually after migration. Zammad's custom role permission sets require a manual reconfiguration in Gorgias's settings.

Zammad flat tags on Tickets migrate to Gorgias labels on the corresponding ticket. Tags are preserved as key-value labels with no taxonomy or hierarchy in either platform. If tags were used to encode organizational membership (see Organization mapping), those tag strings are preserved and used for the tag-based grouping strategy in Gorgias.

Zammad SLA configurations — response time and resolution time commitments tied to calendars and ticket priorities — require manual reconfiguration in Gorgias because SLA rules in Gorgias are structured differently. We extract the Zammad SLA definitions (escalation rules, calendar bindings, business hours) as a written specification document. Gorgias SLA features are available on Pro and above. The customer's admin rebuilds the SLA rules in Gorgias using the specification as a blueprint.

Zammad Calendars defining business hours for SLA calculations migrate as written specifications. Gorgias Business Hours are configured separately from SLA rules and do not have a direct API import path. We document the calendar working days, timezone, and holiday schedules as a configuration guide. The customer's admin applies the settings in Gorgias Settings > Business Hours.

Zammad Custom Objects attached to Tickets, Users, Organizations, and Groups migrate as custom fields on the corresponding Gorgias record type. Supported Zammad attribute types — Boolean, Date, DateTime, Integer, Float, Text, Single Select, Multi Select — map to Gorgias custom field equivalents where types exist. Types that do not have a direct Gorgias equivalent (such as User Reference or Object Reference) are stored as text fields with the referenced value string preserved. We flag any custom object definitions that reference disabled-not-deleted Zammad attributes and recommend excluding them from migration.

Zammad Triggers automate actions based on ticket conditions and do not migrate as automation code to Gorgias. We extract every active Trigger with its condition operators and action set as a written inventory document. Each trigger maps to a Gorgias Rule with the equivalent condition and action logic. The customer's admin reviews the inventory and rebuilds triggers as Gorgias Rules. We flag any triggers that reference custom Object Attributes that could not be migrated due to type limitations.

Zammad Macros bundle ticket updates and article templates for quick agent responses. We migrate the macro content — reply text, subject line changes, status changes, and field updates — as Gorgias Macros. Macros with actions referencing specific Zammad Group IDs or User IDs require remapping to Gorgias Team and Agent IDs during migration. Macros referencing deleted or disabled Zammad attributes are flagged for the customer's admin to review before activation.

Zammad Text Modules (reusable response templates with variable placeholders) migrate as Gorgias Templates. We preserve multi-language Text Modules with their language tags, but the destination must have matching locale configurations in Gorgias. Text Modules with unsupported variables (Zammad-specific system variables not available in Gorgias) are flagged with a note on the equivalent Gorgias variable to use instead.

Attachments on Zammad ticket articles migrate to the corresponding Gorgias ticket as file attachments. We preserve the original filename, content-type, and file size. Attachments exceeding Gorgias's file size limits are flagged before migration, and the customer decides whether to compress, split, or exclude oversized files. The attachment migration runs as part of the ticket article migration phase.

Zammad Knowledge Base articles (internal and external) migrate to Gorgias Help Center as articles within matching categories. Article visibility settings from Zammad — internal-only versus public — require manual reconfiguration in Gorgias because visibility is handled through Help Center publication settings rather than per-article flags. We migrate the article content and category structure; the customer's admin configures publication status post-migration.