Still on OTRS Community Edition 6: upgrade, fork or replace

Still on OTRS Community Edition 6: what the end of life means for your help desk

If your help desk still runs OTRS Community Edition 6.x, you have three realistic paths: buy a current OTRS subscription, move to the Znuny fork, or replace the system with Zammad. The Community Edition reached end of life in December 2020, and the vendor no longer ships security fixes for it. That leaves a ticketing system holding customer data, agent credentials and internal IT records without patches. For many teams the trigger is a renewal date, a data residency requirement that needs the system inside the organization's own network, or a change-control rule that forces a documented decision before the next audit cycle. Start by listing what the instance actually does: which queues, integrations, custom modules and Perl code depend on it, and which personal data it holds.

Znuny is the continuation most teams evaluate first because it stays close to the code they already know. It continues development from OTRS Community Edition version 6.0.30 under the GNU GPL v3 license, so there is no license fee for the software itself. Its maintainers publish a current feature line and a long-term support line, which lets you choose between staying close to the release cadence or holding a stable version for longer. Buying current OTRS keeps you on the vendor's own product line but adds a subscription or hosting quote that you should compare against the cost of running Znuny yourself. Replacing the system with Zammad is a larger change in workflow and customization, and it is covered in the sibling pages. Whichever path you pick, the first deliverable is a written inventory and a test copy, because every option starts from the same unpatched database.

Until you migrate, you carry the risk of an unpatched help desk, so put interim controls in writing. Restrict network access to the web frontend, review agent and administrator accounts, enforce strong authentication where the platform allows it, and confirm that backups are restorable. Ask your security team to record the exposure and an accepted-risk owner with an end date, so the exception is visible to auditors. Confirm the current support and security status directly with OTRS and with the Znuny project, since vendor policies and release dates change. A short, written decision with a dated plan is usually more defensible than an open-ended exception.

What an unpatched help desk must still satisfy

Whichever path you choose, the help desk has to stay patched, run on software its vendor still maintains, and carry a tested way back if an upgrade fails. The four cards below set out those requirements and the checks that confirm them before you commit to a route.

A release line that still receives fixes

Community Edition 6.x no longer receives security fixes, so the first requirement is a release line with a named support window. Znuny publishes a feature line and an LTS line, and the Znuny releases page lists Znuny 7.3.8 and Znuny LTS 6.5.26 as its latest releases. Zammad publishes security releases on more than one line. Confirm each vendor's support end date in writing before you plan around it.

A database still in support

Your upgrade target has to run on a database version its maintainers still support. Znuny lists MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Check your current database version against each list, because a database upgrade may need to happen before the help desk upgrade.

A runtime that meets the prerequisites

Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended. Old operating system images often carry Perl and Apache versions that the target release no longer accepts. Inventory the server OS, Perl modules and web server before you choose a path, and confirm the current prerequisites in the Znuny README.

A tested upgrade path with a rollback copy

Znuny documents a stepwise update path rather than a direct jump from older OTRS versions, so a single in-place upgrade is rarely safe. Restore a copy of the database and the application directory on separate hardware, run each step there, and test ticket search, mail channels, add-on packages and custom code. Keep the untouched production copy as your rollback point until the migrated system has run through a full business cycle.

Ticket history that survives the move

Ticket history, attachments, customer records and audit trails are the assets most likely to be lost in a platform change. Before any migration, export tickets with their articles, attachments and history, then verify record counts and a sample of closed tickets in the target system. Zammad's OTRS migrator is all or nothing and works only on a new instance, so plan a complete export and a verification pass before cutover.

Buying current OTRS, Znuny or Zammad: which path fits which team

This path keeps the OTRS product, its process and ITSM depth, and the vendor relationship your team already knows. OTRS is sold by quote, either as managed hosting or as an on-premise deployment, so the commercial terms follow from a written scope rather than from a published price list. Your team keeps its workflows, configuration and staff habits, but it takes on a new contract and a new set of recurring fees.

Deployment model: Ask whether the quote covers managed hosting or on-premise software you run in your own infrastructure, since the operating burden and data location differ.
Licensing basis: Ask how users or agents are counted, whether the base package and each add-on are priced separately, and what renews annually.
Migration work: Ask what the vendor includes for moving from Community Edition 6 and for testing the upgrade on a copy before cutover.
Support terms: Ask for response expectations, the named support channels and what security fixes are covered during the term.
Exit terms: Ask how you export tickets, configuration and attachments if you leave later.

