Znuny vs OTOBO: when to choose each fork
Choose Znuny if you run an OTRS 6 installation and need a maintained successor that stays closest to the code you already operate. Znuny continues the OTRS Community Edition 6.0.30 line under GPL v3, and its Znuny LTS 6.5.26 release suits teams that want a long-term support branch, while Znuny 7.3.8 carries the feature track. Choose OTOBO if you are selecting a Perl ticketing system from scratch or want the OTOBO 11 platform, a GPL v3 fork started in 2019. Its latest releases on otobo.io are 11.0.18 and 11.1.0 Beta3, both dated September 16, 2026. Neither fork is the default. The right one depends on the three factors below.
The decision turns on three things. First, the upgrade path from OTRS 6: confirm with Znuny which LTS or feature release and migration steps apply to your installed version, and ask OTOBO whether its migration service would carry over your database, customizations and add-ons. Second, the database and Perl baseline: Znuny requires Perl 5.16.0 or higher and accepts MySQL 8.0, MariaDB 10.3, PostgreSQL 12.0 or Oracle 19c, while OTOBO 11's requirements call for Perl 5.24.0 or later, Apache HTTP Server 2.4 and MySQL 8.4, MariaDB 10.11, PostgreSQL 13 or Oracle 19c. Compare your current database versions against both lists, because a database upgrade can cost more than the fork itself. Third, which company sells support: Znuny GmbH in Berlin for Znuny, and Rother OSS GmbH for OTOBO.
Before you compare totals, ask each supplier for a quote tied to a written scope that names the migration work, the supported Perl and database versions, and the ITSM and CMDB modules you need. OTOBO documents native and Docker installation and says Kubernetes support is still in development, so confirm which deployment model your platform team can run and whether Znuny's packaging fits it. Neither supplier's pricing appears in the sources for this comparison, so ask what is one-time (migration, customizing, testing) and what recurs (support, upgrades, managed services). Also confirm that OTOBO's lack of Windows support fits your server estate, since it runs only on Linux or other Unix-like systems.
Which OTRS fork fits which team
This table maps common situations to the fork that fits better and names the condition under which the other fork would win. Read each row against your current installation, database standards and whether you need Docker or Windows-hosted operation.
| Situation | Better fit and reason | Choose the other fork when |
|---|---|---|
| Running OTRS 6 today | Znuny, which continues the OTRS Community Edition 6.0.30 line under GPL v3 and publishes Znuny LTS 6.5.26 alongside its feature release | Your team has already standardized on OTOBO 11 or wants its newer Perl and database baseline and has the migration effort budgeted |
| Starting fresh on Perl | OTOBO 11 needs Perl 5.24.0 or later and Apache 2.4, a newer baseline than Znuny's Perl 5.16.0 minimum, so it suits new builds on current distributions | You must run an older Perl stack or need Znuny's lower Perl floor for an existing server image |
| Needing Docker | OTOBO documents a Docker option that bundles the web and database servers, with Kubernetes support still in development | Your deployment standard is a native Znuny install on Debian or Red Hat and you do not want a containerized runtime to support |
| Running an ITSM and CMDB program | OTOBO offers an optional ITSM component with a CMDB, so it is the closer match for configuration management scope | You want Znuny's ITSM and help desk modules as described in its README and can manage CMDB needs in a separate tool |
| Wanting a vendor migration service | OTOBO's maker otobo.io offers an OTRS to OTOBO migration service, so a fixed-scope migration path is available from the source | Your team prefers Znuny GmbH's professional services in Berlin or wants to stay on the Znuny code line with the same vendor |
| Operating on Windows | Neither fork suits Windows hosting: OTOBO documents that Windows is not supported, and Znuny is described for Linux, preferably Debian or Red Hat | Windows is not a requirement for either; confirm Znuny's Windows position directly with the vendor before any Windows-based plan |
| Database standard is MySQL 8.0 or MariaDB 10.3 | Znuny supports MySQL 8.0 or later and MariaDB 10.3 or later, which matches older database standards | Your standard is MySQL 8.4, MariaDB 10.11 or PostgreSQL 13, which are the OTOBO 11 minimums |
How Znuny and OTOBO are built and deployed
Znuny and OTOBO both descend from OTRS Community Edition and share a Perl, Apache and relational database stack, so most day-two work looks familiar on either side. The differences sit in supported Perl and database versions, Docker maturity, and the platforms each one will run on, and those details decide patching and hosting effort.
Shared OTRS CE lineage
Znuny continues OTRS Community Edition 6.0.30 under GPL v3, and OTOBO is a GPL v3 fork of OTRS Community Edition started in 2019. Both inherit the same ticket model, so administrators and customizers often carry skills across. Confirm which release line you need, since Znuny keeps a feature line and an LTS line in parallel, and check whether your existing OTRS customizations rely on APIs that changed in either fork.
Linux and Unix-like hosts
Znuny runs on Linux and is preferably deployed on Debian or Red Hat. OTOBO 11 runs on Linux or other Unix-like systems, and its documentation states that running OTOBO on Microsoft Windows is not supported. If your platform team standardizes on Windows Server, OTOBO is not an option without a different host, so settle the operating system before comparing features.
Perl and Apache baselines
Znuny requires Perl 5.16.0 or higher with Apache 2 and mod_perl2 recommended. OTOBO 11 needs Perl 5.24.0 or later and Apache HTTP Server 2.4. Your patch cadence depends on whether your distribution ships these versions, so check the Perl version in your base image before committing. Perl module upgrades are a recurring task on both, and the CPAN dependency set should be pinned and tested after each OS update.
Database choice and version floors
Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. OTOBO 11 requires MySQL 8.4 or later, MariaDB 10.11 or later, PostgreSQL 13 or later and Oracle 19c or later. A database that meets one floor may fail the other, so an existing MariaDB 10.3 server may need an upgrade before an OTOBO move. Confirm the engine you will standardize on before patch windows are planned.
Optional Elasticsearch and Redis
OTOBO 11 lists Elasticsearch 7.x and Redis as optional components. Znuny's documentation for these optional services should be checked with Znuny GmbH, since the supplied sources do not confirm equivalent requirements. Adding either service adds a component to patch, back up and monitor, and it changes your failure modes for search and session handling. Decide whether you need them for your ticket volume before you size the host.
Docker deployment details
OTOBO can be installed natively or with Docker, and that image bundles the web and database servers, while Kubernetes support is still in development. The supplied sources do not confirm the Docker image, supported container layout or upgrade path for Znuny, so ask Znuny GmbH for its container support statement in writing. Containerized upgrades reduce host drift but still require Perl module and schema checks against each release.
Release lines, databases and Perl requirements compared
This table compares the requirements and component support each fork publishes, row by row, so you can check them against your current OTRS 6 estate or target stack. Where a row is not covered by the vendor material we reviewed, the cell names who to ask before you commit. The main takeaway is that the two forks differ most on minimum database versions, Perl baseline and Docker packaging, so those rows should drive your platform check.
| Capability | Znuny | OTOBO |
|---|---|---|
| Latest releases listed by vendor | Znuny 7.3.8 (feature line) and Znuny LTS 6.5.26, per znuny.org in October 2026 | OTOBO 11.0.18 and OTOBO 11.1.0 Beta3, both dated September 16, 2026, per otobo.io |
| Minimum Perl version | Perl 5.16.0 or higher | Perl 5.24.0 or later |
| Web server requirement | Apache 2 with mod_perl2 recommended | Apache HTTP Server 2.4 |
| MySQL minimum | MySQL 8.0 or later | MySQL 8.4 or later |
| MariaDB minimum | MariaDB 10.3 or later | MariaDB 10.11 or later |
| PostgreSQL minimum | PostgreSQL 12.0 or later | PostgreSQL 13 or later |
| Oracle minimum | Oracle 19c or later | Oracle 19c or later |
| Docker support | Confirm current container images and support scope with Znuny GmbH | Installable with Docker, which bundles web and database servers |
| Kubernetes status | Confirm with Znuny GmbH before planning a cluster deployment | Support is in development per OTOBO 11 requirements; confirm timing with Rother OSS GmbH |
| Windows support | Runs on Linux, preferably Debian or Red Hat; confirm any other OS with Znuny GmbH | Not supported on Microsoft Windows; Linux or Unix-like systems only |
| Optional Elasticsearch and Redis | Confirm which search and cache components your feature set needs with Znuny GmbH | Elasticsearch 7.x and Redis are optional components |
| ITSM and CMDB component | Described as a ticketing system for customer service, help desk and IT service management; confirm CMDB module scope with Znuny GmbH | Optional ITSM component with a CMDB, alongside a knowledge base and FAQ |
Licensing, support vendors and what is paid for each fork
Both Znuny and OTOBO are distributed under the GNU General Public License v3, and both descend from OTRS Community Edition. The license governs what you may copy, modify and redistribute, but it does not decide who supports your installation or what that support costs. Free use of the code does not mean free operations, so the paid layer has to be evaluated separately for each fork.
- Source access: Both projects publish their source under GPL-3.0, so you can inspect, patch and self-host either one without a license fee.
- Redistribution duties: If you distribute modified builds to third parties, GPL-3.0 obligations apply to those builds. Internal use alone does not trigger them.
- Support is separate: The license grants no support entitlement. Vendor support, managed services and customizing are sold as services.
- Custom code: Your own modules and extensions remain your responsibility to maintain across upgrades, whichever fork you choose.
Confirm with your legal team how GPL-3.0 applies to your planned customizations and whether any internal integrations would count as distribution.
Znuny is the GPL-3.0 continuation of OTRS Community Edition 6.0.30, which reached end of life in December 2020. Development continues in two release lines: a feature line, where the latest release listed is Znuny 7.3.8, and a long-term support line, where the latest listed is Znuny LTS 6.5.26. Professional services come from Znuny GmbH in Berlin, and the documentation portal keeps separate guides for the feature and LTS versions.
- Feature line: Znuny 7.3.8 is the current feature release listed on znuny.org as of October 2026.
- LTS line: Znuny LTS 6.5.26 suits teams that prioritize a stable branch over new features.
- Paid services: Znuny GmbH provides professional services. The supplied facts do not list specific service tiers or prices.
- Documentation: Separate documentation for each release line helps you match guides to the version you run.
Ask Znuny GmbH which release lines and service levels it covers, how long each LTS line is supported, and request a written quote tied to your scope.
OTOBO is a GPL-3.0 fork of OTRS Community Edition started in 2019. Rother OSS GmbH describes itself as the source code owner and maintainer, and it sells consulting, training, support, managed services and customizing. The latest releases listed on otobo.io are OTOBO 11.0.18 and OTOBO 11.1.0 Beta3, both dated September 16, 2026, and the company also offers an OTRS to OTOBO migration service.
- Maintainer role: Rother OSS GmbH is named as the source owner and maintainer, so questions about the roadmap and code direction go to one company.
- Service catalog: Consulting, training, support, managed services and customizing are all offered, which covers both run and change work.
- Migration service: An OTRS to OTOBO migration service is listed, relevant if you are leaving an OTRS installation.
- Pricing: No prices are published in the supplied facts for any of these services.
Request written quotes that separate support, managed operations and customizing, and confirm which OTOBO versions each covers.
Both forks sell services, but the supplied facts describe different service catalogs and no published prices for either. The cost of each option depends on what you buy, who performs the work and how much custom code you carry. Recurring spend usually comes from support and managed operations, while migration and customizing are typically one-time engagements.
- Znuny side: Professional services from Znuny GmbH in Berlin, with no tier or price detail in the supplied facts.
- OTOBO side: Consulting, training, support, managed services, customizing and a migration service from Rother OSS GmbH.
- One-time work: Migration, initial configuration and custom development are usually scoped once, then maintained.
- Recurring work: Support, patching, upgrades and managed hosting recur, and their cost rises with the number of customizations and integrations.
For each fork, ask for a written scope, the named deliverables, the support hours or response terms, and whether upgrades between release lines are included. Compare the two quotes on identical scope.
What drives the running cost of each fork
The running cost of either fork is driven less by licence fees, since both are GPL-licensed and free to download, than by the infrastructure, the administration skills and the upgrade work you carry each year. For OTOBO, the documentation suggests 8 GB of RAM for production with 16 GB recommended, a 3 GHz Xeon-class CPU and 40 GB of storage, and 4 GB of RAM for testing. Budget for a separate test instance sized at that lower figure, because upgrades should be rehearsed before they touch production. Znuny's own sizing guidance is not part of the facts supplied for this page, so ask Znuny GmbH or check the Znuny documentation at doc.znuny.org before you size either environment.
Recurring cost sits mostly in people. Both forks are Perl applications on Apache, so the team needs Perl and database administration skills, whether that is in-house staff or a provider. OTOBO 11 needs Perl 5.24.0 or later and Apache HTTP Server 2.4, and Znuny needs Perl 5.16.0 or higher, so confirm which Perl and database versions your operating system ships before you commit. Vendor support is optional but changes the cost profile: Rother OSS GmbH sells consulting, training, support, managed services and customizing without published prices, and Znuny GmbH offers professional services. Ask each vendor for a written quote tied to a named scope, response expectations and whether upgrades are included.
Upgrade effort and customization are where long-term costs diverge. Moving between release lines, for example from OTRS 6 to either fork or from one major line to the next, means testing custom modules, ITSM and CMDB configuration and any database changes against a copy of production. Customizing ITSM or CMDB modules raises that cost because each local change must survive future upgrades, so keep a written register of changes and ask both vendors how they handle customizations during an upgrade. The one-time migration work, covering data export, schema checks and cut-over, is separate from these recurring costs and should be quoted as its own line. Rother OSS offers an OTRS to OTOBO migration service, and you should ask Znuny GmbH whether it has an equivalent.
Moving an OTRS 6 installation to Znuny or OTOBO
This sequence takes an OTRS 6 installation through a tested move to Znuny or OTOBO, ending with a cutover that has been rehearsed on real data and a support plan for the first weeks in production.
Inventory customizations, modules and integrations
Your administrator or implementation partner lists every custom Perl module, add-on, package, template, external interface and scheduled job on the current OTRS 6 system, along with the Perl modules each one loads from CPAN or the operating system. Record who owns each item and whether it still serves a business process. The output is a signed-off inventory that separates what must move, what must be rebuilt and what can be retired. You know this step is done when every item has a disposition and an owner.
Check database and Perl baselines
Compare your current database engine, version, Perl version and web server against the requirements of the target product. For Znuny, confirm the Perl 5.16.0 minimum, the supported database versions and the recommended Apache 2 with mod_perl2 setup. For OTOBO 11, confirm Perl 5.24.0 or later, Apache HTTP Server 2.4 and the database versions it lists, which are newer than the Znuny minimums in several cases. Where a database or operating system is below the baseline, schedule that upgrade first. The output is a written compatibility report that both the team and the vendor have reviewed.
Build a test environment from a production copy
Provision a non-production server on the same operating system family and database engine as the target, using the install method your team has chosen, native or Docker in the case of OTOBO. Restore a copy of the production database and file storage, then point test mail, LDAP and integrations at sandbox endpoints so no live notifications are sent. Confirm that the test system starts, logs in with a sample of real agent and customer accounts and shows the expected queues. The output is a working test instance with a documented build script.
Port customizations and rebuild add-ons
Reapply or rewrite each item on the inventory that must survive, starting with custom modules and templates, then test each one against the target version. Items that the target product no longer needs, or that exist in a maintained form, should be replaced rather than ported. Keep changes in version control so each adaptation can be traced and reviewed. The output is a build that passes functional tests for ticket creation, escalation, notifications, customer portal access and reporting. You know this step is done when the test plan has no open high-severity defects.
Rehearse the data migration
Run the full migration sequence against the test environment at least once from a fresh production export, measuring the elapsed time and recording every error or manual correction. Verify that tickets, articles, attachments, users, queues, roles, dynamic fields and system configuration arrive intact by comparing counts and sampling records. Repeat the rehearsal until two consecutive runs complete with no unexplained differences. The output is a timed, repeatable runbook and a reconciliation report signed by the business owner.
Execute the cutover
On the agreed change window, stop incoming mail and scheduled jobs on OTRS 6, take a final full backup, run the rehearsed migration on production, switch DNS or the reverse proxy and restart mail and cron processes on the new system. Keep the old server in read-only mode until the post-cutover checks pass. The output is a live new system and a documented rollback point. You know this step is done when a test ticket created by email, by the portal and by the API appears correctly and the old server has stopped accepting new work.
Stabilize and hand over to support
Monitor logs, mail queues, scheduled tasks and performance for an agreed period after go-live, and correct issues in the same order they were found in rehearsal. Confirm which support contract covers defects and upgrades after the move, and whether the vendor's standard support, a managed service or your internal team owns the next release cycle. For Znuny, confirm the upgrade path between your target release line and the current Znuny or Znuny LTS documentation with Znuny GmbH. For OTOBO, otobo.io offers an OTRS to OTOBO migration service, so ask whether it covers the rehearsal, the cutover or only one of them. The output is a handover document with runbooks, owners and a dated support contract.
Where Znuny and OTOBO implementation projects usually run long
The longest delays in a Znuny or OTOBO project usually come from custom code, not from the base install. Teams that moved from OTRS 6 often carry custom modules, ticket templates and agent workflows written against the OTRS 6 API. Each one has to be inventoried, checked against the target version and retested, and that work tends to grow once developers find undocumented dependencies. Ask the vendor or your own developers for a list of every custom package, every ticket hook and every scheduled task before anyone estimates the work. Plan a Perl module review as well. Both platforms run on Perl, but the minimum versions differ (Znuny needs Perl 5.16.0 or higher, OTOBO 11 needs Perl 5.24.0 or later), and CPAN modules pinned on an old host can block an upgrade. Confirm the exact Perl and database versions on your target hosts early, since the database minimums also differ (for example, OTOBO 11 requires MySQL 8.4 or later, while Znuny supports MySQL 8.0 or later).
Identity and data loading add their own delays. LDAP or SSO integration depends on directory group structures, service account rights and certificates that sit with other teams, so schedule those requests at the start. For ITSM and CMDB data, the load is rarely a one-time import. Configuration items need owners, classes and relationships that match the target model, and duplicate or stale records surface only during reconciliation. Testing customized agent workflows is the step most often cut short, so name test users for each queue and role, and agree which workflows must pass before cutover. Clients must provide named system owners who can make decisions within days, test users from each support team, read access to the source database and attachments, and fixed change windows for cutover and rollback. DeployOpen scopes these items in writing before work starts, with deliverables and timelines agreed in advance, so each dependency above appears as a named client input rather than a surprise. Ask any implementation partner, including DeployOpen, to show how those dependencies are recorded in the statement of work.
Questions buyers ask before choosing a fork
Can a team on OTRS 6 move to Znuny without rebuilding its setup?
Possibly for a standard setup, but plan it as a staged migration and test every customization. Znuny continues OTRS Community Edition 6.0.30 under GPL v3, so it is the closest continuation of the code line your team already runs. Your path still depends on installed modules, custom scripts, the database engine and the target release. Znuny requires Perl 5.16.0 or higher, and supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. Confirm the supported upgrade route with Znuny or Znuny GmbH before you set a cutover plan. Custom code is the usual reason a move that looks simple takes longer, so ask for a written inventory of customizations first. Current releases are listed on the Znuny releases page.
What drives the cost and effort of running Znuny or OTOBO?
Both forks are GPL v3, so the main costs are people, hosting, and any paid support, not licence fees. One-time costs include the migration, data cleanup, customization and testing. Recurring costs include staff time for upgrades, database and Apache maintenance, backups, monitoring and any support contract. OTOBO's documentation suggests 8 GB of RAM (16 GB recommended), a 3 GHz Xeon-class CPU and 40 GB of storage for production, so hosting size follows from user count and ticket volume. Rother OSS sells consulting, training, support and managed services without published prices, and Znuny GmbH offers professional services in Berlin. Ask each vendor for a quote that separates migration, customization, support tiers and hosting, and ask which items recur every year.
Does OTOBO's Docker option remove the need for a platform engineer?
No. Docker reduces installation work but leaves upgrades, data protection and integration with your environment to your team. OTOBO can be installed natively or with Docker, and the Docker option bundles the web and database servers, which suits a test environment or a quick evaluation. Production still needs decisions on backups, TLS, storage sizing, monitoring, mail and identity integration, and the host should meet the documented production sizing. Kubernetes support is described as in development, so check its status before designing a cluster deployment. Ask how container images are upgraded, where data volumes live and how restores are tested. Whether you need a dedicated platform engineer depends on how many other systems your team already runs and how often you plan to upgrade.
How long does an OTRS to Znuny or OTOBO migration take?
No public duration covers your move, and the length depends on scope you can measure before you start. The main drivers are the number of queues, dynamic fields and workflows, custom scripts or modules, the volume of ticket history and attachments, and any change of database engine. Integrations with LDAP, mail, monitoring and external systems add test cycles, as does the number of user acceptance rounds. Each fork's migration support is sold separately, and otobo.io offers an OTRS to OTOBO migration service. Ask for a written plan with milestones, a test cycle count and a cutover window, and compare vendors on the same inventory. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts.
What does the migration need from our internal IT team?
Your team needs named owners for each skill area, even if an outside partner does the bulk of the work. A Linux administrator is needed for Debian or Red Hat hosts, a database administrator for the chosen engine, and someone who understands Perl if custom code is involved. Queue owners from the service desk must test workflows and sign off on results, and the mail and identity administrators must confirm integrations. Ongoing, someone must review each upgrade, test restores and manage access. The time each person commits depends on the customization load and the number of integrations, so ask any vendor to list roles and expected involvement in the written scope.
Can our own team do the OTRS migration without an outside partner?
Yes, if the team already has Linux, database and Perl skills, protected time and a tested backup and rollback plan. The risk lies in the cutover and in the customizations nobody documented. Three routes are common: an in-house migration, the vendor's own services from Znuny GmbH, Rother OSS or otobo.io, or an implementation partner. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, on fixed-scope work agreed in writing. A quote follows from that written scope, and ongoing support is available as a retainer. DeployOpen is not an official partner or reseller of Znuny or Rother OSS, so confirm what each option includes before comparing them.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Znuny vs OTOBO, we start with your current OTRS version, database, Perl runtime and ITSM needs, then agree the work in writing before any build begins.
How we scope
- Inventory your current OTRS or Znuny version, database engine, Perl runtime and web server before choosing a target.
- Agree in writing which ticket queues, ITSM and CMDB modules, and customizations are in scope.
- Confirm with each vendor which release line, support terms and paid services your organization will rely on.
How we build
- Install the chosen fork natively or in Docker on infrastructure you control, with the database and web server settings you approved.
- Migrate ticket history, users, queues and attachments in a rehearsed sequence, then compare record counts and sample tickets.
- Test authentication, email channels, permissions and any custom modules against the written acceptance criteria.
How we hand over
- Document the installed configuration, upgrade path, backup procedure and the Perl or database dependencies your team must maintain.
- Walk your administrators through daily operations, module customizations and the rollback steps for the migration.
- Deliver the runbook and test evidence as fixed deliverables listed in the agreed scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants it.
- Plan future upgrades between release lines, such as moving from a 6.x LTS line to a newer feature line, as a separate written scope.
- Ask any support provider to confirm response terms in writing, since DeployOpen does not publish a price list or service levels.
