If your support team is moving off Zendesk's per-agent pricing, the question that decides whether the move is easy or painful is not the software, it is the history. Years of tickets, the customers attached to them, and the workflows your agents lean on every day. This guide is for teams considering Zammad who want to know, before committing, exactly what a migration moves, what it does not, and how long it takes.

The honest headline: Zammad ships a built-in Zendesk migrator, so this is a well-trodden path rather than a bespoke project, and when you take Zammad as a managed service from Node, running that migration is part of the service, not a paid extra. But "built-in migrator" is not "everything moves". Here is the full picture, with sources.

What moves, what needs care, what does not carry over

Moves cleanly. The official Zammad migration documentation covers groups, organisations, users and tickets. Tickets arrive with their complete conversation history, including attachments, and the importer maps your Zendesk ticket, user and organisation fields onto Zammad's custom object attributes, so custom data fields survive the move rather than being flattened away.

Needs care. Import speed is bounded by Zendesk's API rate limits, which vary by Zendesk plan, so a large helpdesk takes real elapsed time (more on timelines below). The importer also runs as a full import each time: differential imports are not supported, so you cannot migrate most of the history early and top up the difference later. That shapes how the cutover is planned, not whether it works. One documented oddity worth knowing: objects with Cyrillic names cannot be migrated and need renaming first.

Does not carry over. Three things, and we would rather you hear them now than after signing:

  • Passwords. User passwords do not migrate; the documentation is explicit about it. Everyone either resets their password on first login or, better, never needs one: on our platform we wire Zammad into Keycloak single sign-on as standard, so agents sign in with your organisation's identity and the missing passwords are simply irrelevant.
  • Macros, triggers, automations and views. The importer moves data, not configuration. Zammad has strong equivalents (triggers, scheduled jobs, macros and overviews), but they are rebuilt, not converted. In practice this is often a feature: most helpdesks accumulate years of dead automation, and rebuilding only what you still use leaves you with a cleaner system.
  • Zendesk Guide content. Your knowledge base articles are outside the importer's scope. Zammad includes its own knowledge base, and articles need re-creating in it. For a handful of articles that is an afternoon; for hundreds it is a scoped piece of work we agree with you up front rather than discovering halfway through.

How we run it

Migration is part of the managed service, and it follows the same shape every time.

Scoping. We look at your Zendesk together: ticket volume, custom fields, the automation you actually use versus the automation that exists, and what Guide content matters. This is where the honest conversation about rebuild effort happens.

Credentials. The migrator connects to Zendesk with an API token generated by a full administrator account (a lesser-privileged token produces a broken migration, per the documentation), so we set that up with you and treat it like any other secret.

Trial import. We deploy your Zammad instance on UK infrastructure and run a first import against your live Zendesk. The importer only reads from Zendesk, so the source is untouched and your team keeps working normally. The trial tells us real import duration on your plan's rate limits and surfaces any data quirks while nothing is at stake.

Rebuild and SSO. While imports run, we rebuild the automation you decided to keep, configure email channels and deliverability (SPF, DKIM, DMARC), and connect Keycloak single sign-on so agents have working logins from day one despite the password limitation.

Verification. After the full import we check the migrated data against the source: ticket counts per group and state, user and organisation counts, spot checks on conversation history and attachments. You review it with us; nothing proceeds on our say-so alone.

Cutover. Because differential imports are not supported, we schedule the final full import close to the switchover, then repoint your inbound channels (support addresses, web forms, chat) at Zammad. Zendesk stays read-only-in-practice as a fallback.

Decommission. Your Zendesk subscription is cancelled only when you confirm you are done with it, never on our initiative. Until then it costs you one more billing cycle and buys certainty, which is usually a good trade.

Doing it yourself

Fair is fair: you do not need us for this. The migrator is part of Zammad itself, offered during initial setup, and the official documentation walks through it. You will need a Zendesk plan with API support, a full administrator API token, somewhere production-grade to run Zammad, and realistic expectations about the rate limits. The parts the tooling does not cover are the parts this guide has already listed: rebuilding automation, moving Guide content, and wiring up authentication. If you go the DIY route, budget most of your time for those, not for the import itself.

