Zendesk cost vs self-hosted Zammad

Running Zammad yourself means operating a small stack, not a single application. The database is PostgreSQL 15 or newer, which holds all ticket content. Redis 7 or newer handles realtime websocket communication, so agents see updates without refreshing. A reverse proxy, either Nginx or Apache, sits in front of the application. Each of these is a service your team installs, configures, backs up, patches and monitors, and each carries its own upgrade path. Before you compare hosting costs with Zendesk's per-agent fee, list these components and assign an owner for each one, including who receives security advisories for Redis and PostgreSQL. Two components are optional but change the workload. Elasticsearch is not required, yet Zammad uses it for faster search, reporting features and searching the content of email attachments, and the project strongly recommends it. Choosing to skip it keeps the stack smaller but limits search and reporting, which matters if you rely on Zendesk's search for daily work. Memcached is needed when you run multiple Zammad instances, such as containers or cluster nodes, while a single installation can use the file system cache. If you plan a multi-node design for availability, budget for Memcached and confirm the cache settings in the Zammad software requirements before you size hardware. Zammad documents three install paths: system packages, Docker Compose and a Kubernetes Helm chart. Package installs are the simplest to audit but tie upgrades to your operating system's schedule. Docker Compose suits a single host with clear version pinning. On Kubernetes, Zammad support covers only the Zammad application, so cluster networking, storage classes and node issues remain with your platform team or a partner. Ask your platform team which path matches your existing operations skills, and ask any implementation partner to state in writing which layers they will own.

The effort of moving from Zendesk to Zammad is shaped less by the tool than by the constraints of its built-in migrator, so plan around those constraints before estimating anything. Zammad's Zendesk migrator needs an API token created by a full administrator in Zendesk, and the migration runs all or nothing on a new Zammad instance. It does not carry over user passwords, so every imported agent and customer will need a password reset or a login through a configured provider such as SAML, OpenID Connect or Google. Ask your Zendesk owner who can create that token and confirm, in the Zammad Zendesk migration documentation, how rate limits apply to your Zendesk plan, since those limits set how long the import takes.

The largest hidden cost is rerunning. Because differential migrations are not supported, a change made in Zendesk after a test run is not picked up by a later run, and a failed or unsatisfactory import means starting the whole migration on a fresh instance. Each rerun therefore costs administrator time for setup, verification and sign-off. Reduce that time by cleaning Zendesk data first (closing stale tickets, removing duplicate users, and fixing organizations) and by agreeing on a single cutover date so the import runs once. Effort rises when there are many custom fields, macros or triggers that need manual rebuilding in Zammad, which the migrator does not translate for you.

Zendesk's own JSON export is the practical safety net. Exports are available on Suite Growth and higher and on Support Professional and higher, but the account owner must ask Zendesk support to enable them. Request that export before cutover and store it under your retention rules, because it gives you a restorable copy of tickets, users and organizations if the import needs to be reversed. Note that the CSV export omits ticket comments and descriptions, so JSON is the format to keep. Confirm with Zendesk, before you start, that the export is enabled and that your account size fits the format limits described in the help center.

Before any cost comparison means anything, the scope needs to be written down. Start with the migration scope: which Zendesk objects move (tickets, users, organizations, macros, triggers, views and knowledge base content), which do not, and who rebuilds the rest by hand. Zammad's built-in Zendesk migrator is all or nothing, works only on a new instance and accepts one source per migration, and it does not carry user passwords or support differential runs. A written scope should say how a cutover window will be handled, how many agents and mailboxes are in play, and who signs off on the imported data. Ask for the effort in writing, separated into migration, configuration and testing, so the internal admin time is visible rather than buried.

Next, fix the hosting topology and the backup and restore tests. The scope should name the reverse proxy (Nginx or Apache), the PostgreSQL 15 or newer database, the Redis 7 or newer instance used for websockets, and whether Elasticsearch and Memcached are included, since both depend on whether the deployment is a single node or a multi-instance setup. It should also name the infrastructure it runs on, its monitoring, and who patches it. For backups, require a documented restore test with a recorded result, not only a backup job. Zendesk's own exports are useful as an independent copy, but they have plan limits and the CSV format omits comments, so the scope should say which copy is authoritative.

Finally, record the support tier and its annual EUR figure, if one is chosen, along with the handover of runbooks. Zammad GmbH lists self-hosted support subscriptions at 2,999 EUR per year for Business, 5,999 EUR per year for Enterprise and 9,999 EUR per year for Corporation, and those figures belong in the scope only as the price the vendor published on its pricing page at the time of quoting. Confirm whether support is included, what it does not cover (such as Kubernetes-specific issues), and what the team keeps in-house. Require written runbooks for upgrades, backups, user administration and incident response, and make their delivery an acceptance condition. The result of the comparison depends on your own figures for agents, hosting, labor and risk, so run the numbers against this written scope, not against any published example.