Zendesk or self-hosted Zammad: which fits your support operation
If your Zendesk renewal has grown harder to justify, or a data location requirement now means customer tickets must stay on your own servers, the choice comes down to what your team can run. Zendesk Suite fits operations that want a managed service, broad channel coverage out of the box and no infrastructure team to patch and back up the platform. Zammad fits organizations that need control over where support data lives, want AGPLv3 licensing with no license fee for self-hosted use, and want a built-in Zendesk migrator to bring existing tickets across. The decision is not only about cost per agent, because a self-hosted help desk moves hosting, upgrades, backups and security patching onto your staff or a implementation partner.
Four factors should drive the decision. First, data location: list which ticket fields, attachments and customer records must stay in a specific country or network, and check whether Zendesk's regional options meet that rule before assuming self-hosting is required. Second, in-house platform skills: Zammad needs PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, and multi-instance deployments also need Memcached, so confirm who will operate those components. Third, channel needs: Zammad centers on email and web ticketing, so if your support depends on live chat or messaging channels, map those requirements before you commit. Fourth, admin time: estimate the hours your team can give to upgrades, monitoring and restores each month, and ask any partner for that effort in writing.
Before you choose, run a short proof of concept against a copy of your busiest queue. Confirm that your Zendesk administrator can create the API token the migrator needs, that your agents can work the imported tickets, and that your reports and knowledge base requirements are met. Then compare the recurring costs of Zendesk seats with the one-time migration work and the ongoing admin time for Zammad, including an optional Zammad GmbH support contract if you want one. Ask for a written scope and quote that lists each component, who operates it and how backups and restores are tested.
Which scenario points to which platform
This table matches common Zendesk-to-Zammad situations with the better fit and the reason for it. Read each row against your own requirements, and treat the rows marked as dependent as questions to confirm before you commit to a platform.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Regulated team that must control where ticket data lives | Zammad on your own servers | Self-hosting keeps ticket content, attachments and user data in infrastructure you choose. Confirm which regulator or contract sets the location rule and whether Zendesk's data center options already meet it. |
| Team with no platform engineers | Zammad German-hosted plan or Zendesk Suite | Self-hosting shifts patching, backups, upgrades and database care to your staff or an implementation partner. Confirm who will run PostgreSQL, Redis and the application day to day before choosing self-hosting. |
| Team that relies on Zendesk messaging and live chat | Zendesk Suite for now, or pair Zammad with Chatwoot | Zammad is strongest at email and ticketing channels. Website chat and social messaging need a separate tool or continued Zendesk use. Confirm which channels carry most of your volume. |
| Team that needs a mature knowledge base in several languages | Depends on the language and content plan | Zammad includes a knowledge base with multilingual public and internal answers, but compare its editing and deflection features against your current Zendesk Guide content. Confirm languages and article volume first. |
| Team whose Zendesk plan lacks data export options | Zammad migration, after enabling a backup path | Exports on Zendesk depend on plan and must be turned on by the account owner through support. Confirm your plan tier, then take a full export before any migration so you keep a copy. |
| Team with a large ticket history and strict reporting needs | Zammad with Elasticsearch, after a sizing review | Reporting and attachment search rely on Elasticsearch, which is optional but strongly recommended. Confirm report types and history length, since both drive sizing. |
| Team with many Zendesk integrations and custom apps | Zendesk Suite unless integrations are mapped | Zammad supports common identity providers and a documented API, but each Zendesk app needs a replacement or rebuild. Confirm the integration list before committing. |
What changes when the help desk runs on your own servers
Moving from Zendesk's cloud to self-hosted Zammad changes who is responsible for the application's availability. Zendesk operates the service, its upgrades and its uptime. With Zammad, your team owns the installation, the upgrade schedule, backups, monitoring and recovery. The decision to make first is who on your side holds these duties, and whether that person or group has the skills to run a multi-component web application that handles customer data. Zammad's stack has several parts, and each one adds operational work. PostgreSQL 15 or newer holds all content, so it needs its own backup, restore testing and capacity planning. Redis 7 or newer carries realtime websocket traffic, so it must be monitored and kept available for agents to see live updates. Nginx or Apache serves as the reverse proxy and terminates TLS, so certificate renewal and proxy configuration fall to your team. Elasticsearch is optional but strongly recommended for search, reporting and searching attachment content; running it means a separate cluster to size, patch and monitor. Memcached is required for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Confirm which of these your architecture will need before you staff the project.
Patch planning matters more than it does on a vendor-run service. Zammad publishes fixes on more than one release line: the 7.2 minor release was followed by security releases 7.2.1 and 7.2.2, and security release 6.5.5 shipped on the 6.5 line in parallel. If you run a line that is not your current target, you still need a path to the fixed release. Decide who watches the Zammad releases page, how quickly security fixes go into test and production, and whether you will run a staging instance that mirrors production before each upgrade. Ask Zammad GmbH or your implementation partner which support tier, if any, covers response expectations for your environment.
Data location, hosting models and compliance implications
Moving Zendesk to Zammad changes who holds the ticket data, who operates the systems and who must produce the evidence. The cards below separate the options: staying on Zendesk's cloud, running Zammad in your own environment, using Zammad GmbH's German-hosted plans, connecting identity, and the control work that remains with your team in every case.
Data location under Zendesk
Zendesk hosts the ticket, user and attachment data in its own cloud, so your team depends on the vendor's regional and residency options for where records are stored. Before a renewal, ask Zendesk in writing which data regions apply to your account, which add-ons change them, and which data stays outside the region, including exports and backups. Your data processing agreement and subprocessor list should match those answers.
Self-hosting in your own environment
Running Zammad in your cloud account or data center puts the application, PostgreSQL database, Redis and any Elasticsearch index under your control, including their location, encryption keys and network paths. The trade-off is that patching, backups, monitoring and restore testing move to your team or to a partner you contract. Confirm the hosting region, key custody and the operator access model before the design is signed off.
Zammad GmbH hosted plans
Zammad GmbH sells hosted plans run in German data centers, which sit between Zendesk's multi-region cloud and a fully self-managed install. Your residency question then becomes a contract question: confirm the hosting entity, subprocessors, support access from outside Germany, and the backup location. Ask how these terms compare with your current Zendesk data processing terms before you treat the hosted option as equivalent to your own infrastructure.
Identity integration through SAML and OIDC
Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, so agent sign-in can follow your existing identity provider rather than local passwords. Decide which identity provider is authoritative, how agent deprovisioning is triggered and whether administrator accounts keep a separate local path. Passwords are not migrated from Zendesk, so every agent must be provisioned through this route or set up again.
Control evidence that stays with you
Access reviews, change records, backup restore tests and log retention are your obligations under any framework you are assessed against, whether the help desk runs on Zendesk or on Zammad. Moving the platform moves the evidence trail too: you need to show who administered the system, when backups were tested, and where audit logs are kept. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work.
What each option costs over time
This table splits the cost of staying on Zendesk Suite from the cost of running Zammad yourself, row by row, and marks each component as one-time or recurring. Zendesk prices depend on plan and quote, so use the rows to build your own comparison with your agent count and support needs.
| Cost component | Who is paid, and for what | One-time or recurring, and what drives it |
|---|---|---|
| Zendesk per-agent subscription | Zendesk, for hosted Suite seats; price depends on plan and your quote, so confirm figures with Zendesk | Recurring. Driven by agent count, plan tier and any renewal uplift; confirm the terms in writing |
| Zendesk add-ons and data options | Zendesk, for features and data options added to the base plan | Recurring. Driven by which add-ons your team needs; ask for each one on the quote |
| Zammad software license | No fee: Zammad is licensed under AGPLv3 and self-hosted installs carry no license fee | Not applicable. Cost moves only with the infrastructure and support rows below |
| Infrastructure hosting | Your cloud provider or data center for application, PostgreSQL, Redis, and optional Elasticsearch and Memcached | Recurring. Driven by agent volume, attachment storage, search indexing and high availability design |
| Implementation and Zendesk migration | Your staff or an implementation partner for setup, the API token, migration runs, testing and cutover | One-time. Driven by mailbox and channel count, custom fields, triggers and how much history you keep |
| Zammad GmbH support contract (optional) | Zammad GmbH: Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year, Corporation at 9,999 EUR per year (Zammad pricing page) | Recurring, annual. Driven by the tier you choose and the support level your team needs |
| Internal admin time | Your IT or support operations staff for upgrades, backups, user management and monitoring | Recurring. Driven by upgrade cadence, in-house skills and how much you automate; ask any partner for a written scope |
How a move from Zendesk to Zammad is organized
The sequence runs from confirming what Zendesk plan and data you have to a verified Zammad instance that carries your channels, with a Zendesk export kept as a fallback copy.
Confirm scope and Zendesk plan tier
List the Zendesk products in use, including Support, Guide, messaging and any add-ons, and record your current plan tier, agent count, ticket volume and attachment size. Your Zendesk plan sets the API rate limits the migrator will run under, so ask your account owner to confirm the tier before scheduling any work. The output is a written inventory that states what must move, what can be rebuilt, and what will stay in Zendesk for a time. Confirm with your Zendesk account owner which plan features you rely on, because the migrator does not carry every object type across.
Request an API token from a full administrator
The Zendesk migrator authenticates with an API token created by a full administrator, so a person with that role must create the token in Zendesk and pass it to the team running the migration. Store the token in a secrets manager, limit who can see it, and plan to revoke it once the migration is verified. The output is a working token that the migration owner has tested against the Zendesk API. Confirm that the account owner understands the token grants access to the full account during the migration window.
Stand up a new Zammad instance
Install Zammad on infrastructure you control, using the package, Docker Compose or Kubernetes Helm chart that matches your environment, with PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy in place. The migrator works only on a new instance, so do not reuse a Zammad installation that already holds live tickets. Decide early whether you need Elasticsearch for search and reporting, and Memcached for multi-node deployments. The output is a clean, reachable instance with the admin account, backups configured and no production data yet.
Run the built-in Zendesk migrator
In the new Zammad instance, start the Zendesk migration with the API token and the Zendesk subdomain, then let the migrator import users, organizations, groups, tickets and related records. Migrations are all or nothing and accept one source system per run, so keep the job from being interrupted and do not mix in data from another helpdesk. Passwords are not migrated, so users will need to set or reset their logins. The output is a completed migration log with no unresolved errors, which the migration owner reviews before moving on.
Verify migrated data against Zendesk
Compare record counts, a sample of tickets with their comments and attachments, custom fields, and user and organization assignments between Zendesk and Zammad. Check that agents can log in, that roles and groups match your design, and that search returns expected results. Because differential migrations are not supported, any ticket created in Zendesk after the run will not appear in Zammad, so note the cutoff. The output is a signed-off verification checklist with the known gaps written down.
Cut over email routing and integrations
Point your support mailboxes, web forms and any connected systems at Zammad, rebuild or re-authorize the integrations you still need, and set up SAML, OpenID Connect or other third-party login if agents will use single sign-on. Plan the switch so no inbound email is lost during the change, and keep Zendesk able to receive mail until routing is confirmed. The output is a tested inbound and outbound email path and working integrations, confirmed with a set of test tickets.
Retain a Zendesk export as a backup copy
Before you close or downgrade the Zendesk account, export tickets, users and organizations from it so you hold a copy outside Zendesk. Zendesk's JSON export is the format to use for large accounts, because its CSV export omits comments and descriptions and XML is capped by size and ticket count. Exports must be enabled by your account owner on eligible plans. The output is a stored, checksum-verified export kept under your retention policy, with a note of the date it was taken.
Questions buyers ask before choosing Zammad over Zendesk
What does a Zendesk to Zammad migration cost, and who does the work?
The licence cost of Zammad is zero, so the cost sits in people and infrastructure. Your team, or a partner you hire, prepares the new server, creates a Zendesk API token from a full administrator account, runs Zammad's built-in Zendesk migrator, and tests the result. Zammad's migrator is all or nothing, works only on a new instance and handles one source system per migration, so the work is usually a single planned cutover rather than a gradual sync. Ask any partner for a fixed-scope quote that lists the servers, the number of agents and tickets in scope, the testing steps, the cutover window and who signs off. DeployOpen works from written scope, and its price follows from that scope.
Can our team run Zammad without outside help?
Yes, if you have people who can run a Linux server, PostgreSQL, Redis and a reverse proxy such as Nginx or Apache. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and it supports Nginx or Apache as the reverse proxy. Elasticsearch is optional but strongly recommended for search, reporting and attachment search. Multi-instance deployments such as containers or cluster nodes also need Memcached. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. Confirm internally whether you have staff for patching, backups and on-call cover before deciding who runs it.
How much internal admin time does self-hosting Zammad need, and what drives it?
The time depends on how many components you run, how often you upgrade, and how much you customize. A single installation with the file system cache is simpler than a multi-instance setup that adds Memcached, and adding Elasticsearch adds a service to patch and monitor. Recurring tasks include applying Zammad minor and security releases, keeping PostgreSQL and Redis current, checking backups, reviewing user and role changes, and maintaining integrations such as SAML or OpenID Connect sign-in. Zammad published security releases for both its 6.5 and 7.x lines in October 2026, so plan for a release process that covers more than one line. Ask your partner to estimate these hours from your own agent count and architecture.
Does Zammad cover the same channels as Zendesk?
Zammad covers the core ticket channels that most support teams use, but you should map each Zendesk channel against Zammad before committing. Confirm email handling, web forms, phone and any messaging or live chat you depend on. Zammad does not replace website live chat by itself, so if you use Zendesk messaging for chat and social channels, check the open-source option described in the Zendesk messaging comparison and decide whether it runs alongside Zammad. Test each channel in a staging instance using your own mailboxes and integrations, because feature availability can differ by version.
How does Zammad's knowledge base compare with Zendesk Guide?
Zammad includes a built-in knowledge base with public and internal answers in several languages, which covers the common case of a help center tied to the ticket system. Zendesk Guide has its own publishing, category and analytics features, so compare them against your current article set, search needs and reporting. Plan to export your articles, map categories, and check how ticket deflection and article links will work after the move. Confirm with the Zammad documentation which knowledge base features your version supports before you design the help center.
Do we need a Zammad GmbH support contract?
No. Self-hosted Zammad has no license fee, and a support contract is optional. Zammad GmbH sells self-hosted support 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 its pricing page. Buy one if you want vendor support for the application. Without one, you rely on your own staff, the community and any partner you hire. Compare these fees with the retainer or support scope a partner would charge, and note that a partner does not replace the vendor's product support.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that names the systems in scope, the number of agents, mailboxes, integrations and tickets to migrate, and which Zendesk data is excluded. Request the deliverables, including the installed environment, the migration run and its validation, backup and restore testing, documentation, and handover to your staff. Ask how the work is tested, who signs off each stage, how a failed cutover is handled, and what post-go-live support is included or sold separately. Confirm the hosting location, access controls and who holds administrator credentials. DeployOpen plans and implements self-hosted platforms in your own infrastructure and provides fixed-scope engagements with written deliverables and timelines, so compare proposals on those points.
When staying on Zendesk is the right call
Staying on Zendesk is the right call when the team cannot staff platform operations. Zammad is self-hosted software, so someone in your organization or a partner must own the application server, the PostgreSQL 15 or newer database, Redis 7 or newer for realtime websocket communication, and the reverse proxy, along with patching and backups. If your IT group has no one who can take that on for the life of the system, the cost of Zendesk's per-agent subscription may be lower than the internal admin time Zammad will need. Ask who will apply security releases within a few days of publication, who restores from backup, and who handles upgrades. Confirm that answer before you compare license costs.
Staying is also right when your channels and automation depend on Zendesk-specific features. Zendesk's messaging, its marketplace apps, its Sunshine and bot integrations, and the way your triggers, macros and views are wired may be hard to reproduce exactly in Zammad. Build an inventory of every active trigger, automation, integration and app your agents touch each day, then check each one against Zammad's documented features and its API. If a critical workflow has no equivalent, the migration will require custom development or a process change, and that work should be priced before you commit. Confirm whether live chat and social channels must stay in one inbox, since that decision often matters more than the ticketing core.
Finally, staying makes sense when your compliance program already accepts Zendesk's controls. If your auditors have reviewed Zendesk's security documentation, your contract covers the data locations you need, and your control evidence (access reviews, logging and change records) is already produced by Zendesk, moving to a self-hosted system means you must build and evidence all of those controls again. That is a one-time project plus a recurring operating burden. Ask your auditor which controls would move to your side of the responsibility line and whether the change needs a new assessment scope. Staying is the stronger choice when that re-evidencing cost outweighs the license savings you expect.
How DeployOpen helps evaluate, implement and migrate Zammad
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Zendesk vs Zammad, we start with a written scope that tests the channels, reporting and knowledge base you actually use before any servers are built.
How we scope
- We inventory the Zendesk channels, triggers, macros, views and integrations your team relies on today.
- We agree in writing which Zammad features cover each need and which gaps need a workaround or a decision.
- We confirm hosting location, identity provider, backup targets and who on your side holds the Zendesk administrator role.
How we build
- We deploy Zammad with PostgreSQL, Redis and the reverse proxy your standards require, inside your environment.
- We configure third-party login such as SAML or OpenID Connect and test mail channels, groups and roles before go-live.
- We run a trial Zendesk migration on a non-production instance, then review what moved, what did not and what needs manual rework.
How we hand over
- You receive architecture notes, configuration records, runbooks and the test results agreed in the scope.
- We document the cutover plan, the Zendesk export kept as a backup copy and the steps to restore it.
- Your administrators are trained on daily operations, user management and upgrade procedures before the engagement closes.
How we support
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A quote follows from your written scope, and we will explain which parts of the cost are one-time and which recur.
