Migrate from Zendesk to Zammad

Migrate from Zendesk to Zammad: what the move involves

If your Zendesk renewal, data residency rules or lock-in concerns are pushing you toward a self-hosted help desk, Zammad's built-in Zendesk migrator can bring tickets and users across. The gaps you must plan for are user passwords, which are not migrated, and differential syncs, which are not supported, so the move is a one-time, all-or-nothing import rather than a rolling copy. Zammad is licensed under the GNU AGPLv3 and its source code is owned by the Zammad Foundation, so the software itself carries no license fee. What you pay for is planning and execution, and that work is usually done by an internal administrator with an implementation partner who handles hosting, configuration and testing.

The migrator only runs on a new Zammad instance, not one that already holds live tickets, and it accepts one source system per migration. Plan the target environment first, then decide the cutover window, because a migration that goes wrong cannot be patched into place on a running system. The migrator needs a Zendesk API token created by a full administrator, so confirm which person on your side holds that role and that the account can be used for the import. Effort and risk depend mainly on ticket volume, attachment size, custom fields, macros, triggers and how many agents must be re-enrolled with new credentials. Ask Zammad and your partner to confirm the current migration steps and any environment prerequisites before you commit to a date.

Treat the import as a copy, not a switch. Before you start, confirm with Zendesk how your plan allows exports, since JSON, CSV and XML exports depend on plan and account settings, and keep a complete export on file as your independent backup. The migrator's rate limits depend on your Zendesk plan, so large accounts should check those limits early and schedule the run accordingly. Agents will need to set new passwords or use a supported third-party login, and any integrations, email routing and knowledge base content must be rebuilt and tested separately. Written scope with your partner should name who owns each of these tasks, how the cutover is verified, and what the rollback path is if the import fails.

Which Zendesk capabilities map cleanly to Zammad

This table compares the main Zendesk capabilities a support team relies on with what Zammad documents, marking each as clean, needs rework or gap. Read it as a checklist to run against your own tenant before scheduling a migration, because several rows depend on your plan, your identity provider or your hosting setup.

Capability	Status in Zammad	What to confirm in your environment
Tickets, users and organizations	Clean	Confirm that the migrator carries your ticket states, priorities, groups and organization links on a test copy of your data.
Comments and attachments	Needs rework	Confirm that internal and public comments and attachments import as expected; Zendesk's CSV export omits comments, so plan for the API route or the JSON export.
Macros and triggers	Needs rework	Zendesk macros and triggers use Zendesk-specific conditions; expect to rebuild them as Zammad triggers and macros and test each one.
Views	Needs rework	Recreate saved views as Zammad overviews and confirm that agents see the same ticket sets after the cutover.
Knowledge base	Gap	Zammad has its own knowledge base; article content, categories and languages from Zendesk Guide do not move through the ticket migrator, so confirm the export and import path separately.
Channels (email, web form, chat)	Needs rework	Email inboxes, web form and chat must be reconfigured on your own mail servers and domains; chat is not covered by the Zendesk migrator.
Reporting	Needs rework	Zammad's reporting depends on Elasticsearch, which is optional but strongly recommended; plan and size it before you rely on reports.
Search	Needs rework	Elasticsearch improves search and attachment content search; without it, confirm that agent search meets your volume and expectations.
Single sign-on	Needs confirmation	Zammad documents third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab; confirm that your identity provider and attribute mapping match your agent accounts.

What exports, identities and integrations to move

Moving a Zendesk help desk to Zammad is three separate jobs: getting ticket data out, deciding how people sign in, and rebuilding the things Zendesk does around the tickets. The migrator covers the first and only part of the second, so each card below names what carries over and what you must plan by hand.

Zendesk account exports as a backup

Zendesk offers JSON, CSV and XML exports on Suite Growth and higher and Support Professional and higher, not on Team plans. Exports are off by default, so the account owner must ask Zendesk support to enable them before you can use them. CSV omits ticket comments and descriptions, so treat JSON as the complete copy. Keep the export as a dated backup even if the migrator succeeds, and confirm which export your plan allows.

Full administrator API token

The Zammad Zendesk migrator authenticates with an API token created by a full administrator in Zendesk, not by an agent with a narrower role. Create the token in a named admin account, record who created it and when, and revoke it once the migration is signed off. Confirm with your Zendesk owner that the token is permitted under your security policy before the migration window opens.

Passwords do not migrate

User passwords are not carried into Zammad, so no imported customer or agent can log in with their Zendesk password. Decide the sign-in method before cutover. Agents can sign in through a corporate identity provider over SAML or OpenID Connect, while customers may need a password reset or a magic link. Plan a communication to customers explaining the new login step.

