Migrate from Zammad to Intercom

Zammad Tickets map to Intercom Conversations. The ticket title becomes the conversation subject, ticket state (new/open/pending/closed) maps to Intercom conversation state (open/closed/snoozed), and priority maps to a custom conversation attribute. The complete article thread (internal and external notes, email replies, chat messages) migrates as message records in Intercom's conversation timeline. Zammad's time entries are flagged as immovable—Intercom has no time tracking equivalent, and Zammad does not allow post-creation editing, so time entries are documented in a separate audit report rather than migrated.

Zammad Agents map to Intercom Teammates. Role assignment (Agent vs Admin) translates to Intercom's teammate permission model: Agents with full ticket access map to Teammates; Agents with admin panel access map to Admins. We resolve by email match and flag any Zammad Agents without a corresponding Intercom teammate account for the customer's admin to provision before production migration. Password migration is not supported; we set temporary passwords for all migrated teammates.

Zammad Customers map to Intercom Contacts. The Zammad user email becomes the primary identifier; phone numbers migrate with validation (Intercom enforces phone format validation—invalid phone numbers cause record rejection and must be corrected or removed before migration). Custom Object attributes attached to Zammad Users map to Intercom Custom Attributes on the Contact, but Fin AI Agent cannot query custom attributes directly, so the customer should plan AI routing rules around Intercom's standard contact attributes rather than migrated custom fields.

Zammad Organizations map to Intercom Companies. The Organization name becomes the Company name, domain is extracted and set as the Company domain, and Organization membership links (which Zammad Users belong to which Organization) migrate as Company relationships on the corresponding Intercom Contacts. A Zammad User can belong to multiple Organizations; Intercom's Company model allows a Contact to belong to multiple Companies, so we preserve the many-to-many relationship using Intercom's multiple-company association.

Zammad Groups (which control ticket assignment and agent access) map to Intercom Teams. The Group name becomes the Team name, and Group membership (which Agents belong to which Group) maps to Team membership in Intercom. Zammad's default Groups (Users, First Level Support) become default Inboxes in Intercom. Group email addresses migrate as Inbox email addresses in Intercom. Any routing rules in Zammad that reference specific Group IDs require re-mapping to Team IDs post-migration.

Zammad Tags are flat key-value labels attached to Tickets. They map to Intercom Labels on Conversations. Zammad's flat tag taxonomy maps directly to Intercom's label model—there is no tag hierarchy in either platform. We migrate all tag associations and create corresponding Labels in Intercom. Tags that were used for internal classification rather than customer-facing labeling should be noted during scoping so the customer can decide whether to preserve them in Intercom or archive them.

Zammad Knowledge Base articles migrate to Intercom Help Center articles within the customer's Intercom workspace. Article content, category assignments, and multi-language locale tags transfer directly. Article visibility settings (internal vs external) require review: Zammad uses separate internal and external Knowledge Base categories, while Intercom uses a single Help Center with draft/published states. Articles in multiple languages require matching locales to be configured in Intercom Help Center before migration.

Zammad SLAs define response and resolution time commitments tied to calendars and ticket priorities. Intercom does not have a native SLA object—SLA compliance is handled through Workflows with time-based conditions and manual tracking. We document every Zammad SLA configuration (calendar bindings, business hours, escalation rules, priority mappings) in a written SLA inventory so the customer's admin can rebuild equivalent SLA tracking using Intercom Workflows and the SLA clock metric. This is a manual rebuild item, not a data migration.

Zammad Custom Objects attached to Tickets (Boolean, Date, DateTime, Integer, Float, Text, Single Select, Multi Select, User Reference, Organization Reference) map to Intercom Conversation Custom Attributes. The attribute type maps to the closest Intercom type (Zammad Single Select becomes Intercom String or option set; Zammad Multi Select becomes Intercom String array). Note that Fin AI Agent cannot query custom attributes directly, so if the customer relies on AI routing based on custom object values, this constraint must be addressed in the Intercom configuration plan before migration.

Attachments on Zammad ticket articles (with content-type, filename, and size preserved) migrate as Intercom conversation attachments. Zammad's default 10 MB attachment limit on Starter maps to Intercom's attachment limits (100 MB on Starter). Large attachments over Intercom's limit are flagged and archived separately. Inline images within article body text migrate as embedded assets in the Intercom message.