Which fits your OTRS situation: OTRS or Znuny?
OTRS fits teams that want vendor-issued, quote-based support and a managed or on-premise contract, with one company accountable for the product and its roadmap. Znuny fits teams that want the GPL v3 code base, self-hosted control over the software and the ability to staff or contract their own operations. Neither choice is wrong on features alone, so the decision turns on four things: the support model you need, the skills you already have in-house, how much custom code and add-on logic you depend on, and how much budget you can commit to people rather than licenses.
Start with the renewal or quote in front of you. Ask OTRS what the quote covers in writing: user counts, the base package, each add-on, hosting or on-premise responsibilities, and what support level is included. Then compare that with the people you would need to run Znuny yourself, including Linux, Perl, web server and database administration, plus patching and backup. If your team has that depth, the license line in the quote becomes a question about what you are paying for. If it does not, a Znuny deployment still needs a plan for who answers at 2 a.m., which is where Znuny GmbH's professional services in Berlin, described on znuny.org, come into the picture.
The third question is how much of your OTRS instance is custom. Heavily customized installations, with bespoke modules, scripts or integrations, carry the most migration risk whichever way you go, so list them before you talk to anyone. For a Community Edition 6 installation that no longer receives security fixes from OTRS, treat the decision as urgent: staying unpatched while you deliberate is itself a risk. Confirm with your security team how long you can accept that exposure, and set the decision date accordingly.
Which option fits which scenario
This table matches common OTRS situations to the option that usually fits best and the condition that tips the choice. Read each row against your own renewal date, team skills and data rules, since the right answer depends on those more than on feature lists. Most organizations on OTRS will find one row that describes them closely.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Fixed-budget renewal with an existing OTRS license | Stay on commercial OTRS for the current term | Your budget is set for this cycle, the contract still has a clear end date, and a migration project cannot be funded before then. Ask the vendor for the terms of the current quote before deciding. |
| Team with Perl and Linux staff and custom code | Znuny | You have engineers who can maintain Perl modules, Apache with mod_perl2 and a supported database, and your custom code depends on OTRS internals. Znuny keeps that code base close to its OTRS roots, so review each customization during the upgrade path. |
| Regulated organization wanting full data residency control | Znuny, or Zammad if a different tool is acceptable | You need every ticket, attachment and log on servers you control, with no vendor-hosted component required. Both run self-hosted, so confirm your assessor's evidence expectations for access control, backups and patching. |
| Team that wants a vendor-backed contract | Znuny with Znuny GmbH professional services, or commercial OTRS | You need a named vendor to answer for upgrades, defects and support hours in writing. Znuny GmbH in Berlin offers professional services, so request the service levels and scope in a written quote before comparing with OTRS. |
| Team that wants a different tool entirely | Zammad, or GLPI for internal IT service management | Your priority is a newer interface, channels and knowledge base, or you are moving away from ticket process depth. Zammad has a built-in OTRS migrator, but migrations are all or nothing and work only on a new instance. |
| Small IT team with no Perl or Linux administration skills | Commercial OTRS managed hosting, or a different tool | Nobody on staff can operate Apache, Perl modules and database upgrades reliably. Self-hosting Znuny without that skill set shifts risk onto a few people, so confirm who will patch and back up the system. |
Where your ticket data lives and who controls it
Ticket data in a help desk includes customer details, internal incident narratives and attachments, so where it sits and who can reach it matters as much as features. The cards below cover the decisions that differ between OTRS managed hosting, OTRS on-premise and self-hosted Znuny, and the points to settle in writing before signing.
Data location under OTRS hosting
Under OTRS managed hosting, the vendor or its hosting provider decides which facility and region store your tickets, attachments and database backups. Under on-premise OTRS, the location is your own choice. Ask the vendor to name the hosting regions, the sub-processors involved and whether backups leave that region. Confirm these terms in the contract, since they determine residency for regulated ticket content.
Data location under self-hosted Znuny
With Znuny, the database, article storage and attachments sit in the cloud account or data center you choose, under your network controls. Your team or DeployOpen can confirm that the Linux hosts, the supported database and any file storage stay in approved locations. Document the locations in your data inventory so auditors can trace where each ticket record lives.
Identity and SSO integration
Agent and administrator sign-in decides who can open, read and close sensitive tickets. Confirm with each OTRS offering whether it supports your identity provider, through which protocol, and whether that integration is included or an add-on. For Znuny, identify the authentication modules and any add-on needed, and test that deprovisioned staff lose access immediately.
Audit and compliance evidence
Under either path, DeployOpen can prepare configuration records, access reviews, change logs and runbooks for an assessment. DeployOpen does not issue audit reports or certifications, and independent auditors or certification bodies make that determination. Ask OTRS which logs and attestation documents it provides for a managed service, and which evidence your team must produce itself for Znuny.
Backup and retention responsibility
With managed hosting, ask the vendor to state backup frequency, restore testing, retention periods and how a ticket is deleted from backups. With self-hosted Znuny, your team owns those controls, including encrypted off-site copies and restore drills. Write down who approves retention changes and who performs a restore so that deletion requests can be honored across all copies.
Vendor staff access to ticket content
Under managed hosting, vendor operators may have administrative access to servers, databases and support tooling, which can expose ticket content. Ask who can access your environment, how that access is logged, whether it requires your approval and how emergency access is reviewed. In a self-hosted Znuny deployment, access is limited to accounts you grant, and you control the audit trail.
What moving from OTRS to Znuny involves
The sequence turns an aging OTRS installation into a tested Znuny system with a known upgrade path, a validated database and a documented cutover. Each phase produces evidence that the next phase can rely on.
Inventory the current OTRS version and add-ons
Record the exact OTRS version, the database engine and version, the Perl and web server stack, every installed add-on package, and any custom modules, templates, scripts and cron jobs. Note which edition you run, since commercial OTRS and Community Edition 6 installations differ in what they include. The team lead and the OTRS administrator own this step. It is done when every component has a version, an owner and a decision to keep, replace or retire it.
Build a test copy of database and files
Take a full database dump and a copy of the application directory, including attachments and configuration, and restore them on an isolated test server that matches production as closely as possible. Keep production read-only during the copy, or agree a known freeze window with users. The platform engineer owns the copy. It is done when the test instance starts, a sample of tickets and attachments opens correctly, and the restore procedure has been written down.
Plan the stepwise upgrade path into Znuny
Map the route from your current OTRS version to the Znuny release line you intend to run, then confirm each intermediate step against the Znuny documentation for that release. Znuny 6.5 accepts updates only from 6.4, so older installations may need intermediate versions before the final move. Do not assume a direct jump. The upgrade lead and the vendor-facing contact own this plan. It is done when each hop is listed with its prerequisites, its rollback point and the documentation page that confirms it.
Assess custom code and add-on compatibility
Check each add-on and custom module against the target Znuny release. Where a package has no Znuny-compatible version, decide whether to rebuild it, replace it with a supported alternative or drop the feature. Custom code that touches core Perl modules needs the most review, because it may break on upgrade. A developer who knows the Perl codebase owns this work. It is done when every item has a compatibility status and a rebuild or retirement decision signed off by the business owner.
Choose and validate the database platform
Select a supported database engine from the Znuny prerequisites, such as MySQL, MariaDB, PostgreSQL or Oracle, using the minimum versions listed in the Znuny README. Confirm that your existing data migrates cleanly to the chosen engine, including character sets and collations. Benchmark the restore time and query behavior on the test copy. The database administrator owns this step. It is done when the chosen engine passes a full test upgrade and the performance on representative ticket volumes is recorded.
Run parallel testing with real workflows
Ask agents and administrators to run their normal work on the test instance: creating and closing tickets, escalations, email ingestion, notifications, reporting, approvals and any integrations with monitoring or directory services. Log each failed or changed behavior as a defect with a severity. Repeat the upgrade from the documented starting point until a clean run is possible. The service owner signs off. It is done when the defect list is closed or formally accepted and the upgrade has run end to end without manual repair.
Execute cutover with a rollback plan
Schedule the production freeze, take a final backup, apply the confirmed upgrade sequence, then verify ticket access, email routing, scheduled jobs and integrations before reopening to users. Keep the original system and backup available until the new instance has run long enough to show stability. The change manager and the platform team own the cutover. It is done when production passes the agreed smoke tests and the rollback procedure has been rehearsed on the test copy.
Establish post-move operations and support
Set up backups, monitoring, patch and release tracking, and documentation for the new environment. Decide who handles Perl and add-on maintenance, and whether to buy support from Znuny GmbH or rely on internal staff. Confirm the cadence for applying future Znuny releases and the documentation you will check before each one. The operations lead owns this work. It is done when backups have been restored successfully at least once, and the runbook names an owner for each recurring task.
Questions buyers ask before comparing OTRS and Znuny
How much does moving from OTRS to Znuny cost?
The cost depends on components, not a single number. Znuny itself is GPL v3 software with no license fee, so the spend falls on Linux servers, a supported database, the people who operate the system, migration and testing effort, and any services you buy from Znuny GmbH. The commercial side has its own components: OTRS licensed users, the base package, add-ons, or managed hosting, each quoted by OTRS. Ask OTRS for a written quote that lists licenses, hosting, add-ons and support separately, and ask Znuny GmbH for a scoped services quote so the two can be compared line by line. Most of the one-time cost is migration and testing, while servers, database and staff time recur.
How long does an OTRS to Znuny migration take?
Duration is set by how far your installation sits from the current Znuny release, how much custom code and add-on packages you run, the size of the database, and how much testing you require. Znuny documentation describes a stepwise update path, and Znuny 6.5 accepts updates only from 6.4 rather than directly from any OTRS version, so older installations usually need intermediate steps. Plan for a full test on a copy of production before any cutover. Ask Znuny GmbH or your implementation partner to estimate duration from an inventory of your version, add-ons and custom modules, and confirm it against a test run.
What does the migration need from our own staff?
Your staff must supply knowledge of how the help desk is configured and used, and they must take part in acceptance testing. Expect input from the ticketing administrator, the owners of queues, workflows and ITSM processes, anyone who maintains custom code or add-ons, and the database and Linux administrators who will run the new stack. Each of these roles adds time, so name them in the project plan before work starts. Confirm with Znuny GmbH which artifacts they expect from you, such as an inventory of installed packages and a current backup.
Can our internal team migrate to Znuny without a partner?
Yes, an internal team can perform the migration if it has Linux, Perl web application, database and OTRS administration skills and time for testing. Znuny publishes separate documentation for its current feature version and its LTS version, plus agent, developer and Perl API documentation, which helps teams that work in-house. The risks are the stepwise upgrade path, unsupported or outdated add-ons, custom code that relies on internal APIs, and the absence of an independent test before production. Many teams split the work: they run the stack and keep control of data, while a partner handles upgrade planning, testing or hardening under a written scope.
Does Znuny GmbH offer a support contract for Znuny?
Znuny GmbH, based in Berlin, provides professional services for Znuny, according to znuny.org. The services are contracted separately from the software, which is free under GPL v3. Before you buy, confirm with Znuny GmbH the exact service levels, response times, covered versions, whether support extends to add-ons and custom code, and whether it includes upgrades and security patch handling. Ask for these terms in writing. Also confirm whether your own staff or a partner will be the first line of support for day-to-day issues.
Which Znuny release line should we choose?
Choose between the current feature line and the LTS line based on how often you want to upgrade and how much change you can absorb. According to znuny.org, the latest releases in October 2026 were Znuny 7.3.8 and Znuny LTS 6.5.26. The LTS line is intended for organizations that prefer longer-lived, more conservative updates, while the feature line receives newer functionality. Confirm with Znuny GmbH how long each line receives fixes, the upgrade path between them, and which Perl and database versions each requires. Check the prerequisites for your chosen release against your Linux distribution before you pick a target.
How does migrating to Znuny compare with migrating to Zammad?
Znuny keeps your OTRS data model, workflows and ITSM configuration, so the move is an upgrade of an existing system. Zammad is a different product under AGPL-3.0, so moving to it is a replacement project that needs a data import and new process design. Zammad's built-in migrator supports OTRS as a source, but migrations are all or nothing, run only on a new instance and accept one source system per migration. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, while Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Compare the two on process fit, staff retraining and the cost of rebuilding your configuration, not on license fees alone.
Who runs the system after go-live under each model
Under managed hosting, the vendor or its hosting partner operates the servers, database and application stack, and your team mainly administers ticketing configuration, queues, users and roles. The contract defines what the provider covers, so the exact boundaries depend on the written scope rather than on the product name. Ask for the terms in writing before go-live.
- Patching: Confirm who applies operating system and application security fixes, how quickly, and whether you can request a change window.
- Backups: Ask how often backups run, where they are stored, how long they are kept, and how you would restore a single ticket or attachment.
- Availability: Confirm the provider's stated availability commitment, its monitoring, and how incidents are reported to you.
- Upgrades and add-ons: Find out whether major upgrades are included, who tests add-on packages and custom code against each release, and who pays for that testing.
- Skills: Your team needs strong process and configuration knowledge of the ITSM application, but not server administration.
Check whether the hosted environment gives you a full database export and an exit path if you later move to another model.
With OTRS installed on your own servers, your team or a contractor owns the full stack: operating system, web server, database, application, backups and monitoring. The vendor's licence and support agreement covers the software and its fixes, but the operational work stays with you. Confirm the support scope for your edition before you plan staffing.
- Patching: Your team applies operating system patches and application updates on a schedule you set, and tests them before production.
- Backups: You design and test database and file backups, including restore drills for tickets and attachments.
- Availability: You provide redundancy, failover and capacity planning for the web tier and database.
- Upgrades and add-ons: You plan each major upgrade, check licensed add-ons and custom code against the new release, and keep a staging copy for testing.
- Skills: You need Linux administration, Perl web application operations, database administration and experience with ticketing configuration.
Ask the vendor which support tiers and upgrade paths your licence includes, and whether any hosting or installation services are quoted separately.
Running Znuny in-house means your staff own the same stack as an on-premise OTRS deployment, but the software is the community continuation of the OTRS Community Edition with no licence fee. Your team takes on all operational responsibility and must also track the Znuny release lines and decide which one to follow. There is no vendor contract to fall back on unless you buy support separately.
- Patching: Your team monitors Znuny releases on the project's release page and applies updates to the operating system, Perl runtime and database.
- Backups: You build and test the backup routine, covering the database, the article storage and any attachments.
- Availability: You design the web and database tiers, monitoring and failover to meet your own service targets.
- Upgrades and add-ons: You follow the documented upgrade path between Znuny versions, and test add-on packages and custom Perl code on a copy before each change.
- Skills: You need Linux, Apache with mod_perl, database administration for a supported engine, and Perl skills for customization and troubleshooting.
Check that your team has named owners for each of these duties, and that the documentation for the current feature version and the LTS version is part of the runbook.
In this model your team keeps Znuny in your own infrastructure, but an outside party carries part of the operational load under a written scope. Znuny GmbH in Berlin offers professional services for Znuny, and DeployOpen implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your environment. The split of duties is set by the agreed scope, and you decide which parts stay internal.
- Patching and upgrades: The partner can plan and execute stepwise updates, test add-ons and custom code, and document each change under a retainer or fixed-scope agreement.
- Backups and recovery: The partner can design, automate and test backups and restores, and report on them, while you keep ownership of the data and the retention decisions.
- Availability: Monitoring, incident response and capacity work can be assigned to the partner, with response expectations written into the contract.
- Add-ons and customization: The partner can review compatibility of add-on packages and custom Perl code before each upgrade, which reduces surprises for your application owners.
- Skills: Your team still needs ITSM process ownership and enough platform knowledge to approve changes and read the reports.
Ask each provider which duties are included in the quote, how support is delivered, and what happens to documentation and access at the end of the engagement.
How DeployOpen helps you evaluate, implement or migrate Znuny
DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For OTRS vs Znuny, we start from your current OTRS deployment, your process and integration needs, and your database and hosting constraints, then agree a fixed scope before any work begins.
How we scope
- We inventory your current OTRS version, add-on packages, custom code and integrations before recommending a path.
- The written scope states which Znuny release line, database and hosting model we will target for your environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- We stand up Znuny on Linux in your own infrastructure, configured for your queues, roles, ITSM processes and notifications.
- We rebuild or port custom code and add-ons against the Znuny codebase and test them on a copy of your production data first.
- We run the stepwise update path and check each intermediate release, so upgrades follow the sequence Znuny documents.
How we hand over
- You receive documentation of the installation, configuration, customizations, backup and restore steps and upgrade runbook.
- Test results, cutover checklists and rollback plans are delivered with the system so your team can verify each stage.
- Knowledge transfer sessions cover day-to-day administration, so your staff can operate Znuny without depending on us.
How we support
- Ongoing support, upgrades and backups can be contracted as a retainer after go-live, scoped in writing.
- We can coordinate with Znuny GmbH for professional services where your scope needs vendor-level expertise, and confirm terms with them directly.
- Security testing of the deployed Znuny instance can be scoped separately, so findings are fixed and retested before sign-off.