The cost drivers are user count, add-on modules, hosting model and upgrade services, and all of them recur. Confirm every item in writing before you compare this path with the others.

How each option compares on upgrade effort, support and lock-in

This table sets the three paths side by side on license model, release line, database support, upgrade route, support source, process depth and migration effort. Read each row against your own OTRS version, customizations and ITSM workflows, because the facts below cover vendor claims and release status, not how well each tool fits your processes.

Criterion	Buy current OTRS	Znuny (fork)	Zammad (replace)
License model	Commercial, sold by quote as managed hosting or on-premise	GNU GPL v3, no license fee for the software	AGPL-3.0, no license fee for self-hosted use; paid support plans are optional
Current release line	Confirm the current OTRS release and support terms with OTRS directly	Znuny 7.3.8 and Znuny LTS 6.5.26 are listed as latest releases	Zammad 7.2 released September 23, 2026, with security releases 7.2.1, 7.2.2 and 6.5.5
Upgrade path from 6.x	Confirm with OTRS whether a direct path from your current 6.x exists	Znuny 6.5 accepts updates only from 6.4, so older 6.x installs need intermediate steps	No in-place upgrade from OTRS; move data with the built-in OTRS migrator into a new instance
Database support	Confirm supported databases for the version you buy	MySQL 8.0+, MariaDB 10.3+, PostgreSQL 12.0+, Oracle 19c+	PostgreSQL 15 or newer required, plus Redis 7 or newer
Support source	OTRS, through its contract	Znuny GmbH in Berlin offers professional services; community support is also available	Zammad GmbH sells Business, Enterprise and Corporation support contracts
Process and ITSM depth	Deepest out-of-the-box ITSM, as the product is built around it; confirm against your current use	Keeps the OTRS process model, so existing workflows and add-ons are most likely to carry over	Different process model; test ticket states, SLAs, approvals and CMDB needs against your workflows
Migration effort	Lowest change in workflow if you stay in the product line, but still requires an upgrade plan and testing	Medium: stepwise updates, add-on compatibility and custom Perl code review	Highest: retraining, rebuilding automations and processes, and an all-or-nothing data migration
Lock-in risk	Highest: dependent on one vendor's roadmap, pricing and terms	Lower: open license and a fork with multiple vendors, but you still depend on the Znuny code base	Lower on license terms, but your processes are rebuilt in a new tool

How to move off OTRS Community Edition 6 without losing tickets

This sequence keeps ticket history, attachments and integrations intact while you move from an unpatched OTRS Community Edition 6 installation to a supported target, with a tested rollback path at every stage.

Inventory add-ons, custom code and integrations
Your administrator and the team that wrote any customizations list every installed package, every custom module or Perl change, each template and dynamic field, and every connection to email gateways, monitoring, LDAP or directory services, and other systems. Record the exact OTRS version and the database engine in use. Add-on packages and custom code are the most common reason an in-place update stalls, so each item needs a named owner and a decision: keep, replace or retire. The step is done when the inventory is signed off and every item has a documented disposition.
Choose the target and database
Decide between upgrading to a current commercial OTRS release, moving to the Znuny continuation of the Community Edition, or replacing the platform with Zammad. Znuny documents supported databases, including MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, and runs on Linux with Perl 5.16.0 or higher. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Confirm vendor support terms, add-on compatibility and your own hosting obligations in writing before committing. The step is done when the target, database and server build are approved by the business owner and security team.
Build a test instance from a copy
Restore a recent full backup of the production database and file store onto a separate server that has no outbound mail, no live integrations and no access to production users. Confirm that the copy loads, that attachments open and that the add-on inventory matches production. Keep this copy as the reference for every later test. The step is done when a tester can log in, open tickets from several years back and see the same history and attachments as production.
Run the stepwise update or migration
For Znuny, follow the update path in order, because Znuny 6.5 accepts updates only from 6.4 and not directly from any OTRS version. Apply each intermediate step on the test copy, run the database upgrade scripts and record every error. For Zammad, use the built-in OTRS migrator on a new instance. Migrations are all or nothing, work only on a new instance and accept one source system per run, so plan separate runs if you also import from another tool. The step is done when the migration or update completes on the test copy with a logged result for each stage.
Validate ticket history and integrations
Test with a checklist written before the run: ticket counts by queue and state, article threads, attachments, customer and agent permissions, SLA and escalation rules, email inbound and outbound, and each integration from the inventory. Compare sample tickets field by field against the production export. Sign off each area by name. The step is done when every checklist item passes or has an approved exception and the test report is archived with the cutover plan.
Rehearse the cutover and prepare rollback
Write the cutover runbook with the exact order of steps: freeze new ticket creation or announce a maintenance window, take a final backup, switch mail routing, point integrations at the new system and reopen access. Keep the original production server and its database untouched and reachable until the new system is accepted. Rehearse the full sequence on the test copy and time it internally. The step is done when the runbook has been rehearsed end to end and the rollback steps, including mail routing reversal, are written and tested.
Cut over and confirm acceptance
Execute the runbook during the approved window, verify inbound and outbound email, check that agents and customers can log in, and review the first day of new tickets alongside the migrated history. Keep the rollback plan active until the business owner accepts the new system in writing. Then retire the old server on a documented schedule, keeping a final read-only archive of the old database and file store under your retention policy. The step is done when acceptance is signed off and the archive location is recorded.

