OTOBO vs Znuny 2026: Which OTRS Fork Fits Best?

The decision between OTOBO and Znuny marks the moment for many IT organizations when they emancipate themselves from the original OTRS Community Edition. Both systems share the same Perl-based technological DNA and use the .opm package format. However, since their forks in 2020 and 2021, they have pursued different philosophies regarding operations, infrastructure requirements, and release cycles. While Znuny focuses on continuity and maintaining a classic LAMP architecture (Linux, Apache, MySQL/MariaDB/PostgreSQL), OTOBO has modernized the stack through a Docker-centric deployment and mandatory Elasticsearch integration for search functions. For administrators and technical decision-makers, this results in significant differences in maintenance, search scalability, and long-term update planning.

Architecture and Deployment: Docker-First vs. Classic LAMP

A key difference between the two systems lies in their recommended and documented deployment approach. OTOBO was developed from the ground up with a strong focus on containerization. The standard installation is based on Docker Compose, dividing the system into multiple containers, including Nginx as the web server, Gazelle as the application server, and dedicated containers for MariaDB, Redis, and Elasticsearch. This structure enables a clear separation of services, but requires administrative expertise in handling Docker resources and container orchestration.

Znuny, on the other hand, stays true to the classic installation method familiar to many administrators from the OTRS Community Edition. Primary deployment methods are Linux packages or installation from source on a classic LAMP stack with Apache and mod_perl. While Znuny also offers Docker support, its architecture is designed to run performantly directly on the operating system without container abstraction. According to its data sheet, a technical unique selling proposition of Znuny compared to OTOBO is its support for Oracle databases, which is particularly relevant in enterprise environments with existing database requirements.

Search Technology and Infrastructure Dependencies

The handling of the search function is a decisive criterion for hardware sizing. OTOBO natively uses Elasticsearch for full-text search. This leads to improved search speed and advanced filtering options for large data volumes, but increases the complexity of the stack. Elasticsearch requires significant RAM resources, which must be factored into server instance planning. Without a functioning Elasticsearch service, the core functionality of OTOBO is not fully available in current versions.

Znuny follows a more conservative approach here. In its standard configuration, the system uses the full-text search of the underlying database (MySQL, MariaDB, or PostgreSQL). This keeps the infrastructure footprint smaller since no additional Java-based service like Elasticsearch needs to be managed. For organizations preferring a lean installation without an additional search engine, Znuny offers a lower barrier to entry for operations. However, Znuny also supports Redis for caching to stabilize performance under heavy loads.

Release Strategy: LTS Stability vs. Feature Speed

Release planning reveals distinct differences in objectives. Znuny offers an explicit Long-Term Support (LTS) version with its 6.5 branch. This version is technologically closest to the original OTRS Community Edition 6 and receives primarily security updates and bug fixes. This gives companies high planning reliability for stable, long-term operations. In parallel, Znuny drives modernization with version 7.3 (as of July 2026), particularly through a revamped agent interface that replaces the old 6.x UI (Source: Znuny Documentation).

OTOBO has a more dynamic release cycle. The current version 11.1 (released on June 24, 2026) already integrates modern features such as OAuth token management, OpenID Connect for Single Sign-On (SSO), and native AI support named "Rotobo" in beta status (Source: OTOBO Release Notes). While OTOBO also maintained a stable branch with a Docker focus in version 10.1, its development focus clearly lies on the rapid delivery of new features and framework modernization.

Package Compatibility and the Ecosystem

Since both systems use the .opm format for extensions, a certain proximity within the ecosystem remains. However, the frameworks are drifting apart. As of the current status (July 30, 2026), the directory lists 115 available packages for Znuny, while 53 packages are listed for OTOBO. This difference is partly explained by Znuny's longer history as the direct successor to the Community Edition and broad support from third-party vendors who were often able to port their existing OTRS extensions to Znuny with minimal effort.

In OTOBO, extensions often require specific adjustments due to profound changes to the frontend (skins, CSS structure) and the integration of Elasticsearch. Migrating from an existing OTRS Community Edition 6 is possible to both systems, where the path to Znuny 6.5 LTS is often considered the more conservative technical path, while switching to OTOBO 11.x is more akin to system modernization.

Which System Fits Whom?

The choice between the two systems should be made based on existing IT strategy and operational requirements.

OTOBO tends to be the better choice if:

• A modern, container-based infrastructure (Docker/Docker Compose) is already standard in your company.
• High demands are placed on search functionality, and resources for operating Elasticsearch can be provided.
• Value is placed on modern authentication methods like OpenID Connect and integrated AI experiments (beta).
• A more radical break with legacy OTRS habits in favor of a modernized architecture is desired.

Znuny tends to be the better choice if:

• Maximum stability and long maintenance cycles (LTS) are top priorities for productive operations.
• The system should run on a classic LAMP stack without Docker constraints.
• Integration into an Oracle database environment is strictly required.
• A very large number of specific .opm add-on packages are needed, which are more widely available in the Znuny ecosystem.
• Administration wants to stay close to the familiar OTRS operating concept.

Database and Validity of the Comparison

This comparison is based on specifications and release states as of July 30, 2026. The package counts and version numbers mentioned (OTOBO 11.1, Znuny 7.3.5) are snapshots. Note that statements about performance or stability always depend on individual configuration and underlying hardware. Since both projects are vendor-driven (Rother OSS for OTOBO, Znuny GmbH for Znuny), long-term development is closely tied to these companies' business strategies. Both systems operate under open-source licenses (GPL v3.0 and AGPL v3.0 respectively), which ensures code independence.

Conclusion

Both OTOBO and Znuny are powerful evolutions of the OTRS Community Edition with different focus areas. There is no blanket winner; the choice is between technological modernization (OTOBO) and proven continuity with enterprise options like Oracle support (Znuny). Before migrating, administrators should check which specific .opm packages are indispensable and whether the target infrastructure meets requirements (Docker/Elasticsearch vs. LAMP/DB search).

For a detailed side-by-side comparison of individual features and technical parameters, please use the interactive comparison table, where you can evaluate OTOBO, Znuny, and other systems directly next to each other.