Third-party login setup

Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Configure the provider in Zammad before inviting agents, and test with a non-admin account. Confirm which identity provider your agents already use and whether it can issue claims that map to Zammad roles and groups.

Webhooks, triggers and apps

Zendesk webhooks, triggers, macros, automations and installed apps do not move with the ticket data. Inventory each one in Zendesk, note which ones send messages to Slack, billing or CRM systems, and rebuild them as Zammad triggers, schedulers or API integrations. Test each rebuilt rule against sample tickets before any live routing depends on it.

Email routing and inbound addresses

Zendesk support addresses forward mail into Zendesk, and those forwarding rules must be repointed to the Zammad mail channel before cutover. Plan the change with your mail administrator, including SPF, DKIM and DMARC records for the new sending domain. Run both systems in parallel for a short window and confirm that replies reach the right ticket.

The migration sequence from inventory to decommission

This sequence moves Zendesk support into a self-hosted Zammad instance without losing track of which system owns each ticket. Each step produces a written artifact, so the cutover is a checked decision rather than a guess. The migrator runs once and is all or nothing, so every change after the first import is delta work that your team carries out by hand.

Inventory tickets, users, triggers, macros and integrations
Support operations and the Zendesk administrator list what the help desk actually does: ticket volumes by channel, the groups and agents who work them, active triggers, automations and macros, views, and every integration that reads from or writes to Zendesk, such as chat, telephony, CRM or monitoring hooks. Each item is marked as migrate, rebuild in Zammad, or retire. The output is a signed-off inventory with an owner for every integration. Confirm the export options and limits for your Zendesk plan with Zendesk before you start, because they determine how the data is pulled.
Prepare the API token and the target instance
A full administrator creates the API token that Zammad's Zendesk migrator needs, and the team records who holds it and when it will be revoked. Platform engineering stands up a new Zammad instance with its PostgreSQL, Redis and reverse proxy in your own infrastructure, following Zammad's software requirements. The output is a reachable, empty instance with a documented token owner. Remember that the migrator works only on a new instance, so do not reuse one that already holds tickets.
Run a pilot import into a test instance
The team runs the built-in migrator against a copy of the data, not the live production instance, and then checks the result against the inventory. They sample tickets with their comments and attachments, confirm that users, groups and organizations landed correctly, and note every gap. Users must reset their own passwords because passwords are not migrated, and the team should plan that communication now. The output is a pilot report listing what moved, what did not, and the manual rebuild items for triggers, macros and integrations.
Rebuild configuration and integrations in Zammad
Administrators recreate the retained triggers, macros, groups, roles, channels and third-party logins in Zammad, and the integration owners repoint their systems to the Zammad API or email addresses. Authentication through SAML, OpenID Connect or another supported provider is tested with real accounts. The output is a configuration checklist that the pilot team has signed off, with each item marked as tested or pending.
Run a parallel period with clear ownership
Both systems stay available for a period the business agrees in advance, and the team writes down which system takes new tickets for each channel and queue. Agents record in a shared register any ticket they open or answer in one system that should exist in the other. Because the migrator cannot run differential syncs, the team plans any later catch-up as manual work. The output is a running ownership matrix and a daily exception log that is reviewed until both sides agree the rules are stable.
Cut over behind a freeze window
The team announces a freeze window in which no changes are made in Zendesk, then performs the final import or catch-up work so that Zammad holds the complete state. Channels are switched to Zammad, and Zendesk is set to receive no new inbound mail or integration traffic. Post-cutover checks confirm that new tickets arrive, outbound replies send, and integrations respond. The output is a signed cutover record listing the freeze start and end, the final data check, and the switch of each channel.
Decommission Zendesk with a retained JSON export
Before the Zendesk subscription ends, the account owner requests a full JSON export, which Zendesk recommends for accounts with more than 200,000 tickets, and stores it encrypted in an archive your retention policy covers. The team verifies that the file opens and that record counts match the inventory, then records the retention owner and review date. The output is a verified archive and a decommission record. Confirm with Zendesk how long exports remain available and whether your plan permits exports before you rely on them.

Why the migrator runs on a new instance only

Zammad's built-in Zendesk migrator works only on a new instance, and every migration is all or nothing. A run imports the whole source, and there is no supported way to bring Zendesk data into a Zammad installation that already holds tickets, users or custom objects. Treat the target as a clean build with no test data you want to keep. Plan one rehearsal instance for trial runs, then a production instance that receives the single final import. Because one migration accepts only one source system, a team that also moves Freshdesk or OTRS data needs a separate run for each source, so decide now whether those histories belong in the same Zammad instance.

