OTRS or Zammad: which service desk fits your team?
If your OTRS renewal is coming up, your licensing terms have changed, or you are running an OTRS Community Edition 6 install that no longer gets security fixes, the decision is whether to keep the OTRS lineage through Znuny or move to a different tool. Zammad is the better fit when you are willing to change tools, when your priority is a modern agent and customer interface, and when you want to bring email, chat and web channels together in one place. OTRS, or its Znuny continuation, remains the stronger choice when you need deep, configurable ITSM process logic and want to keep your existing workflows, queues and custom code largely intact. Zammad fits teams whose service desk is mainly customer-facing and multi-channel, with a moderate number of agents and processes that can be expressed through its own workflow and ticket model. Its built-in OTRS migrator reduces the amount of rebuilding you would otherwise do, but migrations are all or nothing and work only on a new instance, so plan for a fresh environment and a cutover rather than an in-place upgrade. Znuny fits teams with heavy change, problem and service level management, many custom add-ons, or staff who already know the OTRS administration model well. Confirm the feature coverage you rely on with each vendor before you commit to either path. The decision turns on four things: how deep your process definitions go, how many agents and queues you run, which channels your customers use, and who will operate the system after go-live. Ask who will patch, back up and monitor the platform, because self-hosted Zammad and Znuny both shift that work to your team unless you buy support or services. Score each option against your current OTRS configuration, and run a test migration on a copy before you set a renewal or retirement date.
Which option fits each scenario
This table matches common OTRS situations to the better fit between Zammad and staying on an OTRS lineage. Read each row for the condition that changes the answer, and confirm OTRS capabilities with the vendor for your exact edition before deciding.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Formal ITSM change and problem processes | Stay on OTRS or Znuny | Your change advisory, problem and CMDB workflows are already built in OTRS. Confirm with the vendor which ITSM modules your edition includes before assuming parity. |
| Customer support with shared inboxes and a knowledge base | Zammad | Your main need is multichannel ticket handling, collaborative inboxes and a public knowledge base, and you are willing to retrain agents on a new interface. |
| Keep all data in your own data center | Zammad or Znuny, self-hosted | Both can run on your servers. Choose on process fit, then check the database, Redis and Elasticsearch footprint against your data center standards. |
| Limited operations capacity | Zammad with a support plan, or a managed OTRS contract | A small team with no Perl or Linux depth should weigh Zammad's vendor support tiers against the operating load of a Perl-based Znuny stack. Ask for quotes on both. |
| Large migration history in OTRS | Znuny | Years of custom Perl code, add-ons and workflows that would be costly to rebuild favor a stepwise path. Zammad's OTRS migrator works only on a new instance and moves all or nothing. |
| Need to validate migration scope before committing | Test on a copy first | Run a trial import into a new Zammad instance and compare ticket history, users and attachments. Ask Zammad which OTRS versions its migrator has been tested against. |
Where OTRS process depth matters and where Zammad's simpler model fits
The fit depends on whether your ITSM processes need formal configuration or whether a multichannel help desk with a clear agent interface is enough. OTRS is positioned around ITSM process and configurability, so teams that run formal change approval chains, configuration item relationships or CMDB-style records should test those flows against the product before deciding. Zammad is strongest as a multichannel help desk, with channels such as email and other inbound sources, a clear agent interface and a built-in knowledge base. Those strengths map well to customer support and service desk work, but this research does not show that Zammad matches OTRS on change management or configuration depth, so do not assume it does.
Before you shortlist, write down the processes you run today and mark which ones depend on OTRS-specific configuration, such as approval steps, linked assets or service level rules tied to configuration items. Ask your OTRS partner or internal administrator to export a list of active workflows, dynamic fields and automations, then ask Zammad to demonstrate how it handles each one. Where a process has no clear equivalent, confirm whether it can be handled through the Zammad API, a workaround in the knowledge base, or a separate tool. Treat any gap you find as a decision to fund, redesign or accept, not as a detail to resolve after go-live.
If your service desk is mainly ticket intake, customer and employee communication and knowledge sharing, Zammad's simpler model may reduce what your agents have to learn and maintain. If change control and configuration records are central to audit evidence, the OTRS side of the comparison deserves a longer review, and you should check with your auditor which records they will ask to see. In both cases, the outcome of this check should be a written list of required processes with a yes, no or workaround answer for each, agreed by the service owners before any migration planning starts.
How OTRS and Zammad compare on capabilities
This table compares OTRS and Zammad on licensing, source code, databases, search, login, channels, migration and deployment. Zammad cells come from its published requirements and documentation, while OTRS cells tell you what to confirm with OTRS before you decide, so use the open OTRS items as the first questions in your evaluation.
| Capability | OTRS | Zammad |
|---|---|---|
| Licensing | Commercial product sold by quote as managed hosting or on-premise. Confirm current terms with OTRS. | GNU AGPL-3.0. Self-hosted use has no license fee, while optional support subscriptions are sold separately. |
| Source code | Commercial product. Confirm what source access, modification rights and escrow terms your contract includes. | Source code is on GitHub. The Zammad Foundation owns it, and Zammad GmbH develops it with the community. |
| Supported databases | Confirm supported databases and versions with OTRS for your target release. | PostgreSQL 15 or newer, which stores all Zammad content. |
| Search | Confirm search engine options and attachment search with OTRS. | Elasticsearch is optional but strongly recommended for faster search, reporting and email attachment content search. |
| Third-party login | Confirm supported SSO protocols and providers with OTRS for your edition. | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. |
| Channels and knowledge base | Confirm which channels and knowledge base features are included in your edition and add-ons. | Confirm the channels and knowledge base features you need against Zammad's current documentation for your version. |
| Migration tooling | Confirm export and upgrade paths with OTRS before planning any move to another product. | Built-in OTRS migrator. Migrations are all or nothing, run only on a new instance and accept one source system per migration. |
| Deployment options | Managed hosting or on-premise, by quote. Confirm current deployment models with OTRS. | Package installation, Docker Compose and a Kubernetes Helm chart. Kubernetes support covers only the Zammad application. |
| Realtime and caching | Confirm caching and realtime requirements for your OTRS version with OTRS. | Redis 7 or newer for websocket communication. Memcached is needed for multi-instance deployments such as containers or cluster nodes. |
How hosting and data control differ on each side
Hosting decides who can reach your ticket data, where backups sit and which obligations follow them. Read these cards against your data residency, identity and audit requirements, and run each named check before you sign a contract or schedule a cutover.
Where OTRS data lives
Under managed OTRS, the vendor or its hosting partner runs the servers, so ticket content, attachments, logs and backups sit in facilities you do not operate. Ask for the exact country and data center for primary data, replicas and backups, along with every sub-processor that can access them. Get these answers in the contract, not in a sales call. Under an on-premise OTRS license, the same questions move to your own data center, and vendor support access becomes the open item to define.
Zammad hosted plans
Zammad GmbH sells hosted plans that run in German data centers. Hosted plans start at 7 euros per agent per month, and Zammad's pricing page states that self-hosted customers handle updates, backups and availability. Ask which sub-processors support the hosted service, where backups are kept and how data is deleted when the contract ends. A hosted plan moves operations to Zammad, but it does not remove your duty to document the processor relationship.
Self-hosted Zammad on your infrastructure
Self-hosted Zammad keeps every ticket, attachment and log inside your cloud account or data center, and your team chooses the location. The stack needs a supported PostgreSQL release, Redis for websocket traffic 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. Each component is a data store you must back up, patch and place inside your network.
Identity integration
Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. That lets you keep agent accounts in your existing identity provider, so removing an agent happens in one place. Confirm which of these your identity provider supports and what federation OTRS offers on your license tier. Test account disablement and role mapping before cutover, because an departed agent who still holds a local password is an access finding.
Compliance evidence you produce
Under either option, you must produce the evidence that controls operate: access reviews, change records, backup restore tests, log retention settings and vendor due diligence files. A managed OTRS contract or a Zammad hosted plan can supply some of it, but auditors will still ask for your records. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies.
How Zammad runs in your environment
The package path installs Zammad directly on a Linux server, so your team runs the operating system, the web application, the database and the supporting services as separate pieces. Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime websocket communication and supports Nginx or Apache as the reverse proxy. Your team owns each of these services, their patching and their backups.
- Database: PostgreSQL 15 or newer holds the tickets, articles and configuration, so backup and restore planning starts here.
- Realtime: Redis 7 or newer carries websocket traffic for agents working in the browser.
- Reverse proxy: Nginx or Apache terminates TLS and forwards requests to the application.
- Search: Elasticsearch is optional but strongly recommended for faster search, reporting and searching attachment content, so plan a separate node or service for it.
- Caching: a single installation can use the file system cache, so Memcached is only needed once you run more than one instance.
Check the current requirements page before you size the servers, because versions change between releases. Confirm with Zammad GmbH which parts of a self-hosted support plan cover your installation and which remain with your own administrators.
The Docker Compose path packages the Zammad application and its companion services as containers defined in a single file, which suits a pilot or a single-host production setup. Your team still chooses the host, storage, network rules and backup routine, and the containers do not remove the need to plan them. Zammad documents this installation path, so start from its guide and review each service it defines.
- Single host: all containers run on one machine, so host failure takes the whole helpdesk down unless you add failover outside Zammad.
- Persistent volumes: database and attachment storage must sit on volumes you back up and test restoring.
- Scaling: running several application containers requires Memcached as a shared cache, because a single installation's file system cache is not shared between instances.
- Search service: Elasticsearch adds memory and storage demands on the same host, so size the host for it from the start.
- Upgrades: you pull new images and run the documented steps, so keep the compose file under version control.
Ask Zammad which configurations its support covers for containerized installs before you commit to a layout. Confirm also who on your side owns the container host, its patching and its access controls.
The Kubernetes path deploys Zammad with the Helm chart that Zammad documents, which suits organizations that already run a cluster with platform engineering support. This path adds the cluster itself to your scope: nodes, ingress, storage classes, network policies and cluster upgrades all remain with your platform team. Zammad's support on Kubernetes covers only the Zammad application, not Kubernetes-specific issues.
- Application support: Zammad supports the application behavior, not the cluster, ingress controller or storage driver.
- Cluster ownership: your platform team owns node patching, Kubernetes version upgrades and the surrounding tooling.
- Caching: multi-instance deployments such as cluster nodes need Memcached, while a single installation can use the file system cache.
- Stateful services: plan PostgreSQL, Redis and Elasticsearch storage with backups, because pods are replaceable but data is not.
- Secrets and access: keep database credentials and API tokens in your cluster's secret handling, not in chart values committed to source control.
Before you choose this path, ask your platform team who will own incident response for the cluster and confirm with Zammad what its support covers for your chart version.
What each option costs to own
Commercial OTRS and self-hosted Zammad are priced in different units, so the comparison depends on which components you pay for and how often. DeployOpen does not publish prices; a quote follows a written scope that names the components below.
OTRS licenses or managed hosting
OTRS is sold by quote, either as managed hosting or on-premise licensing, so the recurring cost depends on the contract terms, user count and add-ons. Ask the vendor to break the quote into license or hosting fees, support, add-on modules and any upgrade or migration services. Check what happens to pricing at renewal and whether the contract allows you to export your data and configuration cleanly if you leave.
Zammad with no license fee
Self-hosted Zammad has no license fee because it is licensed under AGPL-3.0, so the recurring cost is the infrastructure and people that run it. Support is optional: Zammad GmbH sells self-hosted support plans named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. Compare the plan scope, response commitments and what the vendor says it covers against your own support model before deciding.
Servers, database and cache
Zammad stores content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime websocket communication, so you provision and patch both. Multi-instance deployments such as containers or cluster nodes also need Memcached, while single installations can use the file system cache. Size the hosts from your agent count, ticket volume and attachment storage, and confirm backup and high availability needs with your own environment and the Zammad sizing guidance.
Elasticsearch for search
Elasticsearch is optional for Zammad but strongly recommended, because it drives faster search, reporting and searching of email attachment content. It adds a separate cluster to size, monitor and upgrade, which is a recurring operating cost. If your OTRS users depend heavily on full-text search across attachments, include this component in the sizing and ask your team or implementation partner to test it with real ticket volumes.
One-time migration effort
Zammad's built-in OTRS migrator is all or nothing, works only on a new instance and accepts one source system per migration, so each run is a planned project rather than a sync. Budget for mapping queues, states, SLAs, custom fields, roles and integrations, plus test migrations and user acceptance testing. Ask any vendor or partner to price the mapping, test cycles and cutover window as separate line items so you can see which costs are one time.
Staff who operate the platform
The largest recurring cost on the self-hosted side is usually people: administrators who patch the application, database, cache and search tier, handle upgrades, run backups and respond to incidents. Under a self-hosted model, the vendor's own pricing page states that customers handle updates, backups and availability. Estimate the share of an engineer's time this needs and compare it with OTRS licensing or hosting plus any internal administration you already carry.
What a move from OTRS to Zammad involves
The sequence turns an OTRS queue, workflow and integration estate into a tested Zammad instance with migrated history and trained agents, with each stage closing on a written check. Confirm early what the OTRS migrator carries over for your data, because that answer shapes every later step.
Inventory queues, workflows and integrations
Your admins list every OTRS queue, priority, state, SLA, dynamic field, notification, auto-response, scheduled job and ITSM configuration item that agents rely on, plus every custom module, template change and integration with monitoring, email, LDAP or other systems. Compare that list against Zammad's groups, triggers, overviews and channels to mark each item as replicated, redesigned or retired. The output is a signed-off inventory that names an owner for each gap, such as ITSM change or CMDB processes that need a different approach.
Confirm what the OTRS migrator carries
Ask the Zammad team and run a small test to see how the OTRS migrator maps tickets, articles, attachments, users, groups, customers and organizations in your OTRS version and database. Record which objects arrive intact, which are transformed and which are dropped, including any custom fields and ITSM data. Treat this as a question for your environment, not an assumption. The output is a written mapping that your data owner accepts.
Prepare the source data and access
Your OTRS administrator takes a verified backup of the OTRS database and file storage, then checks the ticket, article and attachment counts so later comparisons have a baseline. Clean up obvious duplicates, inactive accounts and retired queues where your retention policy allows, and document what is deliberately left behind. Because Zammad's migrations are all or nothing and accept one source system per migration, confirm that the OTRS export is complete before moving on. The output is a backup, a count sheet and a retention decision record.
Build the new Zammad instance
Your platform team deploys a new Zammad instance in your own infrastructure using the package, Docker Compose or Kubernetes Helm chart route that matches your operating standards. Set up PostgreSQL 15 or newer, Redis 7 or newer, the reverse proxy, mail channels, identity provider login and, where search volume justifies it, Elasticsearch. Note that the migrator works only on a new instance, so this one must not hold production data yet. The output is a hardened instance with documented configuration, backups and monitoring.
Rebuild configuration and run a test migration
Your Zammad administrators recreate the agreed groups, roles, triggers, SLAs and channels, then run the OTRS migration into a copy of the new instance. Compare ticket counts, article counts, attachment integrity and user mapping with the baseline from the source. Because differential migrations are not supported, plan on repeating the full run for each rehearsal rather than updating a previous one. The output is a migration report with reconciled counts and a list of defects that must be fixed before production.
Test workflows with agents and integrations
Agents and team leads work through representative tickets in the test instance, covering escalations, merges, customer replies, email threads, reporting and any integrations you rebuilt. Your security team reviews role permissions, authentication and audit logging against your own requirements. Track each issue to a fix or an accepted workaround, and record the decisions. The output is a signed test sign-off by the process owners and the security reviewer.
Onboard users and train agents
Your service desk manager plans training for agents, supervisors and requesters who will see a different interface, and prepares short guides for the processes that changed. Provide a shared place for questions during the first weeks after go-live. Confirm that user accounts, login methods and notification settings are ready for the production group. The output is a trained user group and a published support path for the first weeks of use.
Cut over and retire OTRS
Your team freezes OTRS changes, takes a final backup, runs the production migration into the prepared instance, and repoints email channels and integrations to Zammad. Verify the counts again, then switch the live queue and watch the first business cycles closely. Keep the old OTRS system read-only for a period set by your retention policy before decommissioning it. The output is a dated cutover record, a verified production dataset and a decommissioning plan approved by your data owner.
Questions buyers ask before switching from OTRS
What drives the cost of moving from OTRS to Zammad?
The cost is set by the components you pay for, not by a single license line. Self-hosted Zammad has no license fee, so the one-time spend covers infrastructure setup, the migration, configuration, integrations and training, while the recurring spend covers servers, storage, staff time to operate the system and any support contract. Zammad sells self-hosted support plans named Business, Enterprise and Corporation at 2,999, 5,999 and 9,999 euros per year, according to its pricing page, so a support subscription is optional and separate from the software. Ask any implementation partner for a fixed-scope quote that lists each item, who performs it and what is included in the recurring part.
How long does an OTRS to Zammad migration take?
Duration depends on data volume, the number of custom workflows and integrations, and how much your team can test. Zammad's built-in OTRS migrator runs all or nothing, works only on a new instance and accepts one source system per migration, so you cannot import in small increments and must plan a full cutover window. Migrations also depend on how your OTRS data is structured and exported. No duration figure is supplied here, so ask your implementation partner for a timeline in the written scope and confirm the migrator's behavior against your own copy of the data.
What does the internal team need to run the move?
Your team needs skills in Linux server administration, PostgreSQL, Redis and a reverse proxy, because Zammad requires PostgreSQL 15 or newer, Redis 7 or newer, and Nginx or Apache as the reverse proxy, per Zammad's software requirements. Multi-instance deployments also need Memcached, and Elasticsearch is optional but strongly recommended for search and attachment content. Staff also need to own business decisions: which OTRS queues, states and SLAs map to Zammad, who approves the cutover, and who signs off on testing. Assign named owners for these roles before the project starts.
Can we migrate from OTRS to Zammad without an outside partner?
Yes, a capable team can attempt the move alone, since Zammad documents its installation and migrator. The main risks are the all-or-nothing migration, mapping custom fields and processes, and testing on a copy before cutover. A partner adds value when your team lacks Linux, database or integration experience, or when you need a documented plan for compliance evidence. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, so you can compare an internal plan with an outside scope before deciding.
How does Zammad support differ from running it ourselves?
Zammad support is a vendor contract for the software, while self-hosted operation is your own responsibility for uptime, updates and backups. Zammad's pricing page states that self-hosted customers handle updates, backups and availability, so a support plan does not transfer operational duties to the vendor. On Kubernetes, Zammad's documentation says its support covers only the Zammad application, not Kubernetes-specific issues. Ask Zammad exactly which incidents each plan covers, the response terms, and whether infrastructure troubleshooting is included.
What happens to our OTRS custom code and add-ons?
Custom code and add-ons do not move with the data, so they need a decision each. Zammad's migrators cover Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through the Zammad API or through custom development from Zammad. Each OTRS customization should be classed as retire, rebuild on Zammad's API, or keep on an OTRS fork such as Znuny. List every custom ticket field, script, interface and integration in an inventory before requesting a quote, because this list usually drives most of the migration effort.
How do we confirm the migration preserves our data and access?
Confirm it with a test migration on a copy, not on production. Zammad's documentation notes that user passwords are not migrated for Zendesk imports, and that comparable constraints should be verified for the OTRS path before you rely on it. Verify ticket counts, attachments, history, user roles and group access in the test environment, and plan how users will sign in afterwards. Third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab can cover access once accounts are in place. Ask your partner to document each check and its result.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OTRS vs Zammad, we start from your ticket volumes, queues, channels and integrations, so the decision and the migration plan rest on your own environment.
How we scope
- Inventory OTRS queues, ticket states, dynamic fields, SLAs, roles and integrations before comparing Zammad against them
- Identify which processes need ITSM depth and which only need customer-facing ticket handling
- Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope
- Confirm with Zammad GmbH or your own team which hosting, support tier and database versions apply to your setup
How we build
- Install Zammad in your environment with PostgreSQL 15 or newer, Redis 7 or newer and the cache and search components your topology needs
- Run the built-in OTRS migrator on a new instance and document what it moves, what it does not, and what needs manual rework
- Configure authentication through your identity provider and test channels, email routing and knowledge base content
- Test the migrated data on a copy of production and record the results before any cutover
How we hand over
- Deliver architecture, configuration, runbooks and a migration report that your staff and auditors can read
- Document backup, restore and upgrade procedures for the Zammad application and its database
- Train administrators and agents on the configured workflows, with materials tailored to your queues
- Provide a clear list of open items, gaps against the former OTRS process, and decisions still owned by your team
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Align upgrade windows with Zammad security and minor releases so your patch cadence is documented
- Prepare evidence for compliance assessments, while independent auditors remain responsible for any attestation
- Review retainer scope regularly as your ticket volumes, integrations and team responsibilities change
