Zammad vs OTOBO: Modern Helpdesk or OTRS Fork?

Choosing an open-source ticketing system often comes down to a fundamental decision between two different architectural philosophies. On one side is Zammad, an application built from the ground up as a modern helpdesk using Ruby on Rails. On the other side is OTOBO, a fork of the OTRS Community Edition that brings the predecessor's proven Perl logic into a modernized, Docker-centric operational context. For IT leaders and administrators, the question isn't just about feature lists; it's primarily about long-term maintainability, integration with existing infrastructure, and adaptability to specific ITSM processes.

Both systems are actively driven by German companies (Zammad GmbH and Rother OSS GmbH) and fall under open-source licenses (GNU AGPL v3.0 and GNU GPL v3.0, respectively). Even so, they differ fundamentally in their technological core and their approach to ticket management.

Architecture and Technology Stack: Ruby vs. Perl

The most striking difference lies in the chosen programming language and the resulting framework. Zammad uses Ruby on Rails in the backend and Vue.js for the frontend. This combination aims at a reactive user interface that enables real-time updates without manually reloading the page. For data storage, Zammad relies primarily on PostgreSQL. Redis is strictly required for real-time communication between server and client, while Elasticsearch (optional, but strongly recommended for production environments) handles full-text search Source.

OTOBO, on the other hand, is based on Perl and utilizes the OTRS framework grown over decades. Its modernization is particularly evident in deployment and supported services. Alongside PostgreSQL, OTOBO also supports MariaDB and MySQL as databases. The web server stack is flexible: alongside Nginx and Apache (with mod_perl), Gazelle is used. A central feature of OTOBO is its "Docker-first" strategy, which aims to encapsulate the complexity of Perl dependencies using pre-configured container environments Source.

While Zammad pursues a more monolithic web app structure that relies heavily on WebSockets for interaction, OTOBO stays true to the classic request-response structure while supplementing it with modern components like Elasticsearch for search and Redis as a cache.

Origins and Migration Paths

Choosing one system often depends on an organization's technological history. OTOBO is a direct descendant of the OTRS Community Edition. This means that the internal data structure, ticket attribute logic, and configuration mechanisms (SysConfig) are immediately understandable for administrators with OTRS experience. Moving from OTRS Community Edition to OTOBO is designed as an in-place migration that largely preserves existing data and processes Source.

Zammad was launched in 2016 as an independent project with the goal of overcoming the shortcomings of classic ticketing systems through a modern UX. While Zammad offers dedicated migration tools for OTRS, Zendesk, and Freshdesk, switching always entails a system break. Workflows must be re-mapped in Zammad's logic, which offers an opportunity for process cleanup but also requires initial effort.

Feature Set: Helpdesk Focus vs. ITSM Process Depth

Zammad positions itself strongly as a multi-channel helpdesk. The integration of email, telephony (CTI), chat, and social networks like Facebook or Twitter is deeply anchored in its core. Features such as "AI ticket summaries", introduced with version 7.0, highlight the focus on increasing efficiency in daily agent work Source. The user interface allows agents to work on multiple tickets simultaneously (tab concept) without losing context.

OTOBO, meanwhile, plays to its strengths where complex IT service management processes need to be mapped. Integrated process management allows the definition of detailed workflows that go beyond simple status changes. Version 11.1 also further strengthened OAuth token management and OpenID Connect integration. OTOBO also integrates initial AI features via "Rotobo" (currently in beta), but its primary orientation remains closer to classic ITSM structures Source.

Operations and Deployment Compared

Both systems support modern deployment methods via Docker Compose, but offer different alternatives:

• Zammad: Allows installation via native Linux packages (.deb, .rpm) or directly from sources. Package management for extensions uses the .szpm format.
• OTOBO: Places a very strong focus on Docker, but also offers a classic Linux installation. Extensions are managed in the .opm format (familiar from the OTRS ecosystem).

Regarding search, both systems use Elasticsearch to deliver high-performance results even with large datasets. In Zammad, Elasticsearch is essential for features like global search, whereas OTOBO uses Elasticsearch to replace the historically slower SQL-based search of OTRS.

An important aspect for admins is monitoring. Zammad provides a health-check API, while OTOBO relies on container health checks and daemon status checks. Backup strategies are well documented for both, with Zammad providing specific scripts for dumping the database and filesystem Source.

Community and Governance

Both projects follow a vendor-driven open-source model. Zammad GmbH directs the development of Zammad, while Rother OSS GmbH stands behind OTOBO. A look at GitHub statistics (as of July 30, 2026) shows a higher number of stars (5800) and forks (1000) for Zammad compared to OTOBO (331 stars, 89 forks). This indicates a broader developer base for Zammad, whereas OTOBO serves a specialized community from the former OTRS environment.

Which System Fits Whom?

The choice between Zammad and OTOBO should be made based on the following criteria:

Zammad tends to be the better fit if:

• A modern, reactive user interface for maximum agent productivity is prioritized.
• Communication across many different channels (chat, social media, email) needs to be centralized.
• No legacy baggage from an OTRS installation needs to be carried over.
• A Ruby-based stack fits into the internal know-how structure.

OTOBO tends to be the better fit if:

• An existing OTRS Community Edition installation needs to be migrated without abandoning familiar logic.
• Complex, multi-stage ITIL or business processes must be mapped that require OTRS process management.
• A Docker-centric infrastructure is preferred and Perl expertise is available.
• A classic ITSM system with CMDB options (via add-ons) is desired.

Data Status and Limitations of the Comparison

This comparison is based on project specifications and releases up to July 30, 2026. Note that artificial intelligence (AI) features in particular are in a rapid development phase in both systems. While Zammad already offers integrated features with version 7.0, they are still partially in beta status in OTOBO 11.1. The performance of both systems depends heavily on the correct configuration of Elasticsearch and the underlying hardware; blanket statements about scalability cannot be derived from version numbers alone.

Conclusion

Zammad and OTOBO represent different generations of ticketing systems. Zammad breaks with old conventions to offer a state-of-the-art web experience, while OTOBO rescues the proven and powerful functional world of OTRS into the container era. Both systems are stable, actively maintained, and suitable for enterprise use.

To make a final decision, we recommend taking a detailed look at the feature matrix in our interactive comparison tool to weigh specific requirements such as LDAP integration, SSO procedures, or API capabilities in detail.