Build the target before you request the API token, since the token is only useful once the instance is ready to receive data. Zammad's software requirements call for PostgreSQL 15 or newer for content, Redis 7 or newer for realtime websocket communication, and Nginx or Apache as the reverse proxy. Memcached is required for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Elasticsearch is optional but strongly recommended for search, reporting and attachment content search. Confirm which deployment path your team will use, whether the package install, Docker Compose or the Kubernetes Helm chart, because the path determines how these components are wired. On Kubernetes, Zammad support covers only the Zammad application, so the cluster, storage and networking remain your team's responsibility. Check the current requirements in the Zammad software requirements before you size the servers.

What drives the cost and duration of the move

This table lists the main factors that change what a Zendesk to Zammad move costs and how long it takes, and whether each cost is one-time or recurring. Use it to shape the written scope and to check that a quote covers each driver.

Driver	Why it changes cost or effort	What to ask for or confirm
Ticket volume and history depth	Migrations are all or nothing and run only on a new instance, so the full history is imported in one pass. More tickets and older history mean longer import runs, more storage and more validation.	Ask for ticket and attachment counts by year, and whether closed history older than an agreed cutoff is excluded.
Zendesk plan and API rate limits	Migrator rate limits depend on the Zendesk plan, so a lower plan can stretch the import window. Differential migrations are not supported, so the import cannot be run in small increments to shorten the cutover.	Confirm the current Zendesk plan, the rate limit it gives the API token, and the planned cutover window in the quote.
Automations, triggers and custom fields	Each trigger, macro, automation and custom field must be recreated or mapped in Zammad, and user passwords are not migrated. This is design and testing work that scales with the number of rules.	Request an inventory of triggers, macros, automations, views and custom fields, and a mapping table agreed before build.
Single sign-on setup	Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab. Connecting the identity provider, testing groups and roles, and planning the user reset path all add work.	Confirm which identity provider is in use, whether SAML or OpenID Connect is required, and who owns the identity provider changes.
Attachments and integrations	Large attachment stores and connected tools such as chat, telephony, CRM or custom apps each need a migration or rebuild decision. Elasticsearch indexing of attachment content adds indexing time and disk use.	Ask for total attachment size, the integration list, and which integrations are rebuilt, replaced or retired.
Hosting sizing and recurring operations	Zammad needs PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, and Elasticsearch is strongly recommended. Hosting, patching and backups recur after go-live, and multi-instance deployments add Memcached.	Ask for the proposed architecture, sizing assumptions, patch cadence, backup and restore test plan, and who runs each recurring task.
Zammad GmbH support contract (optional)	Self-hosted Zammad has no license fee. A support subscription is an optional recurring cost. Per the Zammad pricing page, list prices are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year.	Decide whether a vendor support tier is wanted, then ask the quote to show it as a separate line from implementation and hosting.
Training and handover	Agents, administrators and reporting users need to learn the new interface and workflows. This is one-time effort, but it recurs for new hires and for any later changes to rules.	Ask for the training format, the number of sessions, the handover documents and the admin knowledge transfer included in scope.

How the move differs by team size and starting point

A small team that runs support mainly through email and a web form usually has a short list of things to move: agents, groups, a modest ticket history and a few triggers or macros. In this case the migrator and a short cutover window are often enough, and the main work is making sure agents can sign in again and that inbound email reaches the new instance.

Accounts and logins: User passwords are not migrated, so plan for password resets or a single sign-on setup before agents return to work.
Email routing: Confirm which mailbox addresses receive customer email and how they will point to Zammad after cutover.
Automation: Review triggers and macros by hand, since only the ticket and user data is brought across.
Ticket history: Decide whether a full history is needed or whether open tickets plus a retained JSON export is enough.
Admin capacity: Ask who will hold the full administrator role needed to create the API token and who will run the instance afterward.

Before you start, confirm your Zendesk plan level, since it sets the rate limits the migration will hit, and check the migration documentation for the current steps.

What usually goes wrong and how to prevent it

Most failed Zendesk-to-Zammad moves do not fail in the import itself. They fail around it: accounts that cannot log in, history that silently thins out, and a cutover that sends customers to the wrong place. Each card below names one failure point and the check that prevents it, so the plan can be tested before any ticket moves.

Users cannot log in after import

Zammad's Zendesk migrator does not carry user passwords across, so imported agents and customers arrive without a usable password. Decide before the run how each group will authenticate, usually through SAML, OpenID Connect or a password reset flow. Test one agent and one customer account end to end on the new instance, including the reset email, before the production run. Confirm that the Zendesk email addresses match the identity provider records you plan to use.

