Freshdesk vs Znuny: which fits a large support team that wants self-hosting
A larger support team should choose between Freshdesk and Znuny on who will run the system, not on feature lists alone. Freshdesk fits teams that want a hosted service with per-agent plans, vendor-managed upgrades and little administration, and that accept the vendor's data center regions as the residency answer. Znuny fits teams that need the ticket system inside their own infrastructure, want to pick the database their DBAs already support, and need a clear release policy. Znuny is a continuation of the OTRS Community Edition 6.0.30 under GNU GPL v3, and it offers two release lines, the standard feature line and an LTS line, so you can choose between newer features and a longer-stable track. It runs on Linux, preferably Debian or Red Hat, and supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, and Oracle 19c or later.
Znuny's database choice matters more for a large team than for a small one, because it sets the backup, replication and patching routines your staff must already know. Ask Znuny GmbH in Berlin, which provides professional services, whether it will support the exact database version and release line you plan to run, and confirm that support terms apply to your environment. Check whether your Freshdesk contract, data residency terms or renewal price is the real driver, since a self-hosted Znuny install moves those costs to your own infrastructure and staff.
The decision turns on three questions. First, do you have Perl, Apache with mod_perl2, and database administrators available to operate the stack around the clock? Second, which database does your standards body approve, and does Znuny's supported list match it? Third, how much customization do your queues, agent roles and integrations require, and will that work be done in-house or through a services contract? If the answers point to a team that can run the platform and needs control over the data, Znuny is worth a pilot. If they point to minimal administration and fast onboarding, Freshdesk stays the simpler option.
Which option fits which scenario
This table matches common Freshdesk vs Znuny situations to the option that usually fits better and explains why. Read each row against your own constraints, since the right answer depends on data residency rules, your database estate, team capacity and how much of IT service management sits beside customer support.
| Scenario | Better fit | Reason |
|---|---|---|
| Regional data residency mandate | Depends on hosting choice | Freshdesk offers a choice of data center region at signup, but moving regions requires contacting support. Znuny can run in any data center you control, so confirm which regions your rules accept. |
| Existing Oracle or PostgreSQL estate | Znuny | Znuny supports MySQL, MariaDB, PostgreSQL and Oracle 19c or later, so it can sit on database platforms your DBAs already operate. Confirm version support with your database team before committing. |
| Small admin team | Freshdesk | Freshdesk is run by the vendor, so no one patches the platform. Znuny needs Linux, Perl, Apache and database administration in-house or through a support partner. |
| Heavy ITSM beyond customer support | Znuny | Znuny's README describes it for help desk and IT service management, which suits change and incident work alongside support. Confirm the specific ITSM processes you need against its documentation. |
| Need for vendor support contracts | Freshdesk | Freshdesk support is part of the subscription. For Znuny, ask Znuny GmbH in Berlin for professional services scope and terms in writing before you rely on them. |
| Preference for a standard or LTS release line | Znuny | Znuny publishes a standard feature line and a separate LTS line, letting you choose how often you take upgrades. Freshdesk upgrades are handled by the vendor on its own schedule. |
| Need to keep ticket data fully in your own servers | Znuny | Self-hosted Znuny keeps ticket records on infrastructure you control. Freshdesk data stays with the vendor in the region you selected. |
| Per-agent cost predictability over time | Freshdesk | Freshdesk costs are set by per-agent plans. Znuny has no license fee, but hosting, staff time and professional services recur, so compare them with your current invoices. |
How Znuny's release lines and database choice shape upkeep
Znuny ships on two release lines, and choosing between them is the first upkeep decision. The feature line is 7.3.x, with 7.3.8 among the latest releases listed on znuny.org in October 2026. The LTS line is 6.5.x, with 6.5.26 listed as its latest release. Znuny continues the OTRS Community Edition 6.0.30 codebase, which reached end of life in December 2020, so teams arriving from old OTRS installations should confirm the upgrade path from their current version before picking a line. Each line has its own documentation on the Znuny documentation portal, so administrators should read the set that matches the version they run, not the newest set by default.
The database choice drives more of the long-term cost than the release line does. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Each engine brings its own backup tooling, tuning skills and support model, so the choice should follow the skills your database team already has. Oracle is a commercial database and requires its own license from Oracle, which is a recurring cost separate from Znuny, which is free under GPL v3. Ask your Oracle account team and your Znuny partner to confirm which Oracle edition and options your deployment would need before you commit to that engine.
Before you finalize the choice, plan a restore test on the chosen engine. Confirm the backup method for the database and the file storage that holds attachments, the retention period your compliance team requires, and who on your staff can run a restore under pressure. Then decide whether upgrades will follow the LTS line for slower change or the feature line for newer functions, and write that decision into your change calendar. Professional services from Znuny GmbH in Berlin can cover upgrades and database work, and the quote should list each engine and release line in the written scope.
Where the data sits and who controls it
For a support team choosing between a SaaS help desk and a self-hosted one, the central question is who holds the data, where it is stored and who can change that arrangement. The cards below separate what Freshdesk and Znuny each let you decide, and what you still need to confirm before signing anything.
Data location and residency
Freshdesk lets customers choose a data center region at signup, and moving regions later goes through Freshdesk support. Znuny has no vendor-run region at all: the database, attachments and application run wherever you deploy them, whether in your own data center, a private cloud or an EU provider. Confirm with Freshdesk which regions are offered for your account type and whether any move is possible, and record the answer in your data processing documentation.
Hosting model and operator
With Znuny, your team or a chosen partner runs the web tier, the database and the mail integration, so patching, backups and access to the database host sit inside your change process. With Freshdesk, Freshdesk operates the platform and you control only tenant configuration. Decide who holds root and database credentials, who is on call, and whether that split matches your existing operating model.
Identity integration
Znuny can authenticate agents against your directory and enforce your own password and session policy, but this depends on the authentication modules you configure and test. Freshdesk agent sign-in is governed by its own account settings and the single sign-on options available on your plan. List every agent and customer identity source, confirm how each system connects and how leavers are removed, and test deprovisioning before go-live.
Audit trail and compliance evidence
DeployOpen prepares systems, controls and evidence for compliance assessments, including access reviews, configuration baselines and logging setup for the Znuny stack. Independent auditors and certification bodies decide whether that evidence meets a standard. For Freshdesk, the evidence you can produce depends on what the vendor provides under its own assurance reports, so request those documents directly from Freshdesk rather than assuming coverage.
Vendor dependence and exit
Znuny is distributed under GNU GPL v3, so the code you run can be kept, forked or moved to another provider without a license renewal. Its professional services come from Znuny GmbH, which is a separate choice you can make or not. Freshdesk exports tickets, solutions, forums and customers as XML on all plans, which you should test as a periodic copy and as a route out, since it does not reproduce the full running system.
What a move from Freshdesk to Znuny involves
This sequence takes your Freshdesk tickets, customers and knowledge into a self-hosted Znuny instance that you can validate against the live system before you switch over and retire Freshdesk. Znuny has no dedicated Freshdesk migrator in the facts we have, so the import route and the conversion work are decisions you confirm early.
Export Freshdesk data as XML
A Freshdesk account administrator opens Admin, Account, Account Details, Export data and requests the export of tickets, solutions, forums and customers as XML, which Freshdesk makes available on all plans. Confirm what the file contains against your own sample ticket, including attachments, notes and custom fields, before you rely on it. The step is done when you hold a complete, checksummed copy stored in an approved location and someone other than the exporter has checked the record counts.
Confirm the import route with Znuny
Znuny's documentation and README do not describe a dedicated Freshdesk migrator, so ask Znuny GmbH or your implementation partner whether an import tool, a custom script or a manual load is the right route for your volumes and fields. Ask for the expected conversion work, which typically covers mapping XML elements to Znuny objects such as tickets, articles, queues and customer records. The step is done when the route, its owner and its limits are written down and agreed.
Design the Znuny target environment
Choose the Znuny release line, either the feature line or the LTS line, and the database engine from MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later, as listed in the Znuny README. Decide the hosting model, the Linux distribution (Debian or Red Hat are preferred), and the Perl and Apache mod_perl2 versions. Document who in your organization or partner operates the stack, backups and patching. The step is done when the architecture decision record is approved by security, IT operations and the support leadership.
Build and harden the Znuny instance
Install Znuny in your own infrastructure, apply your baseline hardening for the operating system, web server, database and mail gateway, and configure authentication, role-based access and encrypted connections in line with your security policy. Set up backups and restore tests from day one, since Znuny's data is your responsibility once it is on your servers. The step is done when a restore from backup has been tested and the hardening checklist is signed off.
Map queues, roles, SLAs and customer data
Translate Freshdesk groups, agent roles, business hours, escalation rules, ticket statuses, priorities and custom fields into Znuny queues, agent groups, roles, service level agreements and dynamic fields. Decide how Freshdesk companies and contacts become Znuny customer users and customer companies, and how duplicates are merged. Keep a mapping table that shows every source field and its target. The step is done when the mapping has been reviewed by a support lead who signs off that no workflow is lost.
Load and reconcile the data
Run the conversion on a non-production copy, load the tickets, articles, attachments and customers, and reconcile counts, timestamps, owners and attachment integrity against the XML export. Investigate every mismatch and record the root cause, then repeat the load until the reconciliation report is clean for the agreed scope. The step is done when the reconciliation report is signed off and the load procedure is repeatable.
Run parallel validation
Let a pilot group of agents work real inbound requests in Znuny while Freshdesk remains live, test email channels, notifications, SLA timers, reporting and integrations, and capture defects in a single tracker. Confirm inbound mail routing and outbound sender reputation with your mail team before any customer-facing change. The step is done when the defect list has no open blockers and the support lead accepts the test results in writing.
Cut over and decommission Freshdesk
Freeze Freshdesk ticket creation, run a final delta load, switch inbound email and web forms to Znuny, and announce the change to agents and customers. Keep Freshdesk read-only for a period you agree in advance so that staff can look up history, and keep the final XML export as an archive copy. Retire Freshdesk only after the archive, retention and deletion obligations are documented. The step is done when all channels point to Znuny, the archive is verified, and the Freshdesk subscription end is confirmed with the vendor.
Questions buyers ask before choosing Znuny over Freshdesk
What does moving from Freshdesk to Znuny cost, and what drives that cost?
Znuny itself carries no license fee under GPL v3, so the cost sits in the components you pay for: infrastructure, database, migration engineering, configuration, testing, and ongoing administration. Infrastructure and database costs recur every year, while migration design, data conversion and go-live work are mostly one-time. The main drivers are the number of agents and ticket volume, the database engine you choose, how many channels and integrations must be rebuilt, and whether you need outside professional services from Znuny GmbH. Ask any provider for a quote built from a written scope that separates one-time and recurring lines.
How long does a Freshdesk to Znuny migration take?
The timing depends on what is being moved and how much must be rebuilt, not on a fixed rule. Freshdesk's account export delivers tickets, solutions, forums and customers as XML, so the conversion work and the rebuild of queues, automations, SLAs, email channels and agent roles usually set the schedule. Other drivers include the volume of historical tickets, the number of integrations, the testing cycles your change process requires, and the availability of your database and Linux administrators. Confirm a duration with a scoped plan that lists each workstream, its dependencies and its acceptance criteria before you commit to a go-live date.
Can our own team run Znuny without an outside partner?
Yes, many teams run Znuny in-house, but it works best when someone owns the platform as an operational service. The README recommends Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 with mod_perl2. Your team would handle patching, backups, restores, monitoring, Perl module management and upgrades between feature and LTS releases. Ask whether you have staff with that skill set and enough spare capacity to cover on-call periods. If the answer is uncertain, a retainer for ongoing support may be a better fit than a one-time build.
What skills and access does a self-hosted Znuny deployment require from our team?
The work needs four capabilities: a relational database administrator, a Linux administrator, Perl knowledge for customization and troubleshooting, and a change control process that tests every upgrade. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, so the choice of engine should match skills you already have and your backup standards. Your team also needs access to the production and test environments, a named owner for each integration, and documented procedures for backup, restore and rollback. Confirm these requirements in writing as part of the scope.
Do we need Znuny GmbH professional services to run Znuny?
No. Znuny is distributed under GNU GPL v3, so you can install, operate and modify it without buying a vendor contract. Znuny GmbH in Berlin offers professional services, and those can help with specific engineering, support or customization work. Whether you need them depends on your internal skills, the complexity of your workflows and how much risk you accept during operations. An implementation partner such as DeployOpen can also plan, integrate, harden, back up and document the platform in your own infrastructure. Ask each supplier to state which parts of the work they cover and which remain with your team.
How do we choose between the standard and LTS release lines?
Choose the LTS line when stability and a longer period between major changes matter more than the newest features, and choose the standard feature line when you need current functionality and can upgrade more often. At the time of writing, znuny.org lists Znuny 7.3.8 as the latest feature release and Znuny LTS 6.5.26 as the latest LTS release. The documentation portal keeps separate guides for each line, so confirm that your customizations, add-ons and database version are supported on the line you select. Write your upgrade policy, test environment requirements and rollback plan before choosing a line, because those decisions shape your operating cost.
What does Freshdesk's data center region choice change in a self-hosted Znuny setup?
With Freshdesk, you choose a data center region within the vendor's hosting options. With Znuny, you choose the location yourself, which means your own data center, an EU or other regional cloud account, or an air-gapped network. That choice affects data residency, backup location, disaster recovery design and who has administrative access to the servers. It also moves responsibility for availability and physical security to your side or to the infrastructure provider you select. Confirm the required residency rules with your compliance team before deciding where the database and attachments will live.
When staying on Freshdesk is the right call
Staying on Freshdesk is the better choice when your team cannot take on operating a database-backed ticket system. Znuny is a mature platform, but it runs on Linux with Perl, Apache 2 with mod_perl2 recommended, and one of MySQL, MariaDB, PostgreSQL or Oracle that you select and maintain. Someone must own patching, database backups and restore tests, schema upgrades between standard and LTS release lines, and performance tuning as ticket volume grows. If no engineer in your organization has capacity for that work, a per-agent SaaS plan moves those duties to the vendor, and the cost of that service is visible on one invoice.
Freshdesk also wins when speed to production matters more than control over the stack. A hosted account can be configured by support leads within days, while a Znuny deployment involves infrastructure, database sizing, mail and LDAP integration and a sign-off on hardening before agents log in. Before you decide, ask whether your go-live date depends on a fixed scope that a partner can deliver in writing, and compare that timeline with the time your own team would need. Professional services from Znuny GmbH and implementation partners are an option, but they add a one-time project cost that should be included in any comparison.
Finally, staying put is reasonable when the hosted plan already meets your requirements. Check your current plan against the controls your auditors or customers ask about, including data region choice, export rights and single sign-on. Freshdesk's account export in XML is available on every plan, so a future move remains possible if your position changes. Confirm your data residency and retention terms directly with Freshdesk, and revisit the decision when your renewal, headcount or regulatory scope changes.
How DeployOpen helps evaluate, implement or migrate to Znuny
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Znuny decision, we work from your current Freshdesk use, your database and hosting constraints, and the support model your team needs before anything is built.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We document your Freshdesk ticket volumes, channels, queues, automations and integrations so the written scope matches your real workflow.
- We confirm your chosen database engine, release line (standard or LTS) and hosting location as part of the scope, not after build.
How we build
- We install and configure Znuny on the Linux distribution, web server and database your organization approves, inside your own cloud or data center.
- We plan the Freshdesk export and conversion work, then test imports of tickets, customers and attachments in a non-production environment first.
- We set up agent roles, queues, notifications, authentication and backups, and run security testing against the deployed system before go-live.
How we hand over
- You receive documentation of the architecture, configuration, data mapping, backup and restore steps, and upgrade procedure.
- We walk your administrators through daily operation, queue and permission changes, and how to choose between the standard and LTS upgrade paths.
- We prepare the controls and evidence your internal team or independent auditors may need for a compliance assessment, without issuing any audit report ourselves.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover patching to new Znuny releases, backup verification and periodic security testing of the helpdesk.
- Ask us to confirm in writing which Znuny professional services, if any, you would still buy directly from Znuny GmbH alongside our work.
