Freshservice vs Znuny: which to choose

When does a Freshservice alternative like Znuny make sense?

Znuny makes sense when a Freshservice renewal, a per-agent cost question or a data location requirement leads you to ask whether your service desk can run on servers you control. Freshservice fits teams that want a managed SaaS desk with a Frankfurt data center and no server work: upgrades, hosting and availability stay with the vendor, and your staff administer the tool rather than the platform beneath it. Znuny fits teams that already run, or can staff, a Linux, Perl and database stack, and that accept the operating work of patching, backups and upgrades in exchange for owning the environment.

The decision turns on three questions. First, staffing: who will run the Perl application server, the database and the upgrade cycle, and does that person or team exist today or need to be hired or contracted? Znuny's ITSM features documentation describes the packages involved, but it does not size the operations work, so ask a Znuny partner or your own platform team to estimate it in writing. Second, which ITSM packages you actually need. Incident, problem, CMDB, service level reporting and change management are separate installs on top of General Catalog and ITSM Core, so list the Freshservice features your team uses today and map each to a package before comparing costs. Third, how formal change management must be. Znuny's documentation recommends modeling changes as a process in most cases and installing the change management package only in special circumstances. If your auditors or change advisory board require a built-in change workflow, Znuny can supply one, but test that requirement early, because it changes the scope of configuration and training.

Which option fits each scenario

This table matches common Freshservice-to-Znuny situations to the option that fits best and the condition that decides it. Read each row against your own team skills, your plan terms and your data rules, and treat Freshservice cells as points to confirm with your account team.

Scenario	Better fit	Deciding condition
Linux and database operations group in-house	Znuny, self-hosted	Your team can run Perl, Apache with mod_perl2, and a supported database such as PostgreSQL 12.0 or later, and can patch and back up the stack.
No appetite for server administration	Freshservice, or Znuny only with a managed or partner-run deployment	Self-hosting makes your team responsible for upgrades, backups and availability. Without that capacity, compare a hosted option or a partner-operated install before choosing Znuny.
Already running OTRS Community Edition	Znuny, as the continuation path	Znuny continues the OTRS Community Edition 6.0.30 codebase under GPL v3, so existing customizations and processes are easier to carry over than with a new product. Confirm add-on compatibility first.
Formal change advisory board workflows	Confirm in Freshservice, then decide	Znuny offers change management with work orders and CAB roles, but its documentation recommends modeling changes as a process in most cases. Confirm Freshservice change approval flows against your plan before deciding.
Strict data residency rules	Znuny, self-hosted in your own or an EU-controlled data center	Znuny keeps ticket data where you host it. Freshservice's Frankfurt data center is a regional choice, so confirm with the vendor what it does and does not change about access and jurisdiction.
Need for CMDB and service level reporting in one tool	Znuny with ITSM packages installed	Znuny's packages cover a CMDB of configuration items, classes and relationships, and service level management reporting. Map your current Freshservice asset and SLA use cases to these packages before committing.
Cost planned around per-agent plan fees	Znuny, weighed against your own operating effort	Znuny has no license fee under GPL v3, but hosting, administration, upgrades and any support contract recur. Compare total ownership with your current per-agent invoices, not license cost alone.

Capabilities side by side: Freshservice and Znuny

This table compares how Freshservice and Znuny cover the ITSM functions most teams depend on, plus licensing, hosting and deployment. Znuny entries come from its documentation and README, while Freshservice entries describe capability areas that you should confirm against your own plan. The main takeaway is that Znuny covers core ITSM through add-on packages you install and operate, while Freshservice delivers them as a managed service.