Comments missing from the CSV export

Zendesk's CSV export omits ticket comments and descriptions, so a backup taken from that file keeps ticket metadata but loses the conversation. Use the JSON export for any copy you intend to keep as a record, and confirm the comment bodies are present by searching for a known phrase from a closed ticket. Plan the backup before the migration starts, because the export must be requested through Zendesk support and is not enabled by default.

Rate limits stretching the import

Rate limits on the Zendesk side depend on your plan, so the time a full import takes is set by your account tier rather than by Zammad. Ask Zendesk which limits apply to your plan and the API token you will use, then estimate the run from the ticket and user counts in your export. Schedule the import outside peak support hours and watch for throttling responses in the first hour, since a slow run can push cutover back.

A half-finished all-or-nothing run

Zammad migrations are all or nothing, work only on a new instance and accept a single source system per run. If the process stops partway, you cannot resume it into the same instance, so the working copy must be discarded and rebuilt. Run the first import on a disposable staging instance, record the time and any errors, and only then repeat the run on the instance that will go live. Keep the Zendesk export on hand so a failed attempt can be repeated without new API calls.

Duplicate notifications during parallel running

If Zendesk and Zammad both send email for the same mailbox while you test, customers receive two replies and agents may answer the same ticket twice. Decide which system owns outbound notifications for each period, and disable or redirect the other system's notifications before testing begins. Confirm the rule with a test ticket that you can trace in both tools, and write down the date the ownership changes.

Broken email routing at cutover

Inbound mail reaches Zammad only after the DNS records or forwarding rules point to it, and a mistake here drops new tickets without an error for the customer. Before cutover, send test messages from outside your network to each support address, confirm the ticket appears in the correct group, and check the sending domain's SPF, DKIM and DMARC records for the new outbound path. Keep the Zendesk forwarding in place until the test passes.

Triggers and automations not rebuilt

Zendesk triggers, automations and macros do not become Zammad triggers on their own, so routing, priority changes and customer notifications can quietly stop. Export the list of active Zendesk rules, map each one to a Zammad trigger or a documented manual step, and test each mapping with a sample ticket. Assign an owner to the list so that any rule with no equivalent is raised before go-live.

Questions buyers ask before moving from Zendesk to Zammad

How much effort and cost should we expect to move from Zendesk to Zammad?

Zammad itself has no license fee when self-hosted, so the cost is the work around it: infrastructure, the migration, configuration, and admin time. Infrastructure includes a PostgreSQL 15 or newer database, Redis 7 or newer for realtime updates, and a reverse proxy such as Nginx or Apache. Elasticsearch is optional but strongly recommended for search and attachment content, and Memcached is needed for multi-instance deployments such as containers. Those hosting costs recur. The migration, testing and cutover are one-time. The main drivers are ticket volume, the number of channels and mailboxes you connect, custom fields and workflows, and how much of Zendesk's history you need. If you want vendor support, Zammad sells self-hosted subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Ask for a written scope that separates one-time and recurring costs.

How long does a Zendesk to Zammad migration take?

No supplied source gives a duration, so treat any number you hear as unverified until it is tied to your own data. The timeline depends on the size of your ticket history, the number of users and organizations, how many attachments you carry, and how much testing your team wants before cutover. Zammad's migrator works only on a new instance, and migrations are all or nothing, so you cannot move in stages from Zendesk. Plan for a full test import on a staging instance, a review of the results, and a final import followed by a cutover window. Your Zendesk plan also affects speed, because rate limits depend on the plan. Ask any implementation partner for a written schedule tied to a defined scope.

What do our Zendesk admins need to do before the migration starts?

The migration needs an API token created by a full administrator in Zendesk, so at least one person with full admin rights must generate it and approve its use. Your team should also decide which Zendesk data to bring over, confirm the Zammad instance is new and empty, and plan how users will sign in. Because user passwords are not migrated, every agent and customer will need a new login or a single sign-on setup. Zammad supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, so confirm which identity provider you will use before the import. Admins should also review email routing, since inbound mail must point to Zammad at cutover. Document these decisions in writing so the import team and the business owners agree on them.

Can our own IT team run the Zendesk to Zammad migration without outside help?

Yes, a team with Linux, PostgreSQL and container or package administration skills can install Zammad and run its built-in migrator, using the package, Docker Compose or Kubernetes Helm chart methods in the documentation. The harder parts are usually outside the migrator: securing the hosts, configuring email channels, setting up single sign-on, backups, upgrades, and checking the imported data. On Kubernetes, Zammad support covers only the application, not Kubernetes-specific issues, so a platform team must own the cluster. If your team has no experience running these systems, a fixed-scope engagement with an implementation partner can cover planning, hardening and testing. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure under a written scope.

