Migrate your Zammad data

Tickets are Zammad's primary object. We migrate full ticket records including state, priority, group assignment, owner, customer, organization, tags, and the complete article/thread history. Attachments are downloaded and re-uploaded. Time entries associated with tickets are preserved as Zammad time accounting records.

Zammad differentiates Agents and Customers. We map source contacts to Zammad Users, preserve role assignments (Agent vs Customer), and handle password hashing by setting temporary passwords during migration. Email addresses must be unique and are validated against Zammad's user schema.

Organizations in Zammad group related Users. We migrate Organizations and preserve their membership links to Users. Organization-level custom Objects are mapped. Note that a User can belong to multiple Organizations in Zammad, which not all source systems support.

Groups control ticket assignment and agent access. We migrate Groups with their email addresses, assignment rules, and active/inactive status. Default Groups like 'Users' and 'First Level Support' are created on fresh installs and we preserve those while mapping custom Groups.

Roles define permissions for Agents. We migrate custom Roles and their permission sets. System roles like 'Agent' and 'Admin' are preserved. Permission granularity is preserved but we flag any role configurations that may not map 1:1 if the destination system has different permission models.

Tags in Zammad are flat key-value labels attached to Tickets. We migrate all Tags and their ticket associations. Tags are preserved as-is; there is no tag taxonomy or hierarchy in Zammad.

SLAs define response and resolution time commitments tied to calendars and ticket priorities. We migrate SLA configurations including calendar bindings, business hours, and escalation rules. SLA-to-priority mappings are preserved.

Zammad's Knowledge Base stores internal and external articles organized by categories and translations. We migrate articles and their category assignments. However, article visibility settings (internal vs external) and translation completeness vary by source system and require manual review post-migration.

Triggers automate actions based on ticket conditions. We migrate Trigger configurations including condition operators and action sets. Some trigger conditions referencing custom Objects may not map directly if the destination system uses different object types.

Macros bundle ticket updates and article templates for quick agent responses. We migrate Macros and their action sets. Macros referencing specific Group IDs or User IDs require re-mapping to destination Group/User IDs.

Text Modules are reusable response templates. We migrate Text Modules and their content. Multi-language Text Modules are preserved with language tags, but the destination must have matching locale configurations.

Custom Objects extend Tickets, Users, Organizations, and Groups with custom fields. Supported types include Boolean, Date, DateTime, Integer, Float, Text, Single Select, Multi Select, User Reference, and Organization Reference. We map custom field values field-by-field. We flag Object types that cannot be changed after creation and recommend disabling rather than deleting unused Objects.

Attachments on ticket articles are migrated with their content-type, filename, and size preserved. Large attachments up to Zammad's configurable limit (default 10 MB on Starter, configurable on higher tiers) are migrated. Files exceeding destination limits are flagged for manual handling.

Calendars define business hours for SLA calculations. We migrate Calendar configurations including working days, timezone, and holiday schedules. Calendars must be created before SLAs that reference them.