Capability	Freshservice	Znuny
Incident and problem management	Built into the hosted service desk; confirm which ticket types, priorities and problem workflows your plan includes	Available as ITSM add-on packages; priority is derived from service criticality and impact
Configuration items and CMDB	Asset and CI records delivered within the hosted product; confirm CI class and relationship depth for your plan	CMDB of configuration items, classes and relationships, delivered as an ITSM package
CSV import and export of CIs	Confirm import and export options and any unit or record limits with Freshservice	CSV import and export of configuration items is supported
Service level reporting	SLA and reporting features are included; confirm report types and SLA tiers per plan	Service level management reporting is included in the ITSM packages
Change management	Change workflows are offered; confirm approval roles and advisory board features for your plan	Work orders and change advisory board roles are available, but Znuny recommends modeling changes as a process in most cases
Licensing	Commercial per-agent subscription; confirm current plan pricing and add-on terms directly with Freshservice	GNU GPL v3; no license fee for the software itself
Hosting and deployment	Vendor-hosted SaaS; regional data center options are available, so confirm the location for your account	Self-hosted on Linux, preferably Debian or Red Hat, operated in your own infrastructure
Database and runtime	Managed by the vendor; not customer-selected	Perl 5.16.0 or higher with Apache 2 and mod_perl2 recommended; supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later

Why Znuny suggests modeling change as a process

Znuny's own documentation says that in most cases it recommends modeling changes as a process instead of installing its change management feature, and it describes the packaged feature as sensible only in special circumstances. For a team leaving Freshservice, this is the first design decision in the change workflow, and it should be made before any configuration is copied across. The documentation is the place to confirm this guidance for the Znuny version you plan to run, since the ITSM features are delivered as add-on packages on top of General Catalog and ITSM Core. The Znuny ITSM features documentation sets out the change management package, its work orders and change advisory board roles.

Keeping the change management package means you install it, then rebuild your approval structure in its terms: work orders, change advisory board roles and the states a change moves through. Your Freshservice change approvals, approver groups and any custom fields will need equivalents, and each change type you configure adds administration that someone must own after go-live. Modeling approvals in the process layer means defining the workflow with Znuny's process tooling and using ticket states, queues and notifications to route approvals to the right people. That path puts more of the logic in your own process definitions, so the admin work moves into designing, testing and documenting those processes and keeping them aligned with Znuny upgrades.

Before choosing, map every current Freshservice change approval: which change types exist, who approves each one, what evidence is attached, and which steps are automated. Count the number of distinct approval paths, because a small number of paths often fits a process model well, while many paths with board-level review may justify the package. Ask your Znuny partner or your own administrators to confirm each mapped path against the documentation for your chosen version, and record the decision with the reason, so auditors and the change board can see why the approach was selected.

What self-hosting a Perl ticket system changes for data and control

Moving from Freshservice's managed service to Znuny shifts where ticket data sits, who patches and backs it up, and who can reach it. Each card below names a control, the condition under which it starts to matter, and what to confirm with Freshservice or Znuny before committing.

Where ticket data lives

With Freshservice, tickets, attachments and CMDB records sit in Freshservice's Frankfurt data center. With Znuny, they sit wherever you install it, including your own data center, a private cloud or an EU provider. Confirm which database engine you will run (MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, or Oracle 19c or later), where attachments are stored, and whether backups leave the region.

Patching and backups move to you

Under Freshservice, the vendor operates the platform, applies updates and manages availability. With Znuny, your team owns the Linux host, Perl runtime, Apache with mod_perl2, database and backup jobs. Confirm who on your staff holds these duties, how restores are tested, and what happens to ticket history if a backup is missing.

Identity and access control

Freshservice handles agent logins and role permissions inside its own tenant. Znuny manages agent and customer accounts and groups locally, so you must decide how it authenticates, how joiners and leavers are removed, and who can change roles. Check whether your directory integration is supported by the Znuny version you select and whether privileged accounts are separated from daily agent work.

Audit evidence you generate

Freshservice keeps audit trails in its platform, and you request exports when needed. A self-hosted Znuny instance writes its own application, web server and database logs, which you must retain, protect and make reviewable. Decide which change, access and admin events must be preserved, and confirm with your auditor which evidence they will accept. DeployOpen prepares these controls and evidence, but it does not issue audit reports or attestations.