Do passwords, attachments and ticket history carry over from Zendesk to Zammad?

Passwords do not carry over, and users must set up new credentials or sign in through a configured identity provider. The migrator is all or nothing, so you cannot pick individual tickets once the import starts, and it does not support differential migrations, so a later sync of changes made in Zendesk is not available. Plan the cutover so that no new tickets arrive in Zendesk after the final import, or accept a manual catch-up step. Before go-live, check specific item types in a test import, including attachments, comments, custom fields, macros, triggers and organization links, because the migrator's coverage should be confirmed against the current Zammad migration documentation for your version.

How does Zendesk's JSON export work as a backup before we migrate?

Zendesk's JSON export is a useful independent copy of your tickets, users and organizations. Zendesk offers JSON, CSV and XML exports on Suite Growth and higher and Support Professional and higher, but not on Team plans. Exports are not enabled by default, so the account owner must ask Zendesk support to turn them on before you can run one. Zendesk recommends JSON for accounts with more than 200,000 tickets, because XML is capped at 500 MB and unavailable above that ticket count. The CSV export omits ticket comments and descriptions, so do not rely on it as a full backup. Store the export in a location your organization controls, and test that you can open it. Your backup plan should also account for the period after the cutover.

What does a Zammad support contract add beyond the free software?

A Zammad support subscription covers the self-hosted product with vendor help, and it does not change the software license, which is AGPLv3. Zammad GmbH sells self-hosted subscriptions named Business, Enterprise and Corporation, priced at 2,999, 5,999 and 9,999 EUR per year as listed on the Zammad pricing page. Ask Zammad which response times, channels and escalation paths each tier includes, and whether migration help is part of the package. A support contract does not replace the work of your own operations team, including patching, backups and capacity planning. Compare it with the cost of internal expertise and any independent implementation partner you engage.

Keeping Zendesk's JSON export as a backup copy

Before you decommission Zendesk, request a full account export and keep it as a backup copy that sits outside both Zendesk and the new Zammad instance. On Zendesk, exports are available on Suite Growth and higher and Support Professional and higher, not on Team plans, and they are not enabled by default. The account owner must ask Zendesk support to turn them on, so start that request early, while your subscription is still active. Ask for the JSON export, since that is the format Zendesk recommends for accounts with more than 200,000 tickets. XML is capped at 500 MB and is unavailable above 200,000 tickets, which makes it a poor fit for large histories. Confirm the current export steps and any size or retention terms with Zendesk support, because those details come from their help center and can change.

Use JSON rather than CSV for the backup itself. The CSV export omits ticket comments and descriptions, so a CSV-only copy would lose the conversation history that support teams rely on most. Store the archive in an encrypted location under your own control, with access limited to the few administrators who need it and a retention period set by your records policy. Record a checksum for the file when you store it, and keep a short inventory noting the export date, the Zendesk account, the plan and the person who requested it. Then verify the copy: open the JSON with a parser, check that ticket counts and date ranges match what Zendesk reports in its admin views, and confirm that a sample of comments and attachment references is readable. Compare a few tickets against the migrated Zammad records as well.

Keep the backup until the migrated data has been checked and your business has agreed that the old history is no longer needed. Decommissioning Zendesk removes access to the account, so the archive is the only fallback if a later question about a closed ticket arises. Ask your compliance lead which retention period applies to customer support records and whether the backup needs to be covered by the same deletion schedule as production data. Plan a dated review that confirms the archive is still readable and still held where the policy says it should be.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Zendesk to Zammad, that means agreeing the scope in writing first, then building and checking the migration and handing over the documentation your team needs to run it.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Zendesk data sources, ticket history and attachments the migration will cover.
We confirm your Zendesk plan, export options and API rate limits, which shape how the import is run.

How we build

We install Zammad in your own cloud account, data center or air-gapped network on a new instance.
We configure the required PostgreSQL, Redis and search components, plus your identity provider and mail channels.
We run the Zendesk migrator in a test instance, then check tickets, users, groups and attachments against the source.

How we hand over

You receive documentation covering the environment, the migration steps, the checks performed and the open items.
We record which content did not move, such as user passwords, so your users know what to reset.
We agree a backup approach that keeps a retained copy of the Zendesk export for your records.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the cutover.
Retainers can cover Zammad version updates, backup verification and security testing of the deployment.
Your team keeps control of the environment, and we document each change so handover stays clear.

Migrate from Zendesk to Zammad