Migrate from Zammad to HubSpot Service Hub

Zammad Tickets map directly to HubSpot Tickets with state (open, pending, closed), priority (low, normal, high, urgent), and owner preserved. The full article thread (emails, chat logs, notes, public replies, internal notes) migrates as HubSpot Ticket Conversations. Zammad's ticket number becomes the ticket ID in HubSpot. Tags on the Zammad ticket transfer to HubSpot Ticket Labels. Group assignment on the Zammad ticket maps to the HubSpot Inbox routing.

Zammad Agents map to HubSpot User records. We resolve by email match. Agents without a matching HubSpot User go to a reconciliation queue for the customer's admin to provision before record import. Zammad role permissions do not map to HubSpot Roles because HubSpot's permission model uses Roles, Teams, and Individual-level overrides differently; we deliver a Zammad role-to-HubSpot-permission mapping document for the admin to configure post-migration.

Zammad Customer records (the end-user who submits tickets) map to HubSpot Contacts. The Zammad customer's email, name, phone, and organization membership transfer to HubSpot Contact properties. Zammad's Customer users do not become HubSpot Users because HubSpot User seats are for agents, not end-users.

Zammad Organizations map to HubSpot Companies. Organization domain, name, note, and member Users transfer. A User can belong to multiple Organizations in Zammad; HubSpot Companies support multiple contacts, but the many-to-many relationship requires a junction approach if the customer needs dual-company associations. We flag this during scoping and default to a primary-company assignment with secondary associations stored in a custom field-contact field.

Zammad Groups map to HubSpot Inboxes (for email routing) and HubSpot Teams (for agent access control). The Group's email address becomes the routing address on the HubSpot Inbox. Group members (agents) are assigned to the corresponding HubSpot Team. Zammad's assignment rules (ticket routing to Groups) become HubSpot Inbox routing rules. Default Groups like 'Users' and 'First Level Support' require customer guidance on which HubSpot Inbox to map to.

Zammad Tags (flat key-value labels on Tickets) map to HubSpot Ticket Labels. Labels in HubSpot attach to ticket records and can be used for filtering, reporting, and workflow triggers. Zammad tag associations migrate as label assignments on each ticket.

Zammad SLAs define response and resolution time commitments tied to Calendars. HubSpot Service Hub Professional and Enterprise include SLA Policies with First Response and Next Response SLA targets. We map Zammad SLA configurations to HubSpot SLA Policies, converting the calendar-based business hours to HubSpot Business Hours. First Response SLA from Zammad maps to HubSpot First Response SLA; Resolution Time SLA maps to Time to Close SLA. Starter tier lacks SLA Policies; we flag this gap during scoping.

Zammad Calendars defining business hours migrate to HubSpot Business Hours. Working days, timezone, and holiday schedules transfer. Calendars must exist in HubSpot before SLAs that reference them are created. We create HubSpot Business Hours during the schema phase.

Zammad Custom Objects extending Tickets, Users, Organizations, and Groups migrate to HubSpot Custom Objects (Professional tier and above) and Custom Properties on standard objects. We pre-create the destination schema via HubSpot's API including field types, picklist values, and lookup relationships. Zammad's Boolean, Date, DateTime, Integer, Float, Text, Single Select, Multi Select, and User Reference types map to their HubSpot equivalents. Lookup relationships to other custom objects require pre-creation of the target schema.

Attachments on Zammad ticket articles migrate as HubSpot Files attached to the parent Ticket record via ContentDocumentLink. Content-type, filename, and size are preserved. We chunk large attachment batches (over 50 GB total) into sequential API calls respecting HubSpot's per-second rate limits. Inline images embedded in ticket articles migrate as separate Files.

Zammad Knowledge Base articles migrate as HubSpot Knowledge Base articles with title, body content, and category assignments preserved. Zammad article visibility settings (internal vs. external) do not map directly to HubSpot's portal visibility model; we flag these for admin configuration. Multi-language Zammad articles with locale tags require the destination HubSpot Knowledge Base to have matching language settings enabled.

Zammad Triggers automate actions based on ticket conditions and migrate as a written inventory document for HubSpot rebuild. Zammad trigger conditions referencing custom Objects map to HubSpot Workflow triggers on custom property values. We document the trigger name, conditions, operators, and action set for the admin to recreate in HubSpot Workflows. Active/inactive status is noted for the admin to apply during rebuild.

Zammad Macros bundle ticket updates and article templates for quick agent responses. We document Macros with their action sets, template content, and Group ID references for the admin to rebuild as HubSpot Snippets and Shared Inbox macros. Zammad macro-specific ticket field updates map to HubSpot workflow-triggered property updates.

Zammad Text Modules are reusable response templates with multi-language support. We document Text Module content, language tags, and usage counts for the admin to recreate as HubSpot Snippets. The destination must have matching locale configurations.