Upgrade cadence and version choice

Znuny publishes a current feature line and a separate LTS line, with Znuny 7.3.8 and Znuny LTS 6.5.26 listed as current in October 2026 on znuny.org. Choosing LTS favors slower change, while the feature line gets newer functions sooner. Plan a recurring upgrade window, test add-on packages against each release, and confirm the support period for whichever line you choose.

Vendor access under regional hosting

Freshservice's Frankfurt data center answers where data is stored, but not who at the vendor can reach it or under which legal process. Self-hosting Znuny removes the vendor from routine data access, yet support contracts with Znuny GmbH may still involve remote sessions. Ask Freshservice for its access and support model in writing, and ask any Znuny services provider how remote access is granted, logged and revoked.

Which path fits your current situation

Teams on Freshservice often look at Znuny when policy requires that ticket, asset and attachment data run inside their own network. Znuny is software you install and operate yourself, so the application, database and upgrade schedule fall under your change control. Freshservice remains a sound choice for many teams, and this path only makes sense once you know what control you need.

Which data must stay on your servers: List the ticket, asset and attachment data your policies cover, and confirm whether backups and logs fall under the same rule.
Who runs the stack: Znuny runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended. Name the people who will patch the operating system, Perl and the database.
Which ITSM features you use today: Znuny delivers incident, problem, CMDB, service level reporting and change management as add-on packages on top of General Catalog and ITSM Core. Map each Freshservice workflow to one of them before committing.
Where GLPI may fit better: If your main need is asset inventory and ITIL management in one GPL-3.0 product, GLPI may be the closer match.

Before you size any server, confirm the export you can take from Freshservice and the Znuny features your workflows need in the ITSM features documentation.

What drives the cost of Znuny against Freshservice plans

Freshservice is a recurring subscription priced per agent and plan tier, while Znuny carries no license fee but moves hosting, setup, patching and support onto your own budget. The cards below separate one-time work from recurring costs so you can compare the two totals on the same basis.

Freshservice subscription by agent and plan

This is a recurring cost that scales with the number of agents and the plan tier you buy. Pull the per-agent figures, add-on charges and renewal terms from your current order form rather than from list pricing, because negotiated rates often differ. Check whether asset units or other add-ons are billed separately, since they change the annual total.

Znuny software license

Znuny is distributed under GNU GPL v3, so there is no license fee to pay for the software itself. The cost you still carry is the staff time to evaluate the ITSM packages you need and to decide which ones to install. Confirm the license terms that apply to any custom modules your team or a partner writes, since those belong to you to maintain.

Server and database hosting

This is a recurring cost for the Linux servers, Apache with mod_perl2 and the database that Znuny needs, sized for your agent count and ticket volume. Your hosting spend depends on whether you run it on existing virtualization, in a cloud account or in a data center, and on the database you choose among MySQL, MariaDB, PostgreSQL and Oracle. Ask your team to size backups and high availability into the same estimate.

One-time migration and configuration

This is a one-time cost for exporting tickets, configuration items and service definitions from Freshservice, then rebuilding queues, SLAs, change workflows and the CMDB in Znuny. The effort rises with the number of workflows, custom fields and integrations you need to recreate. Ask for the migration approach in writing, including how Freshservice history is preserved and how the cutover is tested.

Recurring administration and patching

This recurring cost covers operating the Perl application, applying Znuny point releases, patching the operating system and database, and reviewing agent access. It is usually the largest ongoing item after hosting, and it is where self-hosting costs most often differ from a subscription. Confirm which Znuny release line you will run, since the current feature version and the LTS version each have their own documentation and update cadence.

Optional professional support

This is an optional recurring cost for professional services from Znuny GmbH in Berlin, or for another qualified partner. It moves troubleshooting, upgrades and configuration help out of your own team's schedule and into a contract. Decide whether your team needs support hours on call or a fixed set of services, and ask for the response scope in the quote before you compare it with the Freshservice support tier you already pay for.

