When a ServiceNow alternative like Znuny fits your ITSM estate
Znuny fits when your core need is ticket-centric IT service work that you host yourself. Renewal pressure, a data residency rule or a requirement that ITSM records stay inside your own network often triggers the search. ServiceNow suits organizations that want one platform carrying many workflows, with a vendor-run cloud handling the application stack. Znuny suits teams whose daily work is incident, problem, change and service level management in a system they control, with the ITSM functions added as packages on top of a ticketing core. If your requirement list is mostly those ITSM processes, the comparison is narrower than it first appears, and it is worth testing that assumption against your actual catalog of workflows before you start.
The decision turns on three questions. The first is breadth of workflows: if you expect HR, facilities, security operations or custom application workflows to run on the same platform, Znuny will not cover that breadth, and you should price those gaps separately. The second is skills: Znuny runs on Linux with Perl and Apache, so your team needs staff who can maintain that stack, apply upgrades and troubleshoot modules, or you need a support arrangement that provides them. The third is whether the CMDB must be a platform feature. Znuny's configuration item model is available through its ITSM packages, but it is a module in a ticketing system rather than a platform-wide data model. Confirm each of these with your own architects and a proof of concept before committing.
Which option fits which scenario
This table matches common ServiceNow exit scenarios to Znuny or to the alternatives named in the facts. Read each row as a starting point: the better fit depends on which capabilities you actually need and what your team can operate. The main takeaway is that Znuny suits ticket-centric ITSM with a Perl and Linux operations capability, while platform breadth, air-gapped operation and low operations skills point elsewhere.
| Scenario | Better fit | Reason |
|---|---|---|
| Single ITSM team with a CMDB need | Znuny with ITSM packages | Znuny's packages include a CMDB of configuration items, classes and relationships, plus CSV import and export of configuration items. |
| Enterprise running HR and security workflows on one platform | Neither as a direct replacement | Znuny is a ticketing system for customer service, help desk and ITSM. Confirm which non-ITSM workflows exist before assuming Znuny covers them. |
| Air-gapped network | Confirm with the vendor and your environment | Znuny runs on your own Linux servers with the databases listed in its README. Confirm how you will obtain updates and packages without internet access. |
| Team with no Perl or Linux operations skills | Zammad or GLPI, or a Znuny support arrangement | Znuny runs on Linux with Perl 5.16.0 or higher and Apache 2 with mod_perl2. Without that skill set, budget for outside operations support or pick a platform your team can run. |
| Need for change management with formal approvals | Znuny, with a process-based model | Znuny includes change management with work orders and change advisory board roles, but its documentation recommends modeling changes as a process in most cases. |
| Need to keep one LTS line for stability | Znuny LTS 6.5.26 track | Znuny publishes a separate LTS release line alongside feature releases, and separate documentation for each. Confirm the support window with Znuny GmbH. |
| Need for a hosted, vendor-run service | Zammad hosted plans or ServiceNow itself | Zammad GmbH sells hosted plans in German data centers. Znuny is typically self-operated, so confirm any hosted option directly with Znuny GmbH. |
How a platform differs from a ticket-centric system
The core difference is scope. ServiceNow runs ITSM as one application on a broader platform, where workflows, forms, catalogs and data model are built on a shared application layer that also serves HR, security and customer operations. Znuny is a ticketing system for customer service, help desk and IT service management, and its ITSM capabilities arrive as add-on packages on top of that ticketing core, with General Catalog and ITSM Core installed first. For an IT organization that needs incident, problem, change, CMDB and service level reporting and nothing much else, this narrower model is often enough. It matters most when the non-ITSM workflows you plan to add are few and well defined. If you expect to run HR cases, facilities requests or security response on the same engine within a few years, confirm now whether Znuny's ticket model can carry those forms and approvals without custom code.
Customization follows the same split. In ServiceNow, most changes are made through its platform tooling, and the skills are platform-specific. In Znuny, changes are made in the Perl codebase, its configuration and its package system, so the people who maintain it need Perl, the Znuny developer documentation and an understanding of how packages override core behavior. Check how many of your current changes are configuration, such as dynamic fields, queues, states and notifications, and how many are code. Configuration usually survives upgrades more easily, while custom code must be retested against each Znuny release line, including whether you track the feature release or the LTS line.
Znuny's own documentation adds a useful caution. It 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 you install that package, map your change approvals and change advisory board roles against what the package provides, and decide whether a process model, rather than a built-in package, better matches how your organization approves changes. That decision, made early, reduces the amount of Perl you will own later.
Where your data lives and who operates it
ServiceNow, its Private Stack and self-hosted Znuny differ mainly in who runs the servers, who patches the application and who holds the data. Each card below covers one part of that split so you can map it to your own residency and operating constraints.
ServiceNow cloud hosting
ServiceNow operates the instance, its infrastructure and the upgrade cycle, and your ITSM records sit in ServiceNow's hosting environment. Ask which regions and data centers hold your instance, how backups and restores are handled, and what contractual evidence you receive for hosting controls. Your team controls configuration and data access inside the platform, but not the underlying stack.
ServiceNow Private Stack split
Under Private Stack, your team or a partner runs the load balancer, application server and database tiers, while ServiceNow supplies the application software, upgrade packages, deployment guidance and support. Entry starts with your ServiceNow account team and a workshop covering architecture, hardware sizing, database selection and operational readiness. Confirm current Private Stack terms with ServiceNow before you plan staffing.
Self-hosted Znuny on Linux
With Znuny, you own the full stack: a Linux host, preferably Debian or Red Hat, Perl 5.16.0 or higher, and Apache 2 with mod_perl2 recommended. Supported databases are MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Your team patches the operating system, web server, database and Znuny itself, so confirm who holds that role before you commit.
Identity integration
Decide how agents and administrators authenticate before go-live. ServiceNow typically integrates with your existing identity provider through its own configuration, while Znuny needs its authentication and single sign-on settings set up and tested against your directory. Check how user provisioning, deprovisioning and role mapping will work for each option, since these determine who can see tickets and CMDB data.
Compliance evidence
Under either model, the controls you need to evidence cover access, change, backup and logging. In a hosted service, much of that evidence comes from the vendor's assessments, while a self-hosted Znuny deployment requires you to produce and retain it yourself. Independent auditors issue any attestation, so ask your assessor which evidence each option can supply directly.
Data residency and sovereignty
Residency is often the deciding factor. Self-hosted Znuny keeps ticket, CMDB and attachment data inside the infrastructure you choose, including air-gapped networks, while ServiceNow cloud and Private Stack placement depend on the deployment you contract. Map where each data class sits, including backups and vendor support access, and confirm those locations in writing.
Licensing, release lines and support options
Znuny is distributed under the GNU GPL v3, and it continues the OTRS Community Edition 6.0.30 codebase after that edition reached end of life in December 2020. For an IT team, the license means the software itself carries no per-agent or per-module fee. Your recurring cost sits in hosting, staff time and any external support you choose to buy. Before you commit, confirm with your legal or procurement team that the GPL v3 terms fit how you plan to modify, bundle or redistribute the installation, particularly if you add custom packages or integrations.
Znuny publishes two release lines. The feature line, with 7.3.8 listed as its latest release in October 2026, carries new functionality. The LTS line, with 6.5.26 listed in the same period, is maintained for a longer support window with fixes and no major feature changes. Upgrade planning depends on which line you choose. On the LTS line, you can schedule patch installs without taking on feature changes to your ticket workflows or ITSM packages, which keeps your change calendar predictable. On the feature line, you get newer capabilities sooner but should test each release against your custom templates, dynamic fields and package add-ons before rollout. Check the current support dates for each line on the Znuny release page before you pick one.
Support is the other half of the decision. Znuny GmbH, based in Berlin, offers professional services for Znuny, so you can buy implementation, upgrade or troubleshooting help from the project's commercial team instead of building all of that in-house. ServiceNow works differently. Its subscription is quoted through an account team against your user counts, modules and term, and support is bundled into that agreement. With Znuny, you assemble the cost yourself from the license (zero), infrastructure, internal administrators and any Znuny GmbH contract. Ask Znuny GmbH for a written scope covering response times, upgrade assistance and the LTS versions it will support, and compare that document with the terms in your current ServiceNow order form.
What each option costs over its life
This table sets the cost components of ServiceNow against those of self-hosted Znuny, separating one-time from recurring spend. Read each row as a question to put to your ServiceNow account team or to your own staff and partners, because most figures on the ServiceNow side are only available through a written quote. Znuny's license carries no fee under GPL v3, so its cost sits in infrastructure, people and any services you buy.
| Cost component | ServiceNow ITSM or Private Stack | Self-hosted Znuny |
|---|---|---|
| Software license | Subscription quoted through the ServiceNow account team, recurring per the contract term | Zero license fee under GPL v3; the software itself is free to use |
| Platform or upgrade packages | Included in the subscription on ServiceNow cloud; on Private Stack, ServiceNow supplies application software and upgrade packages under its terms | Upgrades are your work: Znuny feature and LTS releases applied to your own install and tested against your ITSM add-on packages |
| Infrastructure | On cloud, included in the subscription; on Private Stack, you own the load balancer, application server and database tiers | Your servers or cloud instances for the Apache, Perl and database tiers, recurring hosting and backup storage |
| Database and operations | Managed by ServiceNow on cloud; on Private Stack, your DBA and platform team operate it | MySQL, MariaDB, PostgreSQL or Oracle that you select, patch, back up and monitor, typically a recurring staff effort |
| Initial setup and configuration | Account team engagement and, for Private Stack, a workshop on architecture, hardware sizing, database selection and operational readiness, purchased before deployment | Installing General Catalog and ITSM Core, choosing the ITSM package bundle or individual packages, and configuring CMDB classes and service levels, mostly one-time |
| Professional services | Partner or vendor implementation, billed by scope or quoted by the vendor | Optional Znuny GmbH or other partner work, quoted per written scope; not required to run the software |
| Staff and skills | Administrators for the ServiceNow platform and, on Private Stack, infrastructure staff | Administrators for Linux, Perl, Apache and the database, plus ITSM process owners who maintain the add-on configuration |
| What drives cost up | User count, module count, sandbox and environment needs, and the scope of Private Stack hardware and workshop work | Number of agents and CIs, high availability design, custom Perl changes, and the number of packages you enable |
| What keeps cost down | Clear module scope in the quote, a stated renewal and uplift schedule, and written upgrade terms | Standard database and OS choices, a documented change process instead of extra modules where Znuny advises it, and a tested upgrade routine |
What a move from ServiceNow to Znuny involves
The sequence turns ServiceNow's records and process rules into a Znuny ITSM configuration that is tested in parallel and then cut over, with each phase closing on a written check. The order matters because the CMDB and process model must exist before records can be mapped to them.
Inventory ServiceNow records and integrations
Start by listing what ServiceNow holds: incidents, problems, changes, configuration items, knowledge articles, attachments, users, groups and approval history, along with every integration that sends or reads tickets. Export each set within ServiceNow's own list export limits, and plan a separate extraction for attachments. Ask your ServiceNow administrator to confirm which tables are custom and which workflows, catalog items and notifications exist, because these are usually rebuilt by hand in Znuny and their scope should be agreed in writing before work starts. The step is complete when every record set has a row count, a source and an owner.
Define the ITSM process model
Decide how incidents, problems and changes will move through states, who approves what and how priority is set from service criticality and impact. Znuny's documentation recommends modeling change management as a process in most cases rather than installing the change management package, so confirm that approach with your change board before configuring anything. Record the decisions in a short process document that maps each ServiceNow state and assignment rule to a Znuny equivalent or to a gap that needs custom work. The step is complete when the process owner has signed off the document.
Install Znuny with General Catalog and ITSM Core
Provision a Linux server, preferably Debian or Red Hat, with the database engine your standards allow from the supported list (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. Install General Catalog and ITSM Core first, since the other ITSM packages depend on them, then add the incident, problem, CMDB, service level and change packages you chose in step two. Your platform engineers or DeployOpen would carry out this work under a written scope. The step is complete when a clean test instance starts and each installed package appears in the admin package list.
Configure CMDB classes and relationships
Translate the ServiceNow CMDB model into Znuny configuration item classes, attributes and relationships. Keep the class list short at first, because each added class adds fields to load and maintain. Confirm service level definitions and the criticality and impact values that drive priority. The check at the end of this step is a sample set of configuration items entered by hand that shows relationships and service level reporting behave as the process document requires.
Map incidents, problems and changes
Build a field mapping for each ticket type, covering states, priorities, queues, owners, linked configuration items, close codes and timestamps. Run a small sample export through the mapping on the test instance and compare results with the source records field by field. Record each mismatch and decide whether it is fixed in mapping, in configuration or accepted as a known difference. The step is complete when the sample reconciles and every open mapping question has an owner.
Load configuration items and tickets
Import configuration items through Znuny's CSV import, then load historical tickets and link them to the imported items. Run the full load on a fresh copy of the test instance, record counts and error logs, and check relationships on a sample of high-criticality services. Confirm which attachments and history are kept and whether reference numbers from ServiceNow must be preserved for audit. The step is complete when record counts match the inventory from step one, with every exception listed.
Run parallel testing and cut over
Run both systems side by side for a period agreed with the service owners, routing new tickets to Znuny while ServiceNow stays available for reference. Test email notifications, service level reports, approvals and every integration from step one. Plan the cut-over window, freeze ServiceNow for new entries, run a final delta load and switch integrations. The step is complete when the service owners sign the cut-over record and open tickets have a clear home.
Retire ServiceNow and keep an archive
After cut-over, keep a read-only archive of ServiceNow records for the retention periods your policies and regulators require, and confirm with the subscription owner when access ends. Document the Znuny runbook for backups, upgrades and package updates, and decide between the current feature line and the LTS release line for ongoing support. The step is complete when the archive is verified, the subscription end is confirmed in writing and the runbook has an owner.
Questions buyers ask before switching from ServiceNow to Znuny
What does it cost to switch from ServiceNow to Znuny?
The licence cost is zero because Znuny is GPL-3.0, so the switch cost is the work around it. The main components are infrastructure (Linux servers, a supported database such as PostgreSQL 12.0 or later, and Apache 2 with mod_perl2), the one-time build of ITSM packages, CMDB design, data migration and testing, and the staff who run it afterwards. Costs rise with the number of ServiceNow workflows, custom tables and integrations you need to rebuild, and with how much history you migrate. Ask any implementation partner for a fixed-scope quote built from a written list of those items, and ask Znuny GmbH whether it offers paid support for your version.
How long does a ServiceNow to Znuny migration take?
The timeline is set by scope, not by the software. The drivers are how many ITSM processes are in use, how much CMDB data must be mapped to Znuny's configuration item classes and relationships, how many integrations feed or read tickets, and how many approval paths you must model. Znuny's own documentation recommends installing the ITSM packages in a fixed order, which makes the base build predictable, but the data and process work decides the calendar. Ask for a phased plan with a pilot queue, a parallel run and a defined cutover, and confirm each milestone in writing before work starts.
Can our internal team migrate to Znuny without outside help?
A capable team can deploy Znuny alone if it has Linux administration, database and web server skills and someone who can maintain Perl-based configuration and packages. The harder part is usually the ITSM design: deciding how incidents, problems and changes map to the old ServiceNow model, and rebuilding SLAs and approval logic. Many teams split the work, keeping platform operations in-house and bringing in outside help for the design, data mapping and testing. Be honest about who will own upgrades after go-live, since that recurring task is where in-house efforts often stall.
What skills and governance does a Znuny deployment need from our team?
You need named owners for the platform, for the ITSM configuration, and for data quality in the CMDB. On the technical side, expect Linux, Perl, database administration and web server operation. On the governance side, define who approves changes to priorities, service criticality and the CAB roles, because Znuny's change management packages expose those settings directly. Write down which of your ServiceNow controls, such as role-based access and audit trails, you will reproduce and how you will evidence them. Confirm with Znuny which configuration and logging features your chosen version provides before you commit to a control design.
Can Znuny replace the full ServiceNow platform?
Znuny covers ticketing, ITSM incident and problem management, a CMDB, service level reporting and change management, delivered as add-on packages on top of the base system. It is not a general application platform. ServiceNow's wider capabilities, such as its low-code app builder, HR and customer service products, and the broader ITOM suite, have no direct Znuny equivalent. Map every ServiceNow application you use against what Znuny provides, and list the gaps as decisions: accept, rebuild outside the ticket system, or keep ServiceNow for that workload. Confirm each gap with Znuny before you plan around it.
Should we choose the Znuny feature release or the LTS release?
Choose the feature line if you want the newest functionality and can take upgrades on a regular cycle. Choose the LTS line if stability and a longer maintenance horizon matter more than new features, which is common for regulated environments with change freezes. Znuny publishes separate documentation for the current feature version and the latest LTS version, so check the version you deploy against the matching guide. Use the current release numbers listed on the Znuny releases page when you plan, and ask Znuny how long each line receives fixes and how upgrades between lines are handled.
Should we model change management as a Znuny process instead of the change feature?
In most cases, Znuny's documentation recommends modeling changes as a process rather than installing its change management package, which it says only makes sense under special circumstances. That means using the general process and ticket features for approvals, with the CAB logic defined in your own workflow. The decision affects upgrade effort and how closely your process matches the ServiceNow change model. Test both designs with a real change type from your estate, and confirm the recommendation with Znuny for your use case before you build it.
Official sources to read next
Before you commit to Znuny, read the Znuny ITSM features documentation against your current ServiceNow scope. It lists the add-on packages, the General Catalog and ITSM Core prerequisites, and the incident, problem, CMDB, service level reporting and change management pieces. Make a list of every ServiceNow workflow you rely on and check which package covers it. The documentation also says that in most cases Znuny recommends modeling changes as a process instead of installing the change management feature, so decide early whether your change approvals need that package at all.
Next, use the Znuny documentation portal at doc.znuny.org to confirm which line you will run. The portal keeps separate documentation for the current feature version and the LTS version, plus agent, developer and Perl API guides. Your developers will need the Perl API material if you plan custom modules, and your administrators will need the matching version for upgrades. Confirm the supported database versions and the Linux, Perl and Apache requirements with your platform team before you pick a line, because those prerequisites drive your hosting work.
Check the Znuny releases page for the current feature and LTS versions before you plan an upgrade calendar, and compare them with your own change freeze windows. For the ServiceNow side of an air-gapped or sovereign decision, read the ServiceNow Private Stack launch post. It describes the customer or partner owning the load balancer, application server and database tiers, and it says a deployment starts through the account team with a paid workshop. Ask your ServiceNow account team to confirm the current workshop scope and whether it is quoted separately from your subscription.
How DeployOpen helps you evaluate and move to Znuny
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For ServiceNow vs Znuny, that means working from your actual ITSM use, your hosting constraints and your data before any decision or migration is made.
How we scope
- Inventory which ServiceNow ITSM processes you run today, such as incident, problem, change and service level reporting.
- Agree which Znuny ITSM packages, including General Catalog and ITSM Core, your scope needs before installation.
- Put scope, deliverables and timelines in writing before any work starts, as engagements are fixed-scope.
- Ask for a written quote that follows from that scope; DeployOpen does not publish a price list.
How we build
- Plan the Linux, Perl, Apache and database layout in your own data center or cloud account.
- Model change management as a process, following Znuny's documented guidance, and test that workflow with your approvers.
- Build CMDB classes and relationships and test CSV import and export of configuration items against your exported data.
- Test service level reporting and access controls, and document each configuration decision for your own team.
How we hand over
- Deliver written documentation covering installed packages, configuration, backups and the upgrade path between Znuny feature and LTS release lines.
- Walk your administrators through daily operations, ticket workflows and CMDB maintenance before handover.
- Confirm with you which evidence your compliance assessors will need, while noting that independent auditors and certification bodies issue any audit reports or certifications.
- Provide a clear record of what was migrated, what was rebuilt by hand and what remains open.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Znuny upgrades and security testing of the application and its APIs as recurring work with your team.
- Keep backups, restore tests and version tracking under your control, inside your own infrastructure.
- Confirm response expectations, scope and fees in the written retainer before work begins.
