Freshdesk cost vs self-hosted Zammad: where the money actually goes
Self-hosted Zammad removes the per-agent subscription, but it does not remove cost. Zammad is licensed under the GNU Affero General Public License version 3 and carries no license fee, so the money you stop paying Freshdesk is replaced by recurring infrastructure, administrator time and, if you choose it, a vendor support contract. Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Those tiers are optional, and the page does not state what each tier includes beyond support, so confirm the scope with Zammad before you treat it as a required line item. Freshdesk prices are not part of the supplied facts, so take your current per-agent rate and add-ons from your own invoice and compare them against the components below. The recurring side of a self-hosted install includes servers or cloud instances for the Zammad application, PostgreSQL 15 or newer, and Redis 7 or newer for realtime websockets, plus a reverse proxy such as Nginx or Apache. Elasticsearch is optional but strongly recommended for search and attachment content, and Memcached is needed once you run multiple instances, such as containers or cluster nodes. Each of these adds hosting, backup and patching work. Your team also needs time for Zammad release upgrades, including the security releases published in parallel for the 6.5 and 7.x lines, and for backups of the database and attachments. Ask any implementation partner for a quote that splits one-time work (installation, migration, hardening, documentation) from recurring work (upgrades, monitoring, backup testing, support). The one-time cost is the migration itself. Zammad's built-in Freshdesk migrator is all or nothing, works only on a new instance and accepts one source per migration, so plan for a clean cutover and a fallback copy. Freshdesk's account export contains tickets, solutions, forums and customers as XML, which you should keep as an archive regardless. Your largest cost driver will be how much support configuration you must rebuild by hand, such as automations, roles, macros and channels. Build a short cost model with three columns: current Freshdesk spend, Zammad hosting and admin time, and optional Zammad support, then run it against your agent count and growth forecast.
Which cost components move when you leave Freshdesk for Zammad
This table sets each Freshdesk cost component against its self-hosted Zammad counterpart and marks whether it is one-time or recurring. Read the Zammad column as the costs you take on yourself, because the license fee disappears but hosting, migration and administration do not. The main takeaway is that the largest changes are recurring infrastructure and staff time, not the subscription line.
| Cost component | Freshdesk (subscription and managed hosting) | Self-hosted Zammad (your infrastructure) |
|---|---|---|
| Subscription or license | Recurring per-agent plan fee paid to Freshdesk, billed according to the plan you select | No license fee for the AGPL-3.0 software. Optional Business, Enterprise or Corporation support subscriptions are recurring: 2,999, 5,999 and 9,999 EUR per year (Zammad pricing page) |
| Infrastructure | Included in the subscription. Freshdesk runs the application and data centers, and you choose a region as described in the plan terms | Recurring. You pay for servers or cloud instances, PostgreSQL 15 or newer, Redis 7 or newer, a reverse proxy, and optionally Elasticsearch and Memcached for multi-instance deployments |
| Implementation and setup | Minimal. Account configuration, agent roles, channels and automations are set up in the admin console | One-time. Installation through packages, Docker Compose or the Kubernetes Helm chart, then configuring channels, mail, roles and automations. Effort depends on your existing support workflow |
| Data migration | Not applicable as a cost while you stay. Exporting data is available to account administrators on all plans as XML | One-time. Zammad's built-in Freshdesk migrator runs all or nothing on a fresh instance. Validation, reconciliation and rebuilding items it does not carry over are your effort |
| Support contracts | Included in the plan, with support tiers that vary by plan | Optional and recurring. Without a contract, support depends on community channels and your own staff. Ask Zammad which tier covers your incident response needs |
| Upgrades and patching | Performed by Freshdesk as part of the service | Recurring. You schedule minor releases and security releases across the lines Zammad publishes, test them, and apply them to your database, cache and search tiers |
| Backups and recovery | Freshdesk operates the service. Your own export remains a separate copy you choose to keep | Recurring. You design, run and test backups of PostgreSQL, attachments and configuration, and set the recovery objectives your organization requires |
| Internal skills and admin time | Administrators configure the portal. No server or database expertise is needed | Recurring. Requires staff who can run Linux, PostgreSQL, Redis, reverse proxies, certificates, mail routing and monitoring, or a partner who does this on contract |
What pushes the Zammad total cost up or down
Zammad has no license fee, so the cost of a self-hosted help desk moves with the load it carries and the people who run it. The drivers below connect your current Freshdesk footprint to the infrastructure, support and admin time you would take on.
Agent count and growth
Freshdesk bills per agent, so headcount is the number you already pay for. In Zammad, agent count changes the sizing of application and database capacity more gradually, and it changes the number of concurrent sessions and realtime connections the stack must hold. Ask how many agents will be active at peak and how many you expect in the next two budget cycles, not only today's seat count. Growth in agents should be modeled as a sizing input, not as a license line.
Ticket and attachment volume
Ticket history and attachments drive storage, backup size and restore time more than user count does. Attachments in particular grow quickly for teams that handle screenshots, logs or documents. Export a sample of your Freshdesk XML to measure average ticket size and yearly growth, then decide how long closed tickets must stay searchable and how long backups must be kept.
Channels and mailboxes
Each inbound email address, shared mailbox and connected channel adds configuration, monitoring and failure points. Migrated mailboxes must be re-created and tested, and every channel needs its own credentials and routing rules. Count shared inboxes and channels now, and note which ones depend on external services that your team must keep reachable.
Availability requirements
A help desk that goes down blocks support work and can break commitments to customers. Higher availability means redundant application nodes, a highly available PostgreSQL setup, a load balancer and tested failover, which together raise both infrastructure and engineering time. Define the outage window your support team can tolerate before pricing the environment, and ask any implementation partner to state which of these components is included in the scope.
Elasticsearch for search and attachments
Zammad documents Elasticsearch as optional but strongly recommended, because it speeds up search, supports reporting and indexes the content of email attachments. Running it adds a separate cluster with its own memory, storage, patching and backup needs, so it is a meaningful line in the total. Decide whether agents need attachment content search and reporting from day one, and size the node against your ticket and attachment volume.
Data residency and skills on your team
Hosting region determines whether you run Zammad in your own data center, a European cloud account, or with Zammad GmbH's hosting in Germany, which Zammad offers as a hosted plan. Region affects provider pricing and egress costs. Your existing platform engineers' experience with PostgreSQL, Redis, reverse proxies and container orchestration decides whether this work is absorbed internally or needs outside help, which should be stated in the written scope.
How the one-time migration work is priced
The largest one-time cost in this move is the migration itself, and it starts with a constraint that shapes everything else. Zammad's built-in migrator imports from Freshdesk, and it runs all or nothing: the import works only on a new Zammad instance, accepts one source system per migration, and does not run as a differential sync. Whoever does the work therefore needs a clean target environment built first, and any mistake found after import usually means rerunning the whole job on a fresh instance rather than patching records one by one. Check the exact procedure in the Zammad migration documentation before you estimate effort.
The work that drives cost falls into four parts. First, building the fresh Zammad instance with its database, cache, search and reverse proxy, which is an infrastructure task you pay for once. Second, validating imported data: sampling tickets, attachments, customer records, groups and agent accounts against the Freshdesk source, and signing off on the result. Third, rebuilding what does not carry over, such as automations, triggers, macros, SLA rules, mailbox routing and knowledge base content, which typically needs an experienced admin or a Zammad-savvy partner. Fourth, keeping Freshdesk's XML export from the account export screen as a fallback copy, so the source data survives until the cutover is accepted.
Ask the vendor or partner for a written list of the objects the migrator carries over in the specific Zammad release you will run, and test that list against a copy of your own Freshdesk export before you accept a quote. Ask who performs each validation step, how many rounds of re-import are included in the scope, and what happens if the import must be repeated. Any estimate that does not separate these four components, or that assumes everything carries over, should be questioned. Treat the migrated data as trustworthy only after your agents confirm the rebuilt workflows against live test tickets.
How to build the Freshdesk vs Zammad model with your own numbers
This sequence turns a Freshdesk renewal into a like-for-like cost model for self-hosted Zammad, built from your own invoices, quotes and timesheets, over a horizon your finance team sets.
Pull the current Freshdesk invoice
Your finance or procurement lead exports the last twelve months of Freshdesk invoices and the current order form, recording the plan name, the number of billed agents, any add-on modules, and the renewal date. Ask the account owner to confirm whether agent seats are billed by month or by year and whether any seats are unused. The step is done when you have one table that shows plan, seat count, add-ons and annual value, with each figure traced to an invoice line.
List agent and admin roles
The support operations lead lists every person who logs into Freshdesk, separating frontline agents, supervisors, administrators who manage automations and mailboxes, and light users such as reviewers. Compare this list with the seats on the invoice so that idle licenses are visible. The output is a role register with headcount per role, which later drives both the Zammad seat assumptions and the admin time estimate.
Price the hosting components
Your infrastructure team gets quotes or internal chargeback rates for each component a self-hosted Zammad needs: application servers, a PostgreSQL 15 or newer database, Redis 7 or newer for realtime websockets, and a reverse proxy such as Nginx or Apache. Mark Elasticsearch, which is optional but strongly recommended, and Memcached, which is needed only for multi-instance deployments such as containers or cluster nodes, as separate line items so they can be included or excluded. Confirm sizing with the vendor documentation and your own load. The check is a hosting table where every component has a unit cost and a source.
Add backup and monitoring costs
Your platform team prices the backup target for the database, attachments and configuration, and the monitoring that watches uptime, disk, queue health and certificate expiry. Include storage retention that matches your policy, not a default. Note whether these tools already exist in your estate, because shared tooling changes the marginal cost. The output is a line for backup storage and a line for monitoring, each with an owner and a source quote or internal rate.
Decide the support tier
Your leadership and the support lead decide whether to run Zammad with internal skills only or buy a Zammad support subscription. Zammad GmbH publishes Business, Enterprise and Corporation subscriptions for self-hosted installations, and the pricing page gives their annual list amounts, so use those figures as the reference point if you choose a tier. Record the decision as a yes or no for each tier, along with the reason, such as response expectations or staffing depth. Ask Zammad for a written quote if your terms differ from the public list.
Estimate monthly admin hours
Your Zammad administrator and the Freshdesk admin estimate hours per month for patching, upgrades, user and role changes, channel and mailbox maintenance, reporting, and vendor coordination. Base the figure on the last few months of timesheets or ticket logs rather than memory, and multiply by a loaded internal rate. Include the hours that a managed service or support contract would absorb, so the comparison is fair. The output is a monthly admin figure in hours and cost, with the assumptions written beside it.
Add migration and parallel-running effort
Your project lead estimates one-time work: preparing a fresh Zammad instance, running the Freshdesk migrator, which is all or nothing and works only on a new instance, rebuilding automations, testing, agent training, and a period when both systems run in parallel. Ask an implementation partner for a written scope and quote if you do not have the skills in-house. Keep one-time costs in a separate column from recurring costs so the model shows payback clearly. The check is a one-time cost total with each task assigned to a person or vendor.
Compare costs over your chosen horizon
Your finance team selects the comparison horizon and discount approach, then builds two cash flows: Freshdesk seat fees and add-ons on one side, and Zammad hosting, backup, monitoring, support tier, admin hours and one-time migration on the other. Run the model with at least one sensitivity case, such as a seat increase or a different support tier, to see which inputs move the result most. Review the output with the CISO or CIO before the renewal date. The step is complete when the model, its sources and its assumptions are signed off by finance and the service owner.
Freshdesk cost and Zammad effort questions buyers ask
Is self-hosting Zammad always cheaper than paying for Freshdesk?
No, not automatically. Zammad has no license fee, so the saving is the Freshdesk subscription minus the costs you take on: servers or cloud capacity, PostgreSQL, Redis, optional Elasticsearch and Memcached, backups, monitoring, patching, staff time and any support contract you choose. The result depends on your agent count, ticket volume, existing infrastructure skills and how much internal time you can assign. Build a three-year model that lists each component separately, then compare it with your current Freshdesk invoices and any add-ons you pay for today. Include one-time costs such as migration and rebuilding automations, which recur less often than hosting and administration.
How much admin time does a self-hosted Zammad instance need?
The time depends on drivers you can measure in your own environment rather than on a fixed figure. The main ones are how you deploy (package, Docker Compose or the Kubernetes Helm chart), whether you run Elasticsearch and Memcached, how many channels and mailboxes you connect, how many integrations and identity providers you configure, and how often your team applies releases. Zammad published security releases for both its 6.5 and 7.x lines in October 2026, so plan for a regular patch routine. Ask your own platform team to estimate operating hours for upgrades, backups, restore tests and on-call coverage, and check whether that work already sits in an existing operations rota.
Do I have to buy a Zammad support contract?
No. Support subscriptions are optional. Zammad GmbH sells support contracts for self-hosted installations named Business, Enterprise and Corporation, priced at 2,999 EUR, 5,999 EUR and 9,999 EUR per year respectively according to Zammad's pricing page. Without one, you rely on the public documentation, the community and your own staff or an implementation partner. A contract makes sense when your service levels require vendor-backed escalation or when you lack in-house Ruby, PostgreSQL or container skills. Compare the annual subscription with the cost of the hours your team would otherwise spend on troubleshooting, and confirm the current terms directly with Zammad before budgeting.
Can our own team migrate from Freshdesk to Zammad without outside help?
Possibly, if you have the skills and the time. Zammad includes a Freshdesk migrator, but it runs only on a new instance, works all or nothing, and accepts one source system per migration. Your team must install and harden the instance, configure channels, identity and roles, run a test import, check the results against your ticket data and then rebuild automations, macros, SLAs, knowledge base content and reporting. Items the migrator does not carry over need manual work. Assess whether your staff have done a comparable production cutover before. A fixed-scope engagement from DeployOpen can cover planning, implementation, testing and documentation, with the scope and deliverables agreed in writing before work starts.
How long does a Freshdesk to Zammad migration take?
No duration figure has been published for this migration, and the answer depends on scope. The main drivers are the number of agents, the volume and age of tickets and attachments, how many channels and mailboxes you run, how many automations and integrations must be rebuilt, your compliance evidence needs, and whether you run a parallel period. Each of these is measurable in your own Freshdesk account before you commit. Ask any implementation partner, including DeployOpen, for a written plan that breaks the work into phases with dependencies and acceptance criteria. Treat any date given without that breakdown as an estimate to challenge.
What does my team need to provide for the Zammad project?
You need named owners in five areas: a sponsor who approves scope and budget, a service desk lead who defines workflows and acceptance tests, an administrator who will run Zammad after go-live, a platform or infrastructure team that provides hosting and network access, and a security or identity contact who approves single sign-on and access rules. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, so confirm which provider you will use early. Also provide access to a test Freshdesk account, a sample export, and documentation of your current processes so the rebuild matches how agents actually work.
Does Freshdesk's XML export reduce the cost of moving to Zammad?
It helps as a safety copy, but it does not replace the migrator. Freshdesk account administrators can export tickets, solutions, forums and customers as XML from Admin, Account, Account Details, Export data on all plans. Keep that file as an archive for records and audit needs, and plan the conversion work if you ever need to load it into another helpdesk. Because the export is a separate artifact, budget for storage, retention rules and a restore test. Confirm with your compliance owner which fields and attachments must be retained, and avoid assuming the export alone will recreate workflows, permissions or reporting.
When the numbers favor staying on Freshdesk
A Freshdesk subscription can cost less overall than self-hosting Zammad when the team has no one who can run a Linux server, PostgreSQL, Redis and a reverse proxy, and no appetite to learn them. Zammad has no license fee, but the cost moves to people and infrastructure: someone must patch the operating system and database, back up the data, monitor the service and handle upgrades. For a very small support team, the hours spent on that work can outweigh a per-agent fee, especially if the only alternative is hiring or contracting for platform skills. This is illustrative, not a forecast for any particular team.
A vendor-hosted service also carries value that a subscription price does not show. Freshdesk runs the hosting, updates and availability work for the customer, and its plans include capabilities that a self-hosted team would have to plan, configure and test itself. If the organization has no requirement to keep support data inside its own network or a specific region, and no pressure from a renewal or a licensing change, that operational offload may justify the subscription. Teams should also weigh the cost of an outage in their queue, since that risk falls on them, not the vendor, when they self-host.
Freshdesk's price is not part of the information behind this page, so the comparison cannot be settled from published figures here. Ask Freshdesk for a written quote that lists the plan, the number of agents, add-ons, data region options and any support tier, then price the self-hosted side the same way: infrastructure, migration work, admin time and any Zammad support subscription, with the Zammad pricing page as the starting point for support tiers. Compare both over the same number of years and agree which items recur and which are one-time before deciding.
How DeployOpen scopes a fixed-price Zammad implementation
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Freshdesk to Zammad move, we start from a written scope that sets out what the cost model must cover, so the comparison rests on your actual hosting, migration and support decisions.
How we scope
- We agree the written scope before any work starts, covering hosting, migration and handover tasks.
- The scope lists which Freshdesk data is exported, who runs the export and where the copy is kept.
- We record which Zammad support tier, if any, your team needs, and the reasons for that choice.
- We ask you to confirm agent counts, mailbox volumes and attachment sizes so sizing reflects real use.
- Engagements are fixed-scope, and the scope is the basis for any quote we provide.
How we build
- We deploy Zammad in your environment using the package, Docker Compose or Helm options you select.
- We configure PostgreSQL, Redis, the reverse proxy and, where needed, Elasticsearch and Memcached.
- We set up third-party login through your identity provider, such as SAML or OpenID Connect, where your policy requires it.
- We run the Freshdesk migration on a fresh instance and check the results against the Freshdesk export.
- We document the rebuild list for automations, groups, roles and templates that the migrator does not carry over.
How we hand over
- We deliver a runbook covering installation, configuration, upgrades, backups and restore steps.
- We provide a cost worksheet that separates one-time migration effort from recurring hosting and support costs.
- We document the Freshdesk export copy and its retention location for your records.
- We walk your administrators through daily operations, user administration and ticket queue management.
- We record each control and evidence item your compliance team asked for, so readiness work is traceable.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover applying Zammad releases, including security releases, in your environment.
- We can run periodic security testing of the Zammad deployment and its integrations.
- Any retainer scope is agreed in writing, with its own deliverables and review points.
- Ask for a quote built from the written scope, with each cost component shown separately.