What a move from Freshservice to Znuny involves

The sequence turns Freshservice's workflows, SLAs and asset records into a tested Znuny instance that the team can cut over to with a clear rollback point. Each step produces a document or check that the next one depends on.

Inventory workflows, SLAs and change approvals
Document how your team uses Freshservice today: ticket categories, priorities, assignment groups, SLA targets, escalation rules, change approval paths and which asset or CMDB records agents rely on. Involve service desk leads, change managers and the people who run reports. The output is a reviewed inventory that names each process, its owner and whether it will be kept, simplified or modeled differently in Znuny. Confirm which Freshservice automations are exported at all, since the account export is a data dump rather than a configuration backup.
Export the full account data
A Freshservice account administrator runs the full service desk export from Admin, Account, Export. The data arrives as XML at the registered agent email address, so confirm that mailbox is controlled by the right people and that the file is stored in an approved location. Check that the file opens and that record counts for tickets, requesters, assets and conversations match what the admin sees in the product. The output is a verified, access-controlled copy of the source data.
Select packages and build a test instance
Decide which Znuny ITSM packages you need, such as incident and problem management, the CMDB, service level management reporting or change management. Znuny's documentation recommends modeling changes as a process in most cases rather than installing the change management feature, so review that choice with your change board. Install General Catalog and ITSM Core first, then build a test instance on a supported database: MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. The output is a documented package list and a working test system.
Map records and import where suitable
Map Freshservice tickets, requesters, agents, assets and configuration items to Znuny's model of tickets, customers, users, queues, configuration items, classes and relationships. Znuny supports CSV import and export of configuration items, which may suit asset and CI data. Ticket history and attachments usually need a deliberate approach, so test a sample of each. No direct Freshservice migrator appears in the sources used for this page, so confirm with Znuny and your implementation partner which conversion tools or scripts are realistic before you plan the effort. The output is a field mapping document and a test import with reconciled counts.
Rebuild SLAs, priorities and queues
Recreate the service levels, priority logic, queues and escalation rules from the inventory in Znuny. Znuny derives priority from service criticality and impact, so confirm the criticality and impact values match how your teams assign priority today. Test each rule with sample tickets and confirm that service level reports show the results you expect. The output is a signed-off configuration that matches the inventory, with test cases and their results kept for the change record.
Run parallel validation and cut over
Run both systems in parallel for a defined period agreed with the business, comparing ticket routing, SLA timers, approvals and reports on live work. Keep Freshservice available until the exit criteria agreed in the test plan are met, and keep the XML export as a retained record. Then freeze new work in Freshservice, run the final delta, switch intake and integrations to Znuny and confirm with users that the new queues work. The output is a documented cutover with a tested rollback point and an archive of the source export.

Questions buyers ask before choosing Znuny over Freshservice

How much effort does running Znuny take, and who does it?

Running Znuny is ongoing work, not a one-time installation. Someone must own the platform stack (the Linux host, the Perl runtime, Apache with mod_perl2 and the database), apply Znuny feature or LTS releases, enable and update add-on packages, take backups, and review logs. With Freshservice, the vendor carries these tasks inside the subscription. With Znuny, your organization carries them through internal staff or a support contract from a provider such as Znuny GmbH in Berlin. Effort rises with customization, agent count, integrations and the number of ITSM packages you enable. Ask any provider for a written list of recurring tasks, the person responsible for each one, and how upgrades are tested before they reach production.

Can a team without Perl skills operate Znuny?

Day-to-day administration through the web interface needs no Perl, so agent and administrator tasks such as queues, users and standard ITSM configuration can be handled by trained staff. Perl becomes necessary when you troubleshoot application errors, write custom modules, change templates in code or read the Perl API documentation that Znuny publishes. A team without Perl skills should name one owner for Linux and database administration, plus a developer or partner for code changes. Before committing, ask the candidate team to perform a supervised test: restore a backup, apply a release on a staging copy and read one error log. The results show whether the skills gap is small enough to close with training or large enough to require an outside contract.

