Which service desk fits your situation
Most readers reach this decision from one of three starting points: a Jira Service Management renewal coming up, the Atlassian Data Center end-of-sale timeline, or a requirement to keep ticket data on servers you control. Start by writing down which of these drives the decision, because it sets the deadline and the bar for what a replacement must prove. Jira Service Management fits teams that want a vendor-run cloud product with integrated Atlassian tooling and no platform to patch. Znuny fits teams that want an open-source ticketing and ITSM platform on their own Linux, Perl and database stack and accept the operating work that comes with it.
The decision turns on four questions. First, how strict are your data control requirements, and does that rule out any vendor-hosted tenant? Second, how much ITSM process depth do you need: incident and problem handling, a CMDB, service level reporting and change management with advisory board roles. Znuny delivers these as add-on packages that you select and install, so confirm which ones your processes need before you commit. Third, does your team have in-house Perl and Linux skills to run, upgrade and troubleshoot the application, or will you need an outside partner for that work.
The fourth question is whether one platform must serve both IT and customer service. Znuny describes itself as a ticketing system for customer service, help desk and IT service management, so a single installation can cover both, but you should test that the queue, permission and reporting model fits each team before migrating. Write these four answers down, then compare them against the Znuny and Jira Service Management sections below. If any answer points to a capability you cannot confirm, put that item on the vendor or partner question list first.
Which option fits each scenario
This table maps common buyer situations to the platform that usually fits better, and names the condition under which each side wins. Read each row against your own constraints, since the right answer often depends on a single requirement such as in-house data, a customer desk, or a CMDB import.
| Scenario | Better fit | Why |
|---|---|---|
| Customer service desk and IT desk on one platform | Znuny | Znuny is described as a ticketing system for customer service, help desk and ITSM, so one install can serve both teams if you add the ITSM packages. |
| Data must stay in-house on your own database | Znuny | Znuny runs on your Linux servers with MySQL, MariaDB, PostgreSQL or Oracle, so ticket data stays in your database rather than Atlassian Cloud or Data Center. |
| Existing Atlassian stack and Jira workflows | Jira Service Management | Staying on JSM keeps integration with Jira, Confluence and existing automation intact, though Data Center end-of-sale dates should be weighed in the decision. |
| Team with Perl and Linux skills | Znuny | Znuny is written in Perl and runs on Apache with mod_perl2, so in-house staff with those skills can maintain, customize and debug it directly. |
| Team without Perl experience and no Linux operations staff | Jira Service Management | Operating Znuny means owning the web server, Perl runtime, database and upgrades, so a team without that skill set should confirm support capacity first. |
| Need for a standard release line with frequent feature changes | Znuny | Znuny publishes a feature release line and a separate LTS line, so you can choose the cadence that matches your change control process. |
| Need for a long-term support line with fewer feature changes | Znuny | The LTS release line suits organizations that prioritize stability and a slower upgrade cycle, and you should confirm its support window with Znuny. |
| CMDB with CSV import of configuration items | Znuny | Znuny's ITSM packages include a CMDB of configuration items, classes and relationships, plus CSV import and export of configuration items. |
| Change management with formal approval workflows | Jira Service Management | Znuny's documentation recommends modeling most change processes instead of installing its change management package, so teams needing built-in change workflows should compare the two closely. |
How Znuny's ITSM packages change the install
The key difference from Jira Service Management is that Znuny ships ticketing in the base system and delivers its ITSM features as add-on packages. General Catalog and ITSM Core must be installed first, and the remaining features come either as a bundle or as individual packages, which the Znuny ITSM features documentation recommends. For a team that wants to choose its process depth, this is useful: you can install incident and problem management, the CMDB of configuration items with their classes and relationships, and service level reporting without taking on everything else. Plan the install as a sequence of decisions rather than a single switch.
The same modularity adds planning work. Each package you add has to be tested against your ticket templates, permissions, roles and reporting, and the packages interact through shared data such as services, priorities and configuration items. Before you install anything, list the ITSM processes your organization actually runs, map each one to a package, and confirm the dependencies with the documentation for your target release line. Ask whether a bundle or individual packages fits your change volume, and who will own upgrades across the packages.
Pay particular attention to change management. The Znuny documentation says that in most cases it recommends modeling changes as a process instead of installing the change management feature, which it describes as sensible only under special circumstances. Before committing, walk a recent change through your current approval steps, change advisory board roles and work orders, then test whether a process built on standard ticket states and queues covers them. If it does, skip the change package and keep the install smaller. If your audit trail or approval rules need the packaged change management, plan for that package and its configuration from the start.
Where your ticket data lives and who runs it
Moving from Jira Service Management to Znuny changes where ticket data sits and who operates the stack. The cards below cover the Atlassian timeline, the Znuny runtime and database requirements, and the responsibilities that stay with your organization after go-live.
Where the data sits today
Jira Service Management Cloud keeps tickets in Atlassian-managed infrastructure, while Data Center runs on servers you operate. A self-hosted Znuny instance keeps tickets, attachments and agent accounts in the database and file storage you choose, inside your own network or your chosen provider. Before you plan, map every location that holds ticket content, including mail relays, attachment storage and backups, and confirm with Atlassian and your own environment where each copy lives today.
Data Center end-of-life timeline
Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026. Existing customers can buy licenses or expansions until March 30, 2028. On March 28, 2029, Data Center licenses expire and become read-only, so a planned exit should be scheduled well before that date. Ask Atlassian for the current terms for your contract, since renewal and expansion rules may differ.
Supported database engines
Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Your database choice determines backup tooling, replication design and the DBA skills you need in-house. Confirm which engine your operations team already runs and supports, and check that version against the minimum levels listed in the Znuny README before you size hardware.
Linux, Perl and Apache runtime
Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher. Apache 2 with mod_perl2 is recommended for the web tier. Because the application is Perl, your team must maintain the runtime, patch the operating system and manage module dependencies. Ask whether your platform team has Perl and mod_perl operating experience, and confirm the supported distribution versions in the Znuny release notes.
Identity and access controls
With Znuny, sign-in, role assignment, agent provisioning and access logging run where you host them. Jira Service Management uses Atlassian Access and your identity provider integrations, which you would need to rebuild or connect to your own directory. Document who approves agent accounts, how leavers are removed, and which admin roles can change queues or permissions, then confirm the integration options in the Znuny documentation for your identity provider.
Compliance evidence and audit scope
Moving hosting does not transfer compliance obligations. Your organization remains responsible for backups, patching, access reviews, logging and incident records, and for showing auditors how those controls work. Confirm which frameworks, data classes and regions your audit covers, and whether your auditor needs evidence from the Atlassian contract, the Znuny deployment or both. DeployOpen can prepare systems and evidence, but independent auditors issue any report or certification.
Choosing between the Znuny standard and LTS lines
The feature line is the newest Znuny version, and znuny.org listed Znuny 7.3.8 as its latest release in October 2026. Teams that want the most recent ITSM and ticketing improvements, and can absorb more frequent upgrades, usually start here. Read the feature version documentation on doc.znuny.org alongside your change plan, since it describes the behavior of the release you will actually run.
- Newer features: The feature line carries the latest changes to agent interface, ITSM packages and administration.
- Upgrade cadence: Plan for more frequent upgrade cycles, with testing of your custom Perl code and add-on packages each time.
- Documentation: The current feature version has its own documentation set, separate from the LTS documentation.
- Support scope: Confirm with Znuny GmbH in Berlin which versions and issues its professional services cover.
Confirm how long each feature release stays in active maintenance before you standardize on it.
The LTS line is built for a longer-lived installation. znuny.org listed Znuny LTS 6.5.26 as its latest LTS release in October 2026. Organizations with strict change control, validation work or limited upgrade windows often prefer this line because it changes less between releases, which lowers the testing burden for each update. The trade-off is that you will not receive the newest feature work from the feature line.
- Stability: The LTS line changes less, which suits environments where every upgrade needs formal testing and sign-off.
- Longer horizon: It fits teams that want to schedule upgrades on a slower timetable.
- Separate documentation: The LTS version has its own documentation on doc.znuny.org, so use that set when you run LTS.
- Feature gap: Capabilities added in the feature line will not appear in LTS until they are backported, if they are backported at all.
Ask Znuny GmbH how long the LTS line is supported and how security fixes reach it.
Jira Service Management is delivered by Atlassian on its cloud edition, so Atlassian sets the feature and update schedule for that product. You do not choose a release line the way you do with Znuny. Your decision is about who controls upgrades and where the data sits, and that differs from a self-hosted Perl application that you run on your own database. Compare the two on what you need to control, not only on features.
- Vendor-controlled updates: Atlassian decides when changes reach the cloud service, so ask for the current update cadence in writing.
- Edition details: Confirm which Atlassian edition and plan you are buying, since features and data handling can vary by edition.
- Self-managed control: With Znuny, your team decides when each upgrade lands and whether it runs in your own infrastructure.
- Data location: Confirm where Atlassian stores your data for your chosen edition and region.
Get Atlassian's current edition and update cadence confirmed in writing before you compare it with a Znuny line.
What running Znuny costs beyond the software
The Znuny software itself carries no license fee, because it is distributed under GNU GPL v3. The recurring cost sits in the people and infrastructure that keep it running: a Linux server or virtual machine, a supported database (MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, or Oracle 19c or later), Perl 5.16.0 or higher, and Apache 2 with mod_perl2. Each of these needs patching, configuration, certificate renewal, backup verification and monitoring. Jira Service Management, by contrast, is priced per user on a subscription, so its cost rises with every agent and customer you add and does not depend on your own administration effort. Neither side is quoted here. Ask any vendor for the per-user price in writing, and compare it against your own staff hours and hosting bill.
Cost drivers for Znuny are mostly under your control. The ITSM packages (General Catalog and ITSM Core first, then the feature packages you choose) add configuration work for queues, priorities, service levels and configuration item classes, and the CMDB needs a data model agreed before import. Upgrades carry effort of their own: Znuny publishes a current feature line and a separate LTS line, so decide early which one you will run, and budget testing for each upgrade against your custom add-ons. Recurring costs grow with the number of agents, the volume of configuration items, and the number of customer-facing channels. Professional services from Znuny GmbH and vendor support are optional, and they are sold on scope and hours, so the price changes with how much of the operation you hand over.
When you request a quote from an implementation partner or from Znuny GmbH, ask for a written scope that lists the number of agents and customers, the environment (production, test and disaster recovery), the ITSM packages in scope, and the support hours and response expectations you need. Also ask who performs upgrades, backup restore tests and security patching, and what is excluded. For your internal comparison, separate one-time costs (installation, data migration, configuration and integration) from recurring costs (hosting, staff time, upgrades, support and subscription fees). Confirm the database and Perl versions against the current Znuny documentation before you size the environment, since those requirements shape both hosting and staffing.
Cost components on each side
This table sets the cost components of Jira Service Management against a self-hosted Znuny deployment, showing who is paid, whether each cost is one-time or recurring, and what drives it. No commercial prices for either side are supplied here, so obtain both quotes against the same written scope, covering the same users, ITSM packages and hosting model, before comparing totals.
| Cost component | Jira Service Management | Self-hosted Znuny | One-time or recurring |
|---|---|---|---|
| Licensing or subscription | Atlassian subscription priced by agent and tier, on Cloud or Data Center. Confirm current terms with Atlassian and your reseller. | No license fee for the GPL-3.0 software. Optional vendor support or professional services are contracted separately from Znuny GmbH. | Recurring for JSM. Optional recurring for Znuny support. |
| Infrastructure | Included in Atlassian Cloud. On Data Center, you pay for your own servers and their upkeep. | Your own servers or cloud accounts for application, web and database tiers, sized to agent count and ITSM package use. | Recurring |
| Database | Managed by Atlassian on Cloud. Data Center requires your own database licensing and administration. | MySQL, MariaDB, PostgreSQL or Oracle, all within supported versions. Database licensing depends on the engine you choose. | Recurring for hosting and licenses, one-time for setup |
| Administration staff | Atlassian administers the platform on Cloud. Data Center needs internal or contracted administrators. | Internal Perl and Linux operations skills for patching, Apache, mod_perl and database maintenance. | Recurring |
| Upgrades and testing | Atlassian rolls out Cloud changes. Data Center upgrades and regression testing are your responsibility. | You plan each feature release or LTS line, test ITSM packages and custom code, then deploy. Test effort grows with customization. | Recurring |
| Backups | Jira Cloud backup manager covers work items, comments, users and project configuration but excludes automation rules, apps and Assets, so you need separate exports. | You back up the database, attachments and configuration yourself. Storage and restore testing are your costs. | Recurring |
| ITSM configuration and process design | Queues, request types, SLAs and change workflows configured in JSM, often with consultant help. | Install General Catalog and ITSM Core, then add incident, problem, CMDB, SLA or change packages. Process modeling is your effort or a partner's scope. | One-time, with recurring changes |
| Migration | Export from JSM uses backup and CSV routes that omit some automation and Assets data. | Data is rebuilt or imported into Znuny, with CMDB and history mapping planned in advance. Scope drives effort. | One-time |
| Training | Vendor documentation and courses, plus internal agent onboarding. | Agent and admin training for a Perl-based ticketing interface, plus developer training if you customize. | One-time, with recurring onboarding |
What a move from Jira Service Management to Znuny involves
The sequence turns Jira Service Management queues, requests, service levels and configuration items into a Znuny environment on your own database, tested in parallel before cutover. Each step ends with a check you can verify before moving on.
Confirm scope and inventory the systems in use
Start by listing the Jira Service Management projects, request types, queues, approval flows, SLAs, automation rules, forms, connected apps and any Assets schemas that agents depend on. Separate the IT service desk from customer-facing queues, since Znuny covers both but they often run different processes. Record who owns each item and which integrations feed or read from Jira, such as monitoring, identity or chat. The output is a written inventory signed off by the service desk lead and the owners of the integrations. Nothing should move until every queue and integration has an owner and a decision: rebuild, replace or retire.
Export data and extract what backups leave out
Run the Jira Cloud backup manager for work items, comments, users, groups and project configuration. Atlassian's backup excludes automation rules, third-party apps and Assets, so extract those separately, using the Assets CSV export and a written record of each automation rule and app configuration. Attachments require a separate backup pass because Atlassian requires 48 hours between backups when attachments are included. Store the exports in a location you control and check them by opening sample tickets and counting records against Jira. Confirm with Znuny GmbH or your own developers which import paths they will accept, because no supplied fact describes a Jira-to-Znuny migrator.
Build the Znuny environment on supported versions
Provision Linux, preferably Debian or Red Hat as the Znuny README recommends, with Perl 5.16.0 or higher and Apache 2 with mod_perl2. Choose a supported database from the list in the README: MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. Decide between the current feature release line and the LTS line by comparing their release cadence and support terms on the Znuny releases page, then pin that version. Set up a test instance and a production instance on separate hosts or databases. The check is a clean install that loads the agent interface and passes the system checks on both instances.
Install General Catalog, ITSM Core and chosen packages
Install General Catalog and ITSM Core first, because the ITSM packages depend on them. Then add the packages you need: incident and problem management, the CMDB, service level management, or change management. Znuny's documentation recommends modeling most changes as a process instead of installing the change management package, so decide whether a process model is enough before installing it. Install the bundle or individual packages as the documentation describes. The output is a test instance where incident priority, configuration item classes and service levels can be configured and tested.
Map queues, request types, priorities and service levels
Translate the inventory into Znuny queues, priorities, service levels and customer or agent roles. Priority in Znuny derives from service criticality and impact, so define those values with the service owners rather than copying Jira priority names. Map each Jira request type to a Znuny ticket form or process, and record which fields carry over and which are rebuilt. Document the escalation and reporting rules that service level reporting must reproduce. The output is a mapping sheet approved by the process owners and reviewed against the Jira inventory.
Import or rebuild configuration items and tickets
Load configuration items through the CSV import, which Znuny supports for configuration items, after shaping the Assets export into the classes and attributes you defined. Import historical tickets only as far as your chosen import path supports, and confirm the method and its limits with Znuny GmbH or your developers before running it. Rebuild automation rules, third-party app behavior and notifications by hand from the written record made in the export step. Verify by sampling tickets, relationships and configuration items on the test instance against the Jira source. Expect the rebuild of automation to need developer time that cannot be estimated from supplied facts, so ask for it in the written scope.
Run parallel testing and cut over
Route a controlled set of real requests through both systems for a defined test period agreed with the business owners, and compare outcomes such as routing, priority, escalation timing and reports. Fix the gaps the comparison reveals and retest. Prepare a cutover runbook covering the freeze on Jira intake, the final data export, the email and integration switch, rollback steps and the named people who approve each step. The check is a signed go-live decision with the rollback path tested on the test instance.
Set up the upgrade and backup routine
After cutover, schedule regular database and file backups, and test restores on a separate host, since a backup you have not restored is not yet proven. Create a routine for applying Znuny patch releases on the chosen release line, using the test instance first. Keep the documentation for the current feature version and the latest LTS version in your runbook, as the Znuny documentation portal maintains both. Assign operations, security patching and on-call ownership in writing. The check is a successful restore drill and a documented upgrade procedure that the operations team has run once on the test instance.
Questions buyers ask before choosing Znuny
How much effort does a self-hosted Znuny deployment take?
Effort depends mostly on how much of the ITSM model you need, how many agents and customers use the system, and how much of the environment you already run. The base system runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended. Your team also has to choose a supported database, such as MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. The ITSM features are add-on packages, so General Catalog and ITSM Core go in first, and each extra package adds configuration and testing. Ask any partner to break the work into installation, ITSM configuration, integrations and operations.
Can an internal team run Znuny without outside help?
Yes, many teams with Linux and web application experience run Znuny in-house, but the work is continuous rather than a one-time project. Someone must own patching, database backups, Perl module updates, add-on package upgrades and monitoring. Znuny GmbH in Berlin offers professional services, and DeployOpen implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure under a written scope or a retainer. Decide early which tasks stay internal and which move to a partner, and confirm the skills available on your team before you commit to a plan.
How long does a move to Znuny take, and what sets the length?
No general duration can be stated because the length depends on your environment and scope. The main drivers are the number of queues, workflows, roles and customer portals to rebuild, the volume and cleanliness of exported ticket data, how many configuration items the CMDB must hold, and whether SLA reporting and change management must be configured from the start. Integrations with email, identity providers and monitoring also add time. Ask for a timeline in the written scope, with milestones for a test instance, data import, user acceptance testing and cutover.
Does Znuny cover both IT and customer service desks?
Yes, Znuny describes itself as a ticketing system for customer service, help desk and IT service management, so one installation can serve both audiences. Customer service queues use the base ticketing functions, while the ITSM add-on packages add incident and problem management, a CMDB of configuration items, classes and relationships, service level management reporting, and change management with work orders and change advisory board roles. Separate queues, roles and customer portals keep the two teams apart, but confirm during design whether you want one instance or two, because that changes data separation, administration and licensing of your own support time.
What Perl and Linux skills does the team need?
Your team needs working Linux administration for the web server, database and scheduled jobs, and enough Perl to read, patch and debug the application when an update or custom change breaks. Znuny publishes separate developer and Perl API documentation, which helps when you customize templates, modules or packages. Routine operations, such as backups and monitoring, do not require Perl writing. Ask any partner which custom code they would write, how they document it, and how it survives upgrades, because custom Perl is the part most likely to slow future releases.
Should we choose the LTS line or the feature line?
Choose the LTS line if you prefer longer stability between upgrades and fewer feature changes, and choose the feature line if you need newer functions sooner and can absorb more frequent upgrades. Znuny's releases page listed Znuny 7.3.8 and Znuny LTS 6.5.26 as its latest releases in October 2026, and the documentation portal keeps separate documentation for each line. Check the support window for each line in the release notes before deciding, and plan your upgrade cycle, test environment and rollback steps around the line you pick.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists the environment (cloud account, data center or air-gapped network), the Znuny line and the ITSM packages included, the number of queues, roles, workflows and integrations, and the data sources to migrate. The quote should also name deliverables such as configuration documentation, hardening steps, backup and restore testing, upgrade procedures and training. Confirm what happens after go-live, including support hours, who handles security patches, and whether ongoing support is a separate retainer. DeployOpen does not publish a price list, so the quote follows from that written scope.
How DeployOpen helps you decide and move to Znuny
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Jira Service Management vs Znuny, we start by mapping which of your IT and customer service queues, ITSM packages and integrations must move, and which can wait.
How we scope
- Written scope lists which Znuny feature version or LTS line, databases and ITSM packages are covered
- We inventory JSM projects, request types, queues, SLAs and integrations that Znuny must replicate
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We install Znuny on Linux with Perl, Apache and your chosen supported database in your environment
- We configure ITSM Core, General Catalog and the chosen packages, then test queues, priorities and SLA reports
- We run security testing on the deployment and document configuration, access roles and recovery steps
How we hand over
- Handover covers runbooks for administrators, upgrade steps between Znuny releases and backup procedures
- We document the mapping of JSM workflows to Znuny processes, including change management decisions
- We prepare controls and evidence your compliance team can review with its independent auditor
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover moving between Znuny standard and LTS release lines as your schedule requires
- Ask us to confirm response arrangements and upgrade scope in the written retainer before go-live