Preparation checklist

Whether we run it or you do, the same homework pays off:

  • Audit your automation. List your macros, triggers, automations and views, and mark which ones fired in the last quarter. Rebuild only those.
  • Audit your custom fields. Ticket, user and organisation fields all map across; fields nobody has filled in for two years are better retired than migrated.
  • Decide what history matters. All-or-nothing is the importer's model, but knowing what you actually need protects the verification stage from arguing about data nobody uses.
  • List your integrations. Anything talking to Zendesk's API (CRM sync, reporting, internal tools) needs an equivalent against Zammad's API, and that is scoping work, not import work.
  • Inventory Guide content. Count the articles worth keeping so the knowledge base rebuild is a plan rather than a surprise.

Timelines, honestly

We do not promise dates a rate limit can break. The import runs at whatever pace your Zendesk plan's API limits allow, which the Zammad documentation itself flags as the dominant factor. A small helpdesk with a few thousand tickets typically imports within hours. A large one, with years of attachment-heavy history on a lower-tier Zendesk plan, can take days of elapsed time. The saving grace is that elapsed time is cheap: Zendesk stays live throughout, the import runs unattended, and the only genuinely scheduled moment is the final import and channel cutover, which we plan around your quiet hours.

What you end up with

At the end you have your support history, on UK infrastructure, in an isolated tenant, in a database you can query and export, under a UK GDPR Article 28 data processing agreement, with no per-agent licence anywhere in the bill. The ongoing service is the same flat fee that covered the migration: hosting, upgrades, backups, monitoring, deliverability and SSO, run by the two named engineers who operate the platform. For the cost comparison against Zendesk's per-agent pricing, see Zammad vs Zendesk; for what the service includes, see Hosting for Zammad; for current figures, the pricing page. And if your team is two agents on Zendesk's cheapest plan, we will tell you the migration is not worth it, because sometimes it is not.

Frequently asked questions

Does our helpdesk stay live during the migration?

Yes. The importer reads from Zendesk over its API and writes nothing back, so your team keeps working in Zendesk throughout. Because Zammad does not support differential imports, tickets raised after an import run are not topped up automatically; we time the final full import close to the cutover so the gap is as small as possible, and agree how any stragglers are handled.

Do agents lose their ticket history?

No. The importer brings your tickets across with their full conversation history, including attachments, alongside users, organisations and groups. Your Zendesk ticket, user and organisation fields are mapped onto Zammad's custom object attributes, so the context agents rely on comes with them.

What happens to passwords and logins?

Zendesk passwords do not migrate; that is a documented limitation of the importer, not something a migration partner can work around. On our platform it barely matters, because we wire Zammad into Keycloak single sign-on as standard, so agents sign in with your organisation's identity rather than a helpdesk-specific password. Anyone using local accounts instead simply resets their password on first login.

What does the migration cost?

Nothing on top of the flat tier. Migration is part of the managed service, not a billable project: you pay the flat monthly fee for the Zammad deployment (from £25 a month at the time of writing) and we plan, run and verify the import within it. Current figures are on our pricing page.

How long does a Zendesk migration take?

It depends on your ticket volume and your Zendesk plan, because import speed is bounded by Zendesk's API rate limits. A small helpdesk can import in hours; a large one with years of history can take days, and no tool changes that. Because the import runs in the background while Zendesk stays live, the elapsed time costs you little.

What about our macros, triggers and Zendesk Guide articles?

They do not migrate. The importer's scope is data (users, organisations, groups and tickets), not configuration or knowledge base content. We rebuild your automation in Zammad's triggers, schedulers, macros and overviews during setup, and your Guide articles need re-creating in Zammad's own knowledge base, which we scope with you honestly before anything moves.

Could we run the migration ourselves instead?

Yes. The migrator is built into Zammad's setup wizard and documented by the project; you need a self-hosted Zammad, a full administrator API token, and patience with rate limits. If you would rather own the whole process, the official documentation is good. What we add is the production platform around it: hosting, SSO, deliverability, verification and a tested cutover plan.