Is Zammad a Freshdesk alternative for your support team?
If your Freshdesk renewal, a data residency rule or a need to own your customer records is pushing you to look elsewhere, Zammad is a credible self-hosted replacement for Freshdesk's core ticketing, but only if your channel mix and workflow fit what it ships with. Zammad is AGPLv3 software that you can install in your own infrastructure, and its built-in Freshdesk migrator covers the ticket history move. Whether it covers your team depends on the specifics, not on a general verdict.
Freshdesk fits best when your team needs a managed SaaS help desk with minimal operating effort, a broad set of out-of-the-box channels and automations, and a vendor-run upgrade path. Zammad fits best when data control is the deciding requirement, when you have engineers or administrators who can run PostgreSQL, Redis, Elasticsearch and a reverse proxy, and when your email-centred workflow can be rebuilt in Zammad's triggers, macros and groups. Before committing, confirm which Freshdesk channels, automations and knowledge base features your agents use daily, and test each one on a non-production Zammad instance.
The decision turns on four things: your channel mix (email and web forms are Zammad's strongest ground, while live chat or messaging channels may need a separate tool), your data control obligations and who must be able to demonstrate them, your in-house operating capacity for patching and backups, and how much workflow must be rebuilt rather than migrated. Ask your Zammad partner or the Zammad team to confirm feature parity against your own list, and budget for rebuilding automations, since the migrator moves data, not your process logic.
Which option fits which support scenario
This table maps common support team situations to the platform that usually fits better, with the condition that makes the difference. Read each row against your own volumes, channels and admin capacity, since the answer changes when one condition is not true for you.
| Scenario | Better fit | Why |
|---|---|---|
| Email-first team with ticket queues and no need for live chat | Zammad | Zammad's ticket core covers email, web and phone intake in one queue, so the advantage holds as long as chat is not a daily channel. |
| Team that must keep ticket data in its own data center | Zammad | Self-hosting puts the database, attachments and search index under your control, which matters when residency rules rule out a vendor-hosted region. |
| Heavy live chat, WhatsApp and social channel volume | Freshdesk | Freshdesk bundles these channels in its own platform, while Zammad needs separate channel tooling, so the gap widens as channel count grows. |
| No spare admin capacity for patching, backups and upgrades | Freshdesk | A managed SaaS removes server operations, which matters if no one on staff can own PostgreSQL, Redis and Elasticsearch upkeep. |
| Workflows built on Freshdesk-specific automations and marketplace apps | Freshdesk | Rebuilding custom automations and integrations in Zammad is migration work, so this favors staying put until those rules are mapped and tested. |
| Team that wants historical tickets and macros loaded without rework | Zammad | Zammad's Freshdesk migrator is all or nothing on a new instance, so this fits teams that accept a clean cutover and a rebuild of unmapped settings. |
| Team that needs a supported self-hosted option with paid vendor support | Zammad | Zammad GmbH sells self-hosted support contracts, so confirm the tier and response terms in writing before relying on them. |
Which Freshdesk ticketing, channel and knowledge base features carry over to Zammad
Zammad covers the core of a ticketing workflow, but parity with Freshdesk is not established by the material available to us, so each feature you rely on needs a test. Zammad organizes work around ticket queues (views filtered by state, group, owner and other attributes), email channels that create and thread tickets from inbound and outbound mail, and triggers and scheduled automations that act on ticket changes. Map each Freshdesk rule and view you actually use to a Zammad equivalent on a fresh test instance, and record where the behavior differs. Confirm the exact trigger conditions, actions and channel options against the current Zammad release notes, since automation details change between releases.
Third-party login is one area where the design is clear: Zammad supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Confirm which identity provider your agents use, whether group or role mapping from that provider is needed, and how customer accounts are handled, because Freshdesk and Zammad may differ on how end users sign in. Knowledge base content is different. Zammad's knowledge base is a separate feature with its own structure, categories and publishing rules, so migrate and test article content, images, internal versus public visibility and search behavior before you commit. Do not assume Freshdesk solution articles, folders and portal branding map one to one.
Freshdesk's native chat, messaging channels and branded self-service portal are the areas most likely to need a different design. Plan for live chat, WhatsApp, social messaging and SMS as either a separate tool, such as Chatwoot, or as a decision on whether Zammad covers those channels at all. Ask your Zammad integrator or the vendor which channels are native, which need a plugin or external service, and what that service costs to run. Write down every Freshdesk feature your agents and customers touch each week, mark it as native, equivalent, partial or separate, and treat anything marked partial or separate as an open item for the pilot.
Freshdesk and Zammad capabilities side by side
This table compares Freshdesk's vendor-hosted help desk with self-hosted Zammad across licensing, hosting, data export, migration, identity, support and API access. Where a capability is confirmed in Zammad's documentation or Freshdesk's export guidance, the cell says so; where plan details need checking, the cell names what to ask each vendor. The main takeaway is that Zammad replaces a per-plan subscription with your own hosting, database, search and admin time, while Freshdesk's XML export is available on every plan.
| Capability | Freshdesk | Zammad |
|---|---|---|
| Licensing | Proprietary subscription sold by plan; confirm current terms with Freshdesk | GNU AGPLv3 open-source license; self-hosted use carries no license fee |
| Hosting model | Vendor-hosted SaaS; confirm available data center regions with Freshdesk | Self-hosted in your infrastructure, or hosted by Zammad GmbH in German data centers |
| Data export | Admins export tickets, solutions, forums and customers as XML on all plans | Content sits in your own PostgreSQL database, so you control backups and extracts |
| Migration in from Freshdesk | Source of the export; confirm any bulk extraction options with Freshdesk | Built-in Freshdesk migrator on a new instance only; all or nothing, one source per run |
| Channels, automation and knowledge base | Compare channels, automations and knowledge base features against your current plan | Confirm channel coverage, triggers and knowledge base features in the release you plan to run |
| Search and reporting infrastructure | Managed by the vendor; confirm reporting exports and limits | Elasticsearch is optional but recommended for faster search and reporting |
| Identity and login | Confirm supported single sign-on options and plan requirements with Freshdesk | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers |
| Support options | Support depends on plan tier; confirm response terms in your contract | Business, Enterprise and Corporation subscriptions at 2,999, 5,999 and 9,999 EUR per year (Zammad pricing page) |
| API access | Confirm API endpoints, rate limits and plan requirements with Freshdesk | Zammad API supports imports from other systems; confirm endpoints and token setup in its documentation |
How hosting and data control change the decision
Hosting decides who runs the servers, where the data sits and which controls you must evidence. The four cards cover location, operations, identity and compliance, and each one affects the others. Settle the hosting model first, then check identity and evidence against it.
Where your ticket data lives
Freshdesk stores tickets, attachments and customer records in the data center region assigned to your account, and you depend on Freshdesk for location and access controls. With Zammad, the answer depends on the hosting model you choose. Ask Freshdesk which regions are available to your account and whether a region change requires its support team. Then map every data category, including email attachments and exports, to a location you can prove. Get the storage location in writing before you sign, because a support tool holds personal data from every customer conversation.
Who runs the hosting stack
Each model moves different work to your team. Freshdesk runs its regional SaaS and handles upgrades. Zammad GmbH hosts Zammad in German data centers for a fee, and you still manage users, configuration and data requests. Self-hosting in your own or a provider's data center puts the application, PostgreSQL 15 or newer, Redis 7 or newer, the reverse proxy, backups and patching on your team. Elasticsearch is optional but strongly recommended for search. Compare each model on operations time as well as subscription fees.
Identity and login integration
Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Connecting it to your identity provider means agents sign in with the same accounts and multi-factor rules as the rest of your estate. You can remove a leaving agent's access from one identity provider. Check which login methods agents use today, how Freshdesk logins are configured, and how new agents are provisioned. Confirm the provisioning options for your Zammad version in its documentation before you plan the rollout.
Compliance evidence and obligations
Moving data changes which controls you must show. With Freshdesk, the vendor carries part of the hosting controls, and you still document access reviews, retention and data processing terms. Self-hosted Zammad moves platform control evidence onto your team, including access logs, backup restore tests, change records and data deletion procedures. Compliance evidence comes from independent auditors and certification bodies. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, and neither the software nor its vendor issues one for you.
What drives the cost of running Zammad versus Freshdesk
With Freshdesk, the recurring cost is the subscription itself, billed per agent on the plan you choose. Freshdesk hosts the application, databases, backups and upgrades, so your internal cost is mostly licensing plus the admin time spent configuring the account. Your plan tier, the number of agent seats and any add-on features you need will set the monthly figure, and the price list is on Freshdesk's own pricing page, which you should check for current terms.
- Recurring subscription: Per-agent fees repeat every billing period and rise as you add agents or move to a higher tier.
- Plan features: Knowledge base, automations, reporting and channel add-ons may sit in higher tiers, so the cost of your required feature set matters more than the base seat price.
- One-time setup: Configuring mailboxes, groups, automations and the knowledge base is internal admin time, and a partner engagement adds to it if you use one.
- Data export: Freshdesk's XML export is available on every plan, so a copy of your data costs admin time rather than an upgrade.
- Cost drivers: Seat count, plan tier, data residency choices and the number of channels you use are the main levers.
Ask Freshdesk for a written quote that lists every seat type and add-on your workflow needs, with the term length stated.
Self-hosted Zammad has no license fee, so the cost moves to the infrastructure and people who run it. You pay for servers or cloud instances, PostgreSQL, Redis, and where you use it, Elasticsearch and Memcached. Most of the spend is recurring hosting and staff time, with a one-time migration and build phase at the start. The costs below are components to price in your own environment, not a fixed estimate.
- One-time migration: Zammad's Freshdesk migrator works on a new instance only and is all or nothing, so you pay for preparation, test runs and cutover work, either in-house or through a partner.
- Recurring hosting: Compute, storage, network and load balancing, which grow with agent count, ticket volume and attachment size.
- Database and search: PostgreSQL, Redis and Elasticsearch add operating effort and disk, and Elasticsearch is optional but strongly recommended by Zammad.
- Backups and admin time: Backup storage, restore testing, upgrades and patching recur, and they are the largest hidden cost when staff are stretched.
- Cost drivers: Team size, availability targets, whether you run one node or several, and how much your staff already runs PostgreSQL and Redis.
Ask your team to price each component for your own environment, then compare it with the Freshdesk subscription over the same period.
A Zammad support subscription is an optional recurring fee on top of the self-hosted costs above. Zammad GmbH sells three self-hosted tiers, named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, as stated on Zammad's pricing page. The subscription does not replace your hosting or admin staff, so the total is the subscription plus everything in the previous tab.
- Recurring subscription: Business at 2,999 EUR, Enterprise at 5,999 EUR and Corporation at 9,999 EUR per year, each billed annually.
- What is included: Confirm with Zammad which response times, channels and escalation paths each tier covers before comparing them with internal support.
- Unchanged costs: Hosting, backups, database and search operation, and upgrades remain your responsibility.
- Cost drivers: The tier you pick, your need for vendor escalation, and how much in-house expertise you have to cover support gaps.
- Partner options: An implementation or managed support partner is a separate contract with its own scope and price.
Ask Zammad and any partner for a written quote for your own scope and deployment, and compare it with the Freshdesk total over the same term.
How a move from Freshdesk to Zammad runs
The sequence turns a Freshdesk tenant into a self-hosted Zammad instance with agreed channels, a verified data copy and a controlled email cutover, so support keeps running throughout.
Confirm scope and channel mix
Inventory every channel that feeds Freshdesk today, including email inboxes, web forms, phone logs, chat and any connected apps, along with the groups, agents, SLAs and automations that depend on them. Decide which channels Zammad will own and which, such as live chat, stay elsewhere. Ask DeployOpen or your own team to record the agreed scope in writing before any data moves. Done means a signed scope document listing each channel, its owner and its cutover method.
Export Freshdesk data as XML
A Freshdesk account administrator runs the export from Admin, Account, Account Details, Export data. The export covers tickets, solutions, forums and customers as XML and is available on every Freshdesk plan. Store the file in a restricted location and keep it as a fallback copy, since it is the record you can return to if the migration needs a rerun. Done means the export is received, checksummed and stored with a named owner, and the team confirms the ticket count matches Freshdesk's reporting.
Stand up a fresh Zammad instance
Install Zammad on infrastructure you control using the documented package, Docker Compose or Kubernetes Helm chart. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and a reverse proxy such as Nginx or Apache. Multi-instance deployments also need Memcached, and Elasticsearch is optional but strongly recommended for search and attachment content. Done means the instance passes health checks, backups run, and the platform team has tested a restore on a separate host.
Run the Freshdesk migrator on the new instance
Run Zammad's built-in Freshdesk migrator against the new instance only, since migrations are all or nothing, work only on a new instance and accept one source system per migration. Review the migration log for skipped records, attachments and user mapping. If a run fails, restore the instance to a clean state and rerun rather than patching partial data. Done means the migration completes with a reconciled count of tickets, customers and agents against the Freshdesk export.
Rebuild triggers, roles, mailboxes and knowledge base
Rebuild what the migrator does not carry over: triggers and automations, group and role permissions, email inboxes and their sending addresses, signatures, SLA-like escalation rules and the knowledge base articles. Connect third-party sign-in through SAML, OpenID Connect or the provider login your organization uses. Confirm each item against the scope document from the first step. Done means a checklist signed by the support lead shows every rebuilt item and its test result.
Test with real queues before cutover
Have a pilot group of agents work live tickets in staging queues for a period agreed in the scope, covering inbound email, web forms, replies, merges, escalations and reporting. Compare trigger behavior and notification delivery against Freshdesk, and log each defect with an owner. Done means the pilot group signs off, open defects are closed or accepted in writing, and the rollback path has been rehearsed.
Cut over email routing
Change MX or forwarding rules so inbound mail reaches Zammad, and update web form and integration endpoints to the new instance. Freeze new Freshdesk ticket creation for the channels being moved, then run a final delta export if you need records created during the window, noting that Zammad migrations do not support differential runs. Done means test messages arrive in Zammad, outbound replies send from the correct addresses, and the change record is approved.
Retire the Freshdesk tenant after retention
Keep the Freshdesk account and the XML export through the retention period your legal and compliance owners set, then cancel the subscription and confirm the vendor's data deletion steps in writing. Archive the final export under the same controls as other records. DeployOpen can plan and execute the full sequence under a fixed, written scope, so the engagement closes with documented evidence. Done means the retention record, deletion confirmation and final handover document are filed with the owner.
What the Freshdesk migrator carries over and what you rebuild
Plan the Freshdesk move around three documented constraints of Zammad's built-in migrator: it is all or nothing, it works only on a new instance, and each migration accepts one source system. A partial run cannot be resumed in place, so a failed attempt means starting again on a fresh instance rather than patching the existing one. Zammad's migration documentation is the place to confirm the current behavior before you schedule the cutover, because it sets the rules for every migration on the instance.
Treat the migrator as a starting point, not a finished helpdesk. Ticket history, customers and the other objects it imports still need checks against your own data. Before go-live, confirm field-level mapping for ticket states, priorities, groups, custom fields, tags and macros or triggers by running a test migration on a copy of your Freshdesk data. Rebuild or review automations, email addresses and inbound channels, agent roles, and any integrations, because these depend on your configuration rather than on the export. Note the items you cannot verify in the test and decide who signs off on them.
Keep Freshdesk's account export as a fallback copy, not as a loading format. The XML export of tickets, solutions, forums and customers, run from Admin, Account, Account Details, Export data, gives you a complete record that you control, but it needs conversion work before another helpdesk can load it. Ask whoever will own that work to estimate it during the test migration, and retain the export under your retention policy until support teams have confirmed the migrated history is complete.
Questions buyers ask before switching from Freshdesk to Zammad
What does it cost to switch from Freshdesk to self-hosted Zammad?
Zammad itself has no license fee when self-hosted, so the switch cost is the sum of hosting, migration work, admin time and any optional support contract. Hosting and admin time recur, while migration, mapping and rebuilding automations, macros and knowledge base content are mostly one-time. The Zammad pricing page lists 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, which you can weigh against your own staffing. Ask any implementation partner for a fixed-scope quote that separates infrastructure, migration, rebuild of Freshdesk features, testing, training and optional retainer support, and confirm which items recur each year.
How long does a Freshdesk to Zammad migration take?
The duration depends mostly on how much configuration you need to rebuild, not on the import itself. The main drivers are the number of agents, groups, SLA and routing rules, automations, macros, email channels, custom fields, integrations and the volume of history you want to keep. Zammad's migrator works only on a new instance and runs all or nothing, so you need time for a rehearsal on a test instance before cutover. No duration figure is supplied for this work, so ask for a timeline in the written scope and ask which milestones depend on your own approvals, such as email routing changes and user sign-off.
What does the switch require from our own team?
Your team owns the decisions that a migration cannot make for you. Expect to need a support operations lead to map Freshdesk groups, roles and escalation paths onto Zammad, an email administrator to move mailbox routing and DNS or forwarding rules, an identity contact for logins, and a few agents to test real tickets. Someone must also decide which closed tickets, attachments and customer records are kept and for how long. Ask the provider to list these owners and the review points in the scope so that approvals do not stall cutover.
Can an internal admin migrate Freshdesk to Zammad without outside help?
An experienced Zammad administrator can run the built-in migrator without outside help if the data set is small and the configuration is simple. Outside help is more useful when you have many groups, complex SLA and automation rules, custom integrations, strict audit requirements or a hosting environment that needs hardening and backups. Zammad's documentation covers package installation, Docker Compose and a Kubernetes Helm chart, but the hardening and operations work around them still needs skills your team must have or buy. Decide early which parts you will build internally and which you will contract out.
How does the Freshdesk migrator handle ticket history and attachments?
Zammad's migrator imports from Freshdesk as one all-or-nothing run into a new instance, and it accepts only one source system per migration. It does not support a differential migration, so changes made in Freshdesk after the import must be handled by a planned cutover window or a separate reconciliation step. Confirm in Zammad's migration documentation exactly which objects, comments, attachments and custom fields are carried over for your Freshdesk plan and data. Also ask for a sample migration report from a copy of your data, and keep the Freshdesk XML export from Admin, Account, Account Details, Export data as a fallback copy.
What support does Zammad offer for self-hosted installations?
Zammad sells support contracts for self-hosted installations named Business, Enterprise and Corporation, and these are separate from any hosting or implementation work. Support is a subscription with the software vendor, so it covers the Zammad application, while your infrastructure, backups, upgrades and integrations need their own owner or partner. Compare the response scope, hours and escalation paths in the Zammad pricing page with what you need during cutover, and confirm whether an optional contract is required for your rollout. Keep in mind that a support subscription does not replace your own on-call and recovery process.
Does Zammad support cover Kubernetes issues?
No. Zammad's documentation states that on Kubernetes, its support covers only the Zammad application, not Kubernetes-specific issues. Cluster design, ingress, storage classes, node scaling and the Helm release lifecycle remain your responsibility or your implementation partner's. Before choosing this deployment model, ask who will operate the cluster, how PostgreSQL, Redis, Memcached and Elasticsearch are run, and who is paged when a pod fails during business hours. Docker Compose or a single-host package install may suit a smaller team with simpler operations.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Freshdesk vs Zammad, we work from your actual ticket volumes, channels and workflows so the decision and the build rest on your requirements.
How we scope
- We map your Freshdesk ticket flows, channels, automations and knowledge base against Zammad features, marking gaps explicitly.
- We confirm hosting location, data residency needs and which cloud account, data center or air-gapped network will run Zammad.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Zammad with PostgreSQL, Redis and the reverse proxy in your environment, using the documented install path you choose.
- We plan the Freshdesk migration on a fresh instance, including a dry run and a review of what must be rebuilt by hand.
- We configure identity login, Elasticsearch search and any integrations, then test them against your agreed scope before go-live.
How we hand over
- We document the architecture, configuration, admin procedures and the rebuilt automations and macros your team will maintain.
- We deliver backup and restore procedures and keep the Freshdesk XML export as a fallback copy you can review.
- We walk your administrators through daily operation, upgrades and the evidence needed for internal or external assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover Zammad version upgrades, including security releases, and patching of the surrounding stack.
- Quotes follow from the written scope. Ask us to itemize one-time work against recurring support, and confirm with Zammad GmbH whether a self-hosted support contract is needed.