What does Znuny need from our servers, database, patch windows and admins?

Znuny runs on Linux, with Debian or Red Hat preferred, and needs Perl 5.16.0 or higher. Apache 2 with mod_perl2 is recommended. The supported databases are MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, so the choice depends on what your database team already runs and supports. Plan maintenance windows for the web tier, the database and each Znuny upgrade, and agree them with your change board. You will need at least one Linux administrator, one database administrator for backup and restore, and an application owner who decides on configuration and releases. Sizing depends on agent count, ticket volume and attachment storage, so ask for a written sizing basis from whoever implements the system. The Znuny documentation describes the installation and administration steps.

How long does a migration from Freshservice to Znuny take?

No supplied duration applies to this migration, so any number a vendor gives you should be checked against the scope behind it. The main drivers are the volume of tickets, comments and attachments to move, how many configuration items and asset records need reconciliation, how much Freshservice workflow, SLA and approval logic must be rebuilt in Znuny's ITSM packages, the number of integrations to reconnect, and how many test cycles your change process requires. A parallel run period before cutover also adds time. Ask for a fixed-scope estimate in writing that lists deliverables, the data each migration step covers, testing criteria and the dates each milestone depends on. A scope that names these items can be compared across providers. A vague scope usually produces an open-ended invoice.

Can our own staff migrate from Freshservice to Znuny, or do we need outside help?

Your staff can run the migration if they have Linux, database and import skills, time for repeated test loads and a clear owner for data decisions. The difficult part is not moving files but mapping Freshservice's account data, delivered as an XML export to the administrator's registered email address, onto Znuny's ticket, configuration item and ITSM structures. Outside help adds the most value in that mapping, in scripted imports that can be rerun, in rebuilding SLA and change configuration, in hardening the server and in structured cutover testing. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

Can Znuny replace Freshservice's asset units or does it need a separate CMDB design?

Znuny does not use Freshservice's per-unit asset allowance model, so asset records are held in its CMDB instead, and no per-asset fee applies. The ITSM packages provide a CMDB of configuration items, with classes and relationships, plus CSV import and export of configuration items. That covers the structure, but you must design the classes, attributes and relationships yourself, and decide who keeps the data accurate. Znuny's documentation does not list discovery agents or software license tracking among its ITSM packages, so confirm those needs with the vendor or plan a separate inventory tool that feeds the CMDB. Before you start, map each asset type you track today to a Znuny class and agree on ownership and update rules for each one.

How DeployOpen helps you evaluate, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Freshservice vs Znuny, that means starting from the ITSM processes your team actually runs and testing whether Znuny's add-on packages cover them before any installation begins.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map your incident, problem, CMDB, service level and change processes to Znuny's ITSM packages and flag where a gap remains.
We confirm the target hosting, database and Perl and Apache stack against Znuny's documented prerequisites for your environment.

How we build

We install General Catalog and ITSM Core first, then the packages you chose, in your own cloud account or data center.
We configure priority, service criticality and CMDB classes, and test how the change management feature is used or replaced by a modeled process.
We run security testing on the deployed Znuny instance and prepare controls and evidence for your compliance assessments, which independent auditors then assess.

How we hand over

You receive written documentation of configuration, data model, service level reporting and the operating procedures we built.
We rehearse backups and restores with your team and document the recovery steps you will run yourselves.
We walk your administrators through upgrades between Znuny feature and LTS releases so ownership transfers cleanly.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainers can cover Znuny patch and release upgrades, Perl and database maintenance and periodic security testing.
Ask any provider, DeployOpen included, to confirm who answers production incidents and within what hours before you sign.

Freshservice vs Znuny