Migrate from Zammad to Freshdesk

Discovery and plan confirmation

We audit the Zammad instance for ticket volume, user counts (Agents and Customers), organization count, tag inventory, SLA configurations, knowledge base articles, and custom Object definitions. We confirm the Freshdesk target plan — specifically whether it includes API access (Blossom or above required) and the applicable rate-limit ceiling. We also review Zammad's agent tier (Starter cap at 5, Professional cap at 35) to flag any agent-count risk. The discovery output is a written scope and a pre-flight checklist naming every Freshdesk object that must be provisioned before migration begins.

Freshdesk schema pre-provisioning

We deliver a schema pre-provisioning checklist to the customer before migration. This includes: Groups matching the Zammad group structure, Companies (from Zammad Organizations) pre-created or mapped during import, custom ticket fields matching Zammad custom Object field types (or flagged for conversion), SLA Policies configured per the Zammad SLA mapping matrix, and knowledge base categories matching Zammad article categories. The customer provisions these in Freshdesk while we build and validate the migration pipeline against a Freshdesk trial account.

Migration pipeline build and sandbox validation

We build the extraction pipeline against Zammad's REST API (pagination, rate-limit handling, attachment streaming) and the load pipeline into Freshdesk's REST API (batch chunking, parent-record lookup, dedupe). We run a sandbox migration using a representative sample — typically 100-200 tickets with attachments, time entries, and custom field values — and deliver a reconciliation report comparing source counts against destination counts. Mapping corrections happen here, not in production.

Time-entry pre-flight review

We extract every Zammad ticket that contains a time entry and deliver a time-entry report to the customer. The customer reviews and corrects any erroneous time entries in Zammad before migration. Once extraction begins, Zammad data is read-only in our pipeline — we do not write back to Zammad. Corrections after extraction pass begins will not be picked up unless a second extraction pass is scheduled, which extends the timeline.

Production migration in dependency order

We run production migration in record-dependency order: Groups (created in Freshdesk first), then Agents (provisioned in Freshdesk with a reconciliation queue for unmapped owners), then Companies (from Zammad Organizations), then Contacts (from Zammad Customers with company links resolved), then Tickets (with requester, owner, group, tags, and article history), then Tags, then SLA mappings, then custom Object records. Each phase emits a row-count reconciliation report before the next phase begins. API rate-limit handling and exponential backoff run throughout.

Cutover, validation, and automation inventory handoff

We freeze Zammad writes during cutover, run a final delta pass of any records modified during the migration window, then confirm Freshdesk as the system of record. We deliver a full reconciliation report (source vs destination counts per object), a Zammad-to-Freshdesk ID mapping table, and a written inventory of every Zammad Trigger, Macro, Text Module, and Scheduler with its trigger conditions and recommended Freshdesk Automation Rule equivalent. We do not rebuild Zammad automations as Freshdesk automations inside the migration scope; that is an admin task or a separate engagement.