What running an unpatched help desk for another quarter actually exposes

Staying on OTRS Community Edition 6 while you decide means running a help desk that no longer receives security fixes from OTRS. The ticket store is the exposure: it holds customer personal data, contact details, attachments and internal correspondence about incidents, accounts and access. A known flaw in the web interface or the application server does not expire because the team is busy. Each week the instance stays unpatched, the window for an attacker who finds one stays open, and the people who would be affected are the customers and staff whose messages sit in the queue.

Interim hardening reduces that window without changing the platform. Start by restricting who can reach the agent interface: limit it to the corporate network or a VPN, and put the customer interface behind a reverse proxy with rate limiting and a web application firewall if your standards call for one. Review every exposed endpoint, including customer portals, inbound mail handling and any API or add-on routes, and disable what nobody uses. Confirm that agent accounts are individual, that inactive accounts are locked, that administrator access is limited to named people, and that database and file backups are tested. Record each change so you can show it later.

Your security team and your assessor decide which of these controls count as adequate for your obligations. Ask them in writing which evidence they will accept for an unpatched application in the interim, whether a documented risk acceptance with an end date is enough, and what they expect from your vendor-support position. Keep the decision and its review date in the risk register. A written plan with a dated path to upgrade, fork or replace is usually easier to defend than an open-ended exception.

What do teams ask before moving off OTRS Community Edition 6?

What does moving off OTRS Community Edition 6 actually cost?

The software itself has no license fee on the Znuny or Zammad side, so the cost is the work and the people. Expect one-time costs for migration analysis, add-on and custom code review, a test copy of the environment, and cutover. Recurring costs are Linux servers, a supported database, staff time for patching and backups, and any support contract you choose to buy. The main cost drivers are how much custom code and how many add-ons you run, how much history and attachment data must move, and how many integrations depend on the current ticket interface. Ask any vendor or partner to price each of these items separately in writing so you can compare options on the same basis.

How long does an OTRS to Znuny or Zammad move take?

No fixed duration is set by the products, so the timeline depends on your environment. Znuny 6.5 accepts updates only from 6.4, so an older installation may need several stepwise upgrades before the final one, and each step needs testing. Zammad migration is a separate project that imports into a new instance, runs all or nothing, and does not support differential runs, so the cutover window and data freeze need planning. The timeline is driven by version distance, custom code, add-on compatibility, data volume and how many business processes must be re-tested. Ask for a written plan with milestones and a testing phase before accepting any date.

Can our own team handle the move without outside help?

Many teams can, provided they have Linux administration, database skills, and someone who understands the OTRS configuration and custom code. The hard parts are rarely the install itself. They are testing custom modules, rebuilding integrations, validating data after upgrade or import, and preparing a rollback plan. Teams should check whether they have staff who can own patching and backups after go-live, since that work recurs for as long as the system runs. If the same people are also responsible for daily service desk operations, plan for reduced capacity during testing. A short internal skills review often settles the question faster than a debate.

Is Znuny a drop-in upgrade for OTRS Community Edition 6?

