What does OTRS cost compared with self-hosted Znuny?
Znuny carries no license fee, while OTRS is priced by quote per licensed user and package, so the cost gap depends on infrastructure, migration effort and staffing rather than on a list price. If a renewal, quote or hosting change is forcing this review, start by getting the OTRS quote in writing and breaking it into its parts: licensed users, the base package, each add-on, and any managed hosting fee. No OTRS or Znuny price figures are supplied here, so you will need to price the Znuny side yourself using your own server, database and staff estimates.
On the Znuny side, list the recurring and one-time components separately. Linux servers, the database (MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, or Oracle 19c or later), backups, monitoring and test environments all recur or carry setup cost. Migration work, including the stepwise update path and testing on a copy, is largely one-time. The main drivers are the number of agents, how many add-on packages and custom modules you run, and whether your team already operates Perl-based applications. Ask each internal team to estimate its own hours, because those hours are usually the largest line.
Optional professional services from Znuny GmbH in Berlin are priced by their own quote and are not required to run Znuny. Decide early whether your staff will carry upgrades, security patching and second-line support, or whether you want an external support contract for specific cases. Ask for a written scope with each option so you can compare a support contract directly with the OTRS subscription it would replace, and confirm with Znuny GmbH what their quote covers before you compare totals.
Cost components on the OTRS side and the Znuny side
This table sets each cost component of commercial OTRS against its counterpart in a self-hosted Znuny deployment, and marks whether it is paid once or recurs. Read it as a checklist for a quote request: the commercial column names what to ask the vendor for in writing, and the self-hosted column names what your own team or a partner will carry. No figures are given here, so every number should come from a written quote or your own sizing.
| Cost component | OTRS (commercial) | Self-hosted Znuny | One-time or recurring |
|---|---|---|---|
| Licensed users | Agent licenses priced by the vendor quote, usually scaled to the number of named agents | No license fee under GPL v3, so user count drives hardware and support load, not a license charge | Recurring on the OTRS side; none on the Znuny side |
| Base package | Core product fee set by the vendor quote for the edition and deployment model chosen | Code is free to download and use; cost moves to installation, configuration and testing | One-time or recurring on OTRS; one-time effort on Znuny |
| Add-ons | Extra modules and packages priced separately in the quote, so confirm each one you need | Add-on packages must be checked for compatibility with the Znuny release line before you rely on them | Recurring on OTRS; one-time review and possible rework on Znuny |
| Managed hosting or on-premise support | Managed hosting fees or on-premise support terms, both by quote, so ask what the SLA and patching duties cover | Your team or a partner runs the servers, patching and monitoring, so the cost is staff time and infrastructure | Recurring on both sides |
| Linux servers | Included in managed hosting; on-premise deployments need your own servers under the vendor's sizing guidance | Application and database servers on Linux, preferably Debian or Red Hat, sized by your user and ticket volume | Recurring infrastructure cost on Znuny; confirm the managed or on-premise split on OTRS |
| Database | Database choice and licensing defined in the vendor quote, so confirm which engines are covered | Supported engines include MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later; licensing depends on the engine you choose | One-time setup; recurring for hosting, and for Oracle licensing if you select it |
| Backups and monitoring | Often bundled in managed hosting; confirm backup scope, retention and restore testing in writing | Your team builds backup jobs, restore tests and monitoring, and keeps them current | One-time build; recurring operation and storage |
| Znuny GmbH services | Not applicable; support comes from the OTRS vendor under its own terms | Optional professional services from Znuny GmbH in Berlin, scoped and priced per engagement | One-time for projects; recurring if you buy a support retainer |
| Migration | Upgrading or moving to a current OTRS release is priced through the vendor or a partner quote | Stepwise update path, custom code review, add-on checks and testing on a copy, all carried by your team or a partner | One-time project cost on both sides |
| Internal staff time | Administrators still manage users, workflows and integrations, though patching may sit with the vendor | Administrators own patching, upgrades, database maintenance and incident response for the full stack | Recurring on Znuny; scale with how much you hand to a partner |
| Upgrades | New OTRS releases and upgrades follow the vendor's terms and quoted fees | Upgrades follow Znuny's release lines, with the stepwise path between versions and testing before each change | Recurring effort on both sides; planned and tested upgrades keep it down |
What moves the OTRS and Znuny comparison
Most of the difference between OTRS and Znuny cost comes from a few drivers that scale differently on each side. Agent count, data history, edition choice, recovery targets, custom code and team skills decide whether a self-hosted Znuny stack stays cheap or quietly picks up people costs. Work through them in this order before asking for any quote.
Number of agents and licensed users
OTRS licensing is quoted by the vendor per licensed user, so every added agent or customer-facing role can raise the commercial line directly. Znuny has no license fee, so agent growth on that side moves only server capacity, database load and support time. Ask OTRS for the user count definition in writing, including whether read-only or occasional users are counted, and model Znuny against your peak concurrent agents rather than your headcount.
Data volume and attachment history
Years of tickets and attachments drive database size, backup duration and storage on both sides. On a self-hosted stack, that history lands on disks, snapshots and backup targets you pay for every month. Ask whether the vendor quote includes hosted storage limits or overage charges, and estimate Znuny storage from your actual attachment volume, with a plan for archiving closed tickets that you rarely need to search.
Edition and add-on count
A commercial OTRS quote often grows with each module, add-on or support tier attached to the base package, and the total is only visible once every line is listed. Znuny's base is GPL v3, but add-on packages need separate checks for source, maintenance and compatibility with the release line you choose. List every module you use today and every one you expect to need, and confirm which of them exist as maintained packages for Znuny.
Availability and recovery targets
Higher uptime and faster restore goals raise costs on the self-hosted side through redundant database nodes, load balancing, monitored failover and tested restores. Managed OTRS hosting may include parts of this in its quote, so the comparison depends on what is actually included. Write down your recovery time and recovery point targets first, then price the Znuny redundancy and testing that meet them, and confirm which of these the vendor quote covers.
Custom code and integrations
Custom Perl modules, forms and integrations with directory, monitoring or billing systems create the largest long-term maintenance load on Znuny, because each change must be re-tested after every upgrade. On OTRS, custom work also needs review against vendor changes before it can move forward. Inventory custom code and integrations early, since each item adds recurring developer time that the license comparison will not show.
Skills already in the team
A team that already runs Linux, Perl-based applications, PostgreSQL or MySQL can operate Znuny with modest added effort, while a team without those skills will pay for training, external support or Znuny GmbH services. Commercial OTRS shifts more operational work to the vendor, so the people question is about which tasks you want to keep in-house. Ask who will patch, back up, upgrade and troubleshoot the stack, and price those named roles against the license line.
How OTRS is bought: licensed users, add-ons or managed hosting
Under an on-premise arrangement, your organization licenses the OTRS software and runs it on servers it controls or hosts with a third party. The license is typically priced around the number of users who work in the system, so user counts are the main driver of the quote. Ask the vendor to itemize the base package, the licensed user tiers, any add-on modules and the support level, because each line can renew on its own schedule.
- Base package: the core ITSM license, listed separately from modules and support.
- Licensed users: the agent count, how it is defined, and whether named or concurrent users apply.
- Annual support or maintenance: the recurring fee, its start date and what it includes.
- Add-ons: each module or integration with its own renewal line.
- Upgrade rights: whether new major versions are included in the subscription.
Ask how user counts are reconciled at renewal, whether you can reduce seats mid-term, and whether upgrade rights lapse if support stops. Also confirm the infrastructure, database administration and patching you still pay for internally.
Under managed hosting, the vendor or its partner runs the OTRS environment for you and charges a recurring fee for hosting, operations and application support. The price usually combines a platform fee with the user or environment tier. This moves infrastructure work out of your team, but it also means your data lives in a provider's environment and your exit depends on the contract terms.
- Hosting fee: the recurring charge for compute, storage and backups, with the region named.
- Environments: how many production, test and staging instances are included.
- Backup and restore: frequency, retention and whether restore tests are included.
- Service levels: the availability and response commitments written into the contract.
- Data export: the format and cost of a full export at exit.
Ask for the notice period for price changes, the process for moving to a different version, and where backups are stored. Confirm which of these terms are fixed for the full term and which can change at renewal.
Add-ons are priced separately from the core product and can appear on either the on-premise or the managed hosting quote. They often include extra modules, integrations, additional languages or premium support. Because each add-on has its own recurring fee, the total annual figure can differ a lot from the headline base price, so review the complete quote before comparing it with other options.
- Module list: each add-on named with its function and its annual cost.
- Integrations: connectors to directory, monitoring or other systems, and who maintains them after upgrades.
- Dependency on upgrades: whether an add-on still works after a core version change, and at what cost.
- Custom development: any bespoke work, its billing basis and who owns the code.
- Bundled discounts: whether bundles change the renewal basis.
Ask which add-ons are required for your current workflows and which can be dropped at renewal. Confirm whether custom code remains yours to maintain after the contract ends.
The OTRS Community Edition reached end of life in December 2020, so it has no current pricing and no current vendor support. Any cost you see for it is historical, and it should not be used as a baseline for a new budget. Teams still running it face a decision about upgrading to current commercial OTRS, moving to the Znuny continuation or replacing the system.
- No current price: the Community Edition is not sold, so there is no quote to request.
- No vendor fixes: security patches for the Community Edition are not published by the vendor.
- Historical costs: past license or hosting invoices do not predict the cost of a supported path.
- Path comparison: the cost of each route should be quoted against the same user count and scope.
- Data and config: an inventory of custom code and add-ons affects every option.
Before requesting quotes, confirm the exact OTRS product and version you run, and ask each vendor and implementation partner to price the same scope in writing.
What a Znuny deployment needs to run
The cost of a self-hosted Znuny deployment starts with the stack it runs on, and the first decision is the platform. Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher, and Apache 2 with mod_perl2 is the recommended web layer. The operating system carries no license fee in most cases, but the server, its patching and its monitoring are costs the buyer carries in staff time and infrastructure. Confirm the distribution family your team already supports before pricing hardware, because the choice shapes the packages, the Perl build and the upgrade path your administrators will follow.
The database is the second decision and the one most likely to change the total. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. The open-source engines carry no license fee, so the cost sits in the database servers, storage, replication and backup design you build around them. Oracle is the exception with a commercial license that must be quoted separately. Check the database version list in the Znuny README against your planned versions before you buy hardware, because a database version outside that list would force a rebuild or a platform change later.
High availability and backup are where recurring cost usually hides. A production help desk needs a tested backup of the database and the article storage, a restore procedure that someone has actually run, and a standby or failover design if the service must stay up during maintenance. Each of these adds servers, replication licenses if you choose a commercial database option, and monitoring. Ask any Znuny GmbH services quote to state which of these components it covers, and ask your own team to document who owns each one.
How to build the OTRS and Znuny cost model with your own numbers
This sequence turns a vague sense that OTRS costs too much into a side-by-side model of your current spend and a self-hosted Znuny run, built from your own invoices, user counts and staffing.
Collect the current OTRS invoice and renewal quote
Finance or procurement gathers the last full year of OTRS invoices and the written renewal quote, including any managed hosting fees, support terms and the notice period in the contract. Separate one-time charges, such as onboarding or upgrade services, from recurring charges, such as license or hosting renewals. Ask the vendor to confirm in writing what each line covers and what changes if the user count rises. The step is done when every recurring line has a source document and an owner.
Count active agents and customer users
The service desk lead exports the current list of agent and customer accounts from OTRS and marks which ones logged in during the last 90 days. Compare that list with the licensed count on the quote, because licensing models often count differently from actual use. Record growth expectations for the business case period, such as planned hires or new customer groups. The step is done when you have one agreed number for agents, one for customers, and a note on how the vendor counts each.
List add-ons, packages and custom code
The OTRS administrator lists every installed add-on package, every paid module and every custom Perl or configuration change that a developer maintains. For each item, record whether it is still needed, whether a Znuny or community equivalent exists, and who would rebuild or retest it. Custom code is often the largest hidden cost in a migration, so count the developer days it currently takes to keep it working. The step is done when each add-on and custom change has a keep, replace or retire decision.
Price servers and database in your own environment
The infrastructure team prices the Linux application servers, web tier, database service and backup storage that Znuny would run on, using your data center or cloud provider's current rates. Check the Znuny README for supported database versions, including MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, and price only the option your team will operate. Include non-production copies for testing, monitoring and off-site backups. The step is done when every server, database and storage line has a price from your own environment and a note on whether it recurs.
Request Znuny GmbH service quotes if needed
If your team lacks Perl, Znuny or ITSM operations experience, request written quotes from Znuny GmbH in Berlin for the services you want, such as migration help, support or upgrade assistance. Ask each quote to state the scope, deliverables, what is one-time and what is recurring, and what is excluded. Compare these quotes with the internal effort you would otherwise spend, rather than assuming either option is cheaper. The step is done when you have written quotes for each service you may buy, or a documented decision to operate without external services.
Add staff time for upgrades and monitoring
The platform owner estimates the recurring hours for applying Znuny releases, testing add-ons, monitoring the servers and reviewing backups, along with the on-call coverage your service levels require. Use your own team's hourly cost, and identify whether the work falls to existing staff or requires a new hire. Note that Znuny 6.5 accepts updates only from 6.4, so the upgrade path can add effort if you start from an older release. The step is done when each recurring staff activity has an owner, a yearly hour estimate and a loaded cost.
Compare one-time and recurring totals over the period
Place both models side by side over the period your business case covers, showing one-time migration, testing and setup costs separately from recurring license, hosting, support and staff costs. Include the OTRS costs that continue during the parallel run, and state every assumption, such as user growth or hosting price changes. Test the result by changing the largest assumption and checking whether the conclusion holds. The step is done when the finance and IT leads have signed off the same totals and the open questions are listed with owners.
What the migration adds to the first-year cost
The migration is a one-time cost, and its size depends on the installation rather than on the license. Znuny itself carries no license fee, so the first-year figure must include the work to move an existing OTRS installation onto it. That work covers the stepwise update path, add-on packages, custom code, the database and testing. No migration duration or fee is supplied for this comparison, so ask Znuny GmbH or a services partner for a written plan that lists each phase, its deliverables and who performs it, then estimate your own effort from the number of tickets, agents, add-ons and custom modules you run.
The update path is the first item to confirm. Check the upgrade notes in the Znuny documentation at doc.znuny.org for the exact sequence from your current OTRS version to the Znuny line you intend to run, and budget a test cycle for each stop on that path. Next, inventory every add-on package and custom module. Each one needs a compatibility decision: confirm it works on the target Znuny release, find a maintained replacement, or retire it. Custom code and Perl modules that call internal APIs typically take the longest to review, because each change in the API surface can break a workflow that agents rely on every day. The database choice also affects cost. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, so decide early whether you keep your current engine or move, because a database change adds a data conversion step. Finally, test the full upgrade on a copy of production before any cutover, and time the run so you know the real outage window. Ask for test evidence, rollback steps and a sign-off list as part of the written plan, because those items determine whether the first-year number holds.
How much does OTRS cost compared with Znuny, and what work does it need?
Does Znuny have a license fee?
No. Znuny is distributed under the GNU GPL v3, so the software itself carries no license fee. The costs that remain are the Linux servers, the operating system, a supported database, backups, monitoring, storage, and the staff or partner time needed to run them. In your comparison, move the OTRS license line into the Znuny column as zero, then add the infrastructure and labor lines. Check separately whether any add-on packages you rely on carry their own terms, because those terms are set by each package owner and should be confirmed in writing before you compare totals.
What should an OTRS quote include before you compare it?
A usable quote states the licensed user count and whether users are named or concurrent, the base package, each add-on by name, the support tier, and whether hosting is managed or on-premise. It should also show the term length, the renewal uplift, any onboarding or migration work, and the terms for exporting your data if you leave. Ask what changes at renewal and whether add-ons are priced per module or per user. Without these lines, you cannot place OTRS costs next to a self-hosted Znuny estimate in a fair way.
Can our own team run Znuny without outside help?
It depends on the skills you already have. Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended. It supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. A team with Linux, web server and database administration experience can operate it, but customization, add-on upgrades and migration testing usually need Perl and ITSM knowledge. Check the requirements against your environment in a test build, and list the gaps before deciding between an internal team and an external partner for the work.
How long does an OTRS to Znuny migration take, and what drives it?
No duration is fixed in the supplied facts, so ask any implementer for a duration in writing, based on your scope. The main drivers are the installed OTRS version and how far it sits from the Znuny update path, the number and complexity of add-on packages, custom code, the database you choose, the size of your ticket history, and the number of integrations with directory, mail and monitoring systems. Testing on a copy of production data adds time but reduces cutover risk. Ask the implementer to show the stepwise update plan and the test evidence they will provide.
What do Znuny GmbH services cover, and what do they cost?
Znuny GmbH, based in Berlin, offers professional services for Znuny, according to the project's release page. The supplied facts do not list its service catalog, support levels or rates, so request the service description and price basis from Znuny GmbH directly. Typical scopes to ask about are installation, upgrades, add-on support, custom development and training. Separately, DeployOpen can plan, implement, customize, harden, back up, upgrade and document Znuny inside your own infrastructure, under a fixed scope agreed in writing before work starts, with ongoing support available as a retainer. Compare both written scopes against the same requirements list.
What skills does a Znuny operations team need?
Plan for four skill areas. Linux administration covers patching, users, file permissions and service management. Web server work covers Apache 2 with mod_perl2, which Znuny recommends. Database administration covers backup, restore, performance tuning and version upgrades for your chosen engine. Application knowledge covers Perl for custom code, the agent and admin interfaces, and mail channel configuration. Developers can use the Perl API documentation published on the Znuny documentation portal, and the agent documentation covers day-to-day use. Name an owner for each area so that one absence does not stop patching or backups.
What recurs each year after a Znuny migration?
Most recurring cost is people and infrastructure. Expect annual hosting or data center charges, storage and off-site backup capacity, monitoring tools, and database and operating system maintenance. Plan for regular Znuny updates: the project currently publishes a feature line and an LTS line, so choose which one you follow and budget the test cycles for each release. Add add-on updates, security patch testing, and any support contract or retainer you buy. Recurring labor should cover patch windows, restore tests and user administration. One-time costs are migration, customization, hardening and initial training.
How DeployOpen scopes a fixed-price Znuny implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For OTRS cost vs self-hosted Znuny, we start with a written scope that separates license savings from the infrastructure, migration and staffing costs you will carry yourself.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists your current OTRS license, add-ons, hosting arrangement and user counts as inputs
- Scope defines which Znuny services, database and Linux servers are in and which are your responsibility
- Ask for the scope to state who pays for each component, one-time and recurring, so comparisons stay like for like
How we build
- We size the Znuny servers, database and backup targets against the user and ticket volumes in your scope
- Installation, add-on and custom code review are performed in your cloud account, data center or air-gapped network
- We test the migration and the cost model on a copy of your environment before any production cutover
- Hardening, backups and monitoring are configured as part of the build and documented for your own teams
How we hand over
- Handover includes architecture notes, runbooks and configuration documentation written for your operators
- We document the update path and the test steps your team needs for each future Znuny release
- Your staff receive a walkthrough of backup, restore and access controls before the engagement closes
- The handover package lists the recurring costs you will own, such as servers, storage, staff time and any Znuny GmbH services
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- A retainer can cover Znuny version upgrades, patch review and backup verification on a schedule agreed in writing
- Ask whether support scope includes add-on compatibility checks and restore tests before you sign
- DeployOpen prepares controls and evidence for compliance assessments, while independent auditors issue any audit reports
