Zendesk or Znuny: which fits a large support operation that wants its own servers
Zendesk fits teams that want a vendor-run cloud with no server operations, and Znuny fits teams that want a mature ticket system on their own infrastructure and can staff its operation. The decision usually starts with a per-agent price change at renewal, a rule that support records must stay in a named location, or a wish to avoid depending on one vendor's roadmap for a large agent base. Those triggers are real business drivers, but they only point toward Znuny if the organization can run the application tier, the database and the upgrade cycle as a standing function.
The first factor is staffing. Someone must own patching, Perl and Apache configuration, backups, capacity and the move between Znuny feature releases and the LTS line, and that cost recurs for as long as the system runs. The second is the database standard. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, so an existing database team and its licensing terms may settle the choice before the ticket system does. Confirm each version against the current Znuny README before you commit. The third is data location: a self-hosted Znuny keeps ticket content where you put it, but you must document backup copies and admin access as well.
The fourth factor is integrations. List every system that feeds or reads tickets today, including Zendesk apps, webhooks and the reporting pipeline, and confirm which ones have a Znuny equivalent or need custom work. The fifth is whether to buy professional services from Znuny GmbH in Berlin for installation, customization or support. Compare that quote against an internal team's time, and ask for the scope in writing so you can see what is covered after go-live.
Which option fits which scenario
This table matches common Zendesk Suite situations to whether Znuny or another path fits better. Read each row as a condition: the advantage applies only when that condition is true for your organization, so check the row against your own constraints before deciding.
| Scenario | Better fit | Why it matters |
|---|---|---|
| Data must stay on owned servers | Znuny | Znuny runs on your Linux servers or data centers with your own database, so ticket content stays under your control. Zendesk Suite data lives in Zendesk's cloud, so confirm whether its data location add-on meets your residency rule. |
| Existing MySQL, MariaDB, PostgreSQL or Oracle estate | Znuny | Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, so your DBA team can reuse known tooling and backup routines. Check the exact versions your estate runs against these minimums. |
| No in-house operations team | Zendesk Suite or a vendor-supported plan | Znuny is self-hosted, so patching, backups, Perl and Apache upkeep and availability fall to you or a partner. Without that capacity, budget for a Znuny GmbH services contract or stay with a hosted product. |
| Large agent count with strict change windows | Znuny with an LTS line | Znuny publishes a standard feature line (7.3.8 in October 2026) and an LTS line (6.5.26), letting you plan upgrades on a slower cadence. Confirm the support horizon of each line with Znuny before committing. |
| Heavy use of Zendesk Suite features such as triggers, macros and analytics | Zendesk Suite, or a Znuny build-out | Znuny can cover ticket queues, SLAs and reporting, but automation and reporting parity must be mapped and built, which adds project effort. Inventory your triggers and reports before estimating the move. |
| Need for vendor-run support with SLAs | Zendesk Suite or Znuny with a professional services contract | Zendesk provides vendor-run support as part of its subscription. Znuny offers professional services from Znuny GmbH in Berlin, so ask for the response commitments in writing rather than assuming them. |
| Team preferring a newer Zammad-style stack | Zammad | Zammad is AGPL-3.0 licensed, requires PostgreSQL 15 or newer and Redis 7 or newer, and includes a built-in Zendesk migrator. Choose it when a modern interface and a Zendesk import path matter more than the OTRS lineage. |
Where the data lives and who operates the stack
Zendesk Suite is a vendor-hosted service, so Zendesk operates the application, databases, patching and platform availability. Your team configures accounts, roles and integrations, and remains responsible for the data your agents enter.
- Hosting responsibility: Zendesk runs the platform. Your planning depends on its change schedule and incident communications rather than on your own maintenance windows.
- Data location: Get the storage location for your ticket and attachment data confirmed in writing for your plan. Zendesk's Data Center Location add-on applies to specific plans, so check its current terms during plan review.
- Backups and export: Zendesk does not give you a standing full copy. JSON, CSV and XML exports are available on Suite Growth and higher and Support Professional and higher, are not enabled by default, and the account owner must ask Zendesk support to turn them on. CSV omits comments and descriptions, and XML is capped at 500 MB and unavailable above 200,000 tickets.
- Identity: Single sign-on and role settings live in the admin console. Confirm which SSO options your plan includes before you connect your directory.
- Audit evidence: Request Zendesk's current compliance documentation and the contract terms that cover your data. Your auditor decides what evidence your assessment requires.
Check your export entitlement and enable it now, while the account is in good standing, because the setting is off by default.
Znuny is GPL-3.0 software that you install into a cloud account you already control. Linux with Debian or Red Hat is the preferred base. Your team or a DeployOpen engagement owns the virtual machines, database service, load balancing, patching and backups, and the cloud provider owns the physical facilities.
- Stack: Perl 5.16.0 or higher and Apache 2 with mod_perl2 are recommended. The database can be MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later, or Oracle 19c or later, so choose the engine your database team already supports.
- Backups: Back up the database, article storage and configuration together, and test restores on a schedule you set. Managed database snapshots help, but confirm they also capture attachments held on the file system.
- Patching: Znuny offers a standard release line and an LTS line. The znuny.org releases page lists 7.3.8 and LTS 6.5.26 as the latest releases in October 2026. Standard suits teams that want new features, while LTS suits teams that want longer planned upgrade cycles. Test each upgrade in staging first.
- Identity: Connect agent authentication to the identity provider you already run. Confirm the supported method for your chosen version in the Znuny documentation portal.
- Audit evidence: Keep change records, patch logs, restore test results and access reviews. DeployOpen prepares these controls and evidence, but independent auditors issue any report.
Confirm which Znuny line you will run before you design the backup and patch calendar, because that choice sets your upgrade rhythm.
On your own hardware, your team owns everything from the rack and hypervisor up. This gives full control over placement, network segmentation and data residency, and it adds capacity planning, hardware lifecycle and out-of-band access to your responsibilities.
- Hosting: Size the application hosts, database hosts, storage and redundancy for your ticket volume and attachment growth. If you want architecture and sizing work covered, ask DeployOpen for a written scope that defines deliverables and timelines.
- Redundancy: Place database replicas and file storage in separate failure domains. The Znuny documentation describes the components that need protection, so use it as the checklist for your design review.
- Backups: Keep at least one copy off the primary site. Agree retention periods and restore time targets with the business owner, and record them in the runbook.
- Identity: Connect Znuny to directory services on the internal network. Limit access to the admin interface to approved administrator networks, and log administrative sessions.
- Audit evidence: Document physical access, hypervisor and firmware patch records, network diagrams and application logs together. Auditors judge whether the controls work, and DeployOpen can prepare the controls and evidence for them.
Confirm which team owns hypervisor and firmware patching, because gaps at that layer are easy to miss during a help desk review.
In an air-gapped network, there is no direct route to the internet, so operating system packages, Perl modules, Znuny releases and database updates must cross an approved transfer process. Znuny's open-source code makes this workable, but every dependency has to be mirrored, verified and recorded.
- Hosting: Run the same Linux, Perl, Apache and database versions on isolated hosts. Build an offline installation set so that every host is installed from the same verified artifacts.
- Updates: Stage release packages, operating system packages and Perl modules through a controlled import with hash verification. Plan the import around the standard or LTS line you chose, and allow time for security review of each batch.
- Backups: Store encrypted backups on media that move through the same approved channel. Test restores inside the enclave, because a backup that cannot be restored there provides no recovery.
- Identity: Use the enclave's internal directory or local accounts. Confirm that the login method works without outbound calls to external services.
- Audit evidence: Log every media transfer, approval and import. Ask your assessor which records they expect for controls in an isolated environment before you design the process.
Ask your security team to approve the transfer procedure before you select the release line, because the procedure determines how often you can apply patches.
What running Znuny needs from your team
Running Znuny in your own data center or cloud account means your team owns the full stack: a Linux host, Perl, a web server, and a database. Znuny's README points to Debian or Red Hat as the preferred Linux distributions, requires Perl 5.16.0 or higher, and recommends Apache 2 with mod_perl2. Pick the database before anything else, because it sets your backup, replication and upgrade tooling. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. If your organization already runs one of these under support with tested backups, reusing it is usually the lower-risk choice. Confirm the exact minimum versions for your chosen distribution against the Znuny documentation before you build the base image.
Upgrades are where the release lines matter. Znuny publishes a standard feature line, currently 7.3.8 as listed on the releases page, and a separate LTS line, currently 6.5.26, both shown on the Znuny releases page. Standard releases bring new features and move faster, while the LTS line suits operations that want fewer, planned upgrades. The documentation portal keeps current feature documentation and latest LTS documentation separately, so your runbooks must name the line you run and the matching docs. Decide the line before go-live, since moving between lines is itself a planned upgrade with testing, customization review and rollback steps. Staff skills follow from that stack. You need Linux administration for patching and file permissions, Perl skills for custom modules and scripts, database administration for backups, replication and performance tuning, and web server tuning for mod_perl memory and worker limits. Hardware sizing depends on agent count, ticket volume, attachment size and integrations, so ask Znuny GmbH for a written sizing review and confirm the assumptions it uses. Ongoing staffing is the recurring cost, and it is worth estimating against those four skill areas before you compare total cost with Zendesk Suite.
Cost components on each side
Zendesk Suite and Znuny differ less in license fees than in who carries the recurring work. The cards below separate what Zendesk charges for from what a self-hosted Znuny deployment shifts onto your own budget and staff. Zendesk prices are not covered here, so take them from your own contract and renewal notice.
Zendesk Suite per-agent subscription
This is the recurring fee you pay Zendesk per agent on your Suite plan, and it scales with agent count, plan tier and add-ons such as the Data Center Location option. Check which plan your agents sit on, whether any agents are billed as light or full seats, and what each add-on costs at renewal. Ask your Zendesk account team to confirm the current per-agent rate and whether discounts expire at renewal. Your own contract is the only valid source for these figures.
Znuny software licence
Znuny is distributed under GNU GPL v3, so there is no per-agent or per-seat licence fee for the software itself. Costs shift to the components around it: hosting, database, staff and any support contract. Confirm with your legal team how GPL-3.0 applies to any custom modules or changes you plan to distribute, since that determines whether your own code must be shared. Keep the license text with your architecture records.
Infrastructure and database hosting
This is recurring cost for servers or cloud instances, storage, backups and the database. Znuny runs on Linux with Apache 2 and mod_perl2, and supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Your choice of database and your redundancy target drive this cost up or down, and Oracle licensing can add a separate line. Ask the implementer for a sizing estimate tied to your agent count and ticket volume.
Implementation and migration services
This is a one-time cost for planning, installation, configuration, data migration from Zendesk and testing. Most engagements are fixed-scope, so request a written scope with deliverables, assumptions about your Zendesk data, and the handling of attachments, comments and users. Ask which parts are included in the fixed fee and which are billed as change requests. Compare quotes on the same scope, not on headline totals.
Znuny GmbH professional services and support
Znuny GmbH in Berlin offers professional services, and this is a contracted cost you choose or skip. It covers support response, upgrade assistance and custom development on top of the free software. Ask for the service levels in writing, the named escalation path, and whether upgrades between the standard and LTS release lines are included. Confirm these terms directly with Znuny GmbH before budgeting.
Internal administration time
This is the recurring staff cost of running the helpdesk: patching, upgrades, backups, monitoring, user and queue administration, and incident response. It is often the largest line in a self-hosted budget and is easy to leave out. Estimate it by naming the role that owns the platform and the hours it takes each month, then check that estimate against your current Zendesk admin workload. Review it again at each planned upgrade.
What a move from Zendesk to Znuny involves
The sequence turns a Zendesk Suite account into a Znuny help desk on your own servers, with data verified, queues and SLAs mapped, and an upgrade path chosen before go-live. Each step closes with a check you can sign off.
Confirm scope and the data to move
Agree in writing which queues, mailboxes, channels, users, organizations, macros, triggers, SLAs and historical tickets must move, and which can stay in Zendesk as an archive. Confirm your Zendesk plan first, because data exports are available on Suite Growth and higher and Support Professional and higher, not on Team plans, and the account owner must ask Zendesk support to enable them. The output is a signed scope document that names the data owner for each object type.
Export tickets, users and organizations
Request the account export in JSON, which is the format to use for full fidelity, since CSV omits ticket comments and descriptions and XML is capped at 500 MB and unavailable above 200,000 tickets. For full ticket history with comments, the incremental export API is the route to confirm with your Zendesk contact. Store the raw exports in encrypted, access-controlled storage in your own environment. The check is a row count per object type that matches what Zendesk reports for the same period.
Build the Znuny environment and database
Provision Linux (Debian or Red Hat are the recommended distributions), Perl 5.16.0 or higher, and Apache 2 with mod_perl2, then choose a supported database: MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. Decide now between the standard feature line and the LTS line, because that choice shapes every later upgrade. Your administrators or Znuny GmbH install the system in your infrastructure. The output is a tested installation with backups running and restore already rehearsed.
Map queues, roles and SLAs
Translate Zendesk groups, ticket forms, triggers, automations and SLA targets into Znuny queues, agent roles, customer permissions and escalation rules. Mapping is a manual design exercise: no Zendesk-to-Znuny migrator appears in the supplied facts, so confirm with Znuny GmbH whether any tooling exists before you assume it. Record every Zendesk rule that has no direct equivalent and decide whether to rebuild it or drop it. The output is a signed mapping workbook approved by support leads.
Script, run and validate the data transfer
Write mapping and import scripts against Znuny's supported interfaces, test them on a copy of the exported data, and log every rejected record with its reason. Run repeated test loads until the rejects are understood and acceptable, then reconcile counts for tickets, articles, attachments, customers and agents against the Zendesk exports. Check a sample of tickets by hand for correct status, owner, priority and history. The output is a validation report with sign-off from the business owner of each queue.
Run parallel testing with real workflows
Operate Znuny alongside Zendesk for a trial period you set in advance, routing test tickets through each queue, escalation, email notification and reporting path. Agents work the same scenarios in both systems, and reporting teams compare dashboards against the figures they already trust. Track defects in a single list with an owner for each. The output is a closed defect list and an agreed go or no-go decision recorded in writing.
Cut over channels and integrations
Move inbound email addresses, web forms, phone and chat integrations, and any API consumers in a planned window, repointing each to Znuny and disabling the Zendesk equivalents. Confirm that outbound mail, SMTP credentials, and identity sources such as directory login work from the new server. Keep Zendesk in read-only or archived state for an agreed period so late messages can be traced. The check is a test message through every channel landing in the correct queue.
Plan the first upgrade on the chosen release line
Before the system goes live, write the upgrade procedure for your chosen line: the standard feature release or the LTS release, using the matching Znuny documentation for that version. Schedule the first upgrade in a staging copy, record the database backup and rollback steps, and confirm the support window with Znuny GmbH. The output is a documented, rehearsed upgrade runbook that your operations team owns.
Questions buyers ask before switching from Zendesk to Znuny
How much does a switch from Zendesk to Znuny cost?
Znuny itself is free under GPL-3.0, so the cost is the work around it: infrastructure, database licensing or hosting, the migration of tickets and users, configuration, integrations, testing and staff time. Who you pay matters. An internal team carries salaries and hours, a partner such as Znuny GmbH or DeployOpen is paid under a written scope, and the database is either free (MySQL, MariaDB, PostgreSQL) or licensed (Oracle). Recurring costs include servers, backups, patching and a support contract if you want one. Ask any provider for a quote that separates one-time migration, configuration and integration work from recurring hosting and support, and compare it with your current Zendesk Suite invoice over the same period.
How long does a Zendesk to Znuny migration take?
The timeline depends on the size of your ticket history, how many custom fields, triggers, macros and integrations you run, how many channels feed the desk, and how much testing your agents and compliance team need before cutover. Znuny has no Zendesk migrator in the supplied facts, so the data move is a custom export and import project, and that is usually the longest phase. Confirm the schedule in writing with whoever does the work, and ask for the phases, the sign-off points and the cutover plan, including how Zendesk stays available for reference during parallel running.
What does the work need from our own team?
Expect to name owners for the service catalog, queues, roles and SLAs, because those decisions are yours and not the software's. You will also need people who can approve the target architecture, the database choice and the hosting location, and an agent group that can test real ticket scenarios. Znuny runs on Linux with Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended, so your platform team must own the servers, patching and backups. Ask your implementation provider which of these tasks they take on and which stay with you.
Can our own team migrate and run Znuny without an outside partner?
Yes, if you have Linux, Perl and database administration skills and time to build and test the environment. Znuny is published as open source with agent, developer and Perl API documentation, so an experienced team can work from the source. The risks are concentrated in the data move, custom integrations and the upgrade process, where mistakes are costly. Many teams combine internal ownership with a fixed-scope partner for the hardest phases, or with Znuny GmbH's professional services. Decide based on the skills you already have and how many people can absorb ongoing maintenance.
How do upgrades differ between Znuny's standard and LTS release lines?
Znuny publishes a standard feature line and a separate LTS line, and the documentation portal keeps separate docs for each. Per the supplied releases page, the current versions in October 2026 are Znuny 7.3.8 on the feature line and Znuny LTS 6.5.26 on the LTS line. The standard line brings new features on a faster cadence, which suits teams that can test and upgrade often. The LTS line suits organizations that want fewer, more predictable upgrade windows and a longer period on one version. Check the support window for each line with Znuny before you choose, and plan upgrades against it.
Is there a Zendesk migrator for Znuny?
The supplied facts do not confirm a built-in Zendesk migrator for Znuny. Zammad is the option that ships one, and its migrator needs a full administrator API token and works only on a new instance. For Znuny, plan a custom export from Zendesk (see the Zendesk export guidance), a transformation step that maps ticket fields, states, groups and users to Znuny's model, and an import tested on a copy. Ask your provider to show how they will preserve ticket history, attachments and customer records, and how they will verify the result.
What compliance evidence must we produce ourselves?
A self-hosted helpdesk moves control ownership to you. You must document where ticket data is stored, who can access it, how access is granted and removed, how backups are tested, how changes and upgrades are approved, and how logs are kept. DeployOpen can help prepare systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and an independent auditor makes that determination. Ask your auditor early which evidence they expect, so the migration project collects it from day one.
When staying on Zendesk is the right call
Staying on Zendesk is the better choice when your organization has no realistic capacity to operate servers for a ticket system that carries customer-facing service levels. Znuny is self-hosted by design: your team or a partner must run the web tier with Apache and mod_perl2, the database, patching, backups and capacity planning. Before you decide, count the people who would hold that work, including an on-call rota that covers weekends, and confirm that the platform engineers you would assign can absorb it alongside their current roles. If that answer is no, a cloud-hosted Zendesk Suite subscription transfers the availability risk to the vendor, and that transfer has real value for a support operation that cannot tolerate an outage.
The second condition is a need for vendor-run support and a contractual availability commitment. Znuny GmbH sells professional services, and an external partner can take on operations, but that remains a contract you must negotiate, scope and renew. Zendesk support is built into the subscription, and its service terms are the reference point your procurement and risk teams already know. Ask Zendesk for the current support tiers and uptime terms in writing, then ask Znuny GmbH or your chosen partner for the equivalent response times and escalation paths, so the comparison rests on documents rather than assumptions. Third, check how deeply your agents and processes depend on Zendesk-specific apps, triggers and integrations. Every marketplace app, custom app or webhook built for Zendesk would need an equivalent in Znuny or a rebuild, and the migration cost grows with each one. Inventory the active integrations in your Zendesk admin area and mark which ones have no open-source counterpart. Finally, if your Zendesk contract ends soon, staying through renewal and planning the move for a later window is often the lower-risk path. Use the remaining term to run a pilot, document the dependencies and revisit the decision with real inventory data.
How DeployOpen helps evaluate and implement Znuny
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including Znuny on your servers, cloud accounts or air-gapped network. We start with a written scope that shows how Zendesk Suite workflows map onto Znuny before any build work begins.
How we scope
- Inventory Zendesk ticket volumes, queues, channels, SLAs, custom fields and integrations that Znuny must reproduce.
- Agree the database choice among MySQL, MariaDB, PostgreSQL or Oracle and the release line, standard or LTS, in writing.
- Define which data location, access and retention requirements the Znuny deployment must meet before implementation starts.
How we build
- Install Znuny on your chosen Linux distribution with Apache and mod_perl2 in your own environment.
- Configure queues, roles, notifications, ticket templates and email channels to match the agreed scope.
- Test ticket flows, integrations and data imports in a non-production environment before any cutover decision.
How we hand over
- Document the installed configuration, customizations, backup procedures and upgrade steps for your administrators.
- Deliver runbooks for moving between standard and LTS release lines so planned upgrades stay predictable.
- Walk your agents and administrators through the new system, with written handover material for later reference.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Keep backups and restore tests on a schedule agreed with your operations team.
- Confirm with your own team and Znuny GmbH which professional services you still need after handover.