Znuny is a continuation of OTRS Community Edition 6.0.30 under GNU GPL v3, so it is the closest path for an existing installation, but it is not a silent drop-in replacement. Znuny 6.5 accepts updates only from 6.4, so older systems need stepwise updates. Add-on packages, custom Perl code and any changes you made to core files must be checked against the target release. Znuny documents its own upgrade path and runs on Linux with Perl 5.16.0 or higher, Apache 2 with mod_perl2 recommended, and databases including MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Confirm your database and Perl versions before choosing a target.

What do Zammad's support tiers cover compared with a self-hosted install?

Self-hosted Zammad has no license fee, but Zammad GmbH sells support subscriptions named Business at 2,999 euros per year, Enterprise at 5,999 euros per year and Corporation at 9,999 euros per year, according to its pricing page. Zammad states that self-hosted customers handle updates, backups and availability themselves. The subscription therefore covers vendor support for the software, not operation of your servers. Before buying, confirm what each tier includes in response times, channels and escalation, and whether it covers the database, Redis and Elasticsearch components your deployment uses. Compare that against the cost of your own on-call and patching time.

Is buying external help for the migration worth it?

External help is worth pricing when the in-house team lacks migration experience, the environment has heavy customization, or the business cannot absorb a failed cutover. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any provider to show how they will test on a copy, how they will handle rollback, and who keeps the system patched after handover.

What auditors and assessors ask to see after the move

Whichever path you choose, an assessor will want records that show what is running, how it was tested, how it can be restored and who changed it. Independent auditors issue attestations, not DeployOpen or the software vendor, so the evidence below is what they review rather than a certification in itself.

Release and patch level in use

Record the exact product line, feature or LTS version, database version and operating system in production, with the date each was last patched. For a Znuny path, show that you are on a supported release line such as Znuny 7.3.8 or Znuny LTS 6.5.26, and for a Zammad path, show the release and any security releases applied. Keep a dated inventory so the assessor can see the gap between a vulnerability disclosure and your patch.

Upgrade and migration test records

Keep the results of every run on a copy of production, including the database version, add-on packages tested, custom code reviewed and the data checked after import. For a stepwise Znuny update, show each intermediate version step. For a Zammad migration, record which source data was compared and which fields were confirmed missing or changed, such as the attachments and history you chose not to carry over.

Backup and restore evidence

A backup only counts once a restore has been tested. Keep dated backup job logs for the database and attachment storage, plus a restore test that rebuilt the help desk on separate hardware and checked ticket counts and attachments. Record who ran the test and how long recovery took, so the assessor can compare the result with the recovery targets you set for the help desk.

Access control and admin role lists

Export the list of administrators, agents and their roles and groups at cutover, and again on a set schedule. Confirm that shared or default accounts from the old OTRS installation were removed, and that single sign-on or directory login is used where your identity provider supports it. Assessors commonly ask who can change queues, permissions and email settings, so this list should answer that question directly.

Change records for the cutover

Keep a change ticket for the cutover that lists the planned steps, approvals, the rollback plan, the go or no-go decision and the post-cutover checks. Attach the cutover window, the people who performed each step and any deviations from the plan. The record shows the assessor that the move was controlled, and it becomes the reference point when someone later asks why a setting differs from the old system.

How DeployOpen plans and runs an OTRS exit under your constraints

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a team still on OTRS Community Edition 6, we start by agreeing which of the three paths fits your data, integrations and compliance obligations, then work through that path in a fixed scope agreed in writing before any work begins.

How we scope

We inventory the OTRS version, add-ons, custom Perl code, database engine and the systems that send or receive tickets.
The written scope names the chosen path, whether upgrade to Znuny, a move to Zammad or a commercial OTRS purchase, and the deliverables for each.
We agree in writing which data migrates, which is archived, and which retention and access requirements your auditors expect to see evidenced.

How we build

We rebuild a copy of your production help desk in a separate environment so each upgrade step and migration run is tested before cutover.
For Znuny, we follow the stepwise update path and test add-on packages and custom code against each intermediate release.
For Zammad, we run the built-in migrator on a new instance, then review what was and was not carried over, including user passwords and attachments.

How we hand over

You receive installation, configuration, backup and restore runbooks written for your own operators and change process.
We document the security settings, patch procedure and access model, and record the test results that support your internal review.
Your staff run a supervised cutover and a documented rollback plan, so the team knows how the system behaves before we step back.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the project.
We can prepare systems, controls and evidence for a compliance assessment, while independent auditors issue any audit report or certification.
Ask us to confirm in writing which security release lines and support tiers apply to your chosen platform before the scope is signed.