Can you replace Zoho Desk with self-hosted Zammad and keep Zoho CRM?
Yes, Zammad can replace Zoho Desk as the ticketing system while Zoho CRM stays where it is, but only if the link between tickets and CRM accounts is planned as its own piece of work. Zammad is published under the GNU Affero General Public License version 3, runs on infrastructure you control, and has no license fee for the software itself. The cost you carry is the server, the database, the search and caching layers, and the people who run them, plus any support subscription you choose to buy from Zammad. Zoho Desk's ticket queues, agent roles and customer records are the easy part to rebuild. What Zammad does not do for you is keep Zoho CRM and Zammad in sync, so the account link, the customer identifiers and the sync direction need an explicit design before cutover.
Before you commit, confirm four things with the Zammad documentation and in a proof of concept on your own environment. First, which of your Zoho Desk channels (email, web form, chat, phone or social) you need on day one, and whether each has an equivalent in Zammad. Second, how your Zoho Desk SLAs, business hours and escalation rules map to Zammad's service level and escalation settings, since the researched facts do not describe that mapping in detail. Third, how your knowledge base articles will move, because the knowledge base is a separate question from ticket migration. Fourth, how the CRM link will work. Zammad's documented migrators cover Freshdesk, Kayako, OTRS and Zendesk, and other systems use the Zammad API or custom development, so confirm with Zammad or your implementation partner how Zoho Desk data will be extracted and whether account identifiers from Zoho CRM can be carried into Zammad records. Ask for these answers in writing before you size the deployment.
Which Zoho Desk capabilities Zammad covers and where to confirm gaps
This table maps the Zoho Desk capabilities a support team usually depends on to Zammad features and to self-hosted complements. Read the coverage column first, since it separates what the Zammad documentation confirms from what you must verify in a test instance or with Zammad before committing. Rows marked custom work will shape the migration plan and the engineering effort.
| Zoho Desk capability | Zammad position | Self-hosted complement | Coverage status |
|---|---|---|---|
| Ticket channels (email, web form, chat) | Confirm which inbound channels your Zammad version ships and which need add-ons or custom work | Dedicated mail provider and web form hosted in your own infrastructure | Confirm with vendor |
| Email-to-ticket and threading | Confirm inbound mailbox setup, reply threading and attachment handling in a test instance | Self-hosted SMTP and IMAP service under your control | Confirm with vendor |
| SLAs and escalations | Confirm SLA policies, business hours and escalation rules against your current Zoho Desk setup | Monitoring alerts for breached response times, if SLAs need external reporting | Confirm with vendor |
| Automations and macros | Confirm trigger, scheduler and macro equivalents for each Zoho Desk automation you run today | Workflow automation platform from the workflow automation pillar for cross-system steps | Confirm with vendor |
| Knowledge base | Confirm whether the built-in knowledge base covers your article structure, permissions and public portal needs | Knowledge base and wiki platform from the knowledge base pillar | Confirm with vendor |
| Agent roles and reporting | Reporting features rely on Elasticsearch, which the documentation recommends; confirm the dashboards you need | Elasticsearch cluster sized for your ticket volume and attachment search | Confirmed by facts |
| Third-party login | Supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among other providers | Identity provider from the identity and SSO pillar | Confirmed by facts |
| Migration of Zoho Desk history | Built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, not Zoho Desk; other sources use the API or custom development | Export scripts from Zoho Desk and a staging import for validation | Requires custom work |
| Linking tickets to CRM accounts | No Zoho CRM connector is listed in the researched facts; links are built through the API using shared account identifiers | CRM hosted in your own infrastructure with a matching account key | Requires custom work |
Which open-source helpdesk fits a Zoho Desk team
Zammad fits most Zoho Desk teams that want ticket channels, SLAs and the knowledge base on their own servers. The cards below cover its stack, its optional components and install paths, then two self-hosted helpdesk alternatives to test for narrower needs. Confirm each platform's current feature set and support scope against your own channel and SLA requirements before you choose.
Zammad as the primary fit
Zammad is the primary fit for a Zoho Desk team that wants ticketing, channels and service-level handling on its own servers. It is licensed under the AGPLv3, so self-hosting carries no license fee, and the paid Business, Enterprise and Corporation subscriptions are optional vendor support. Before committing to a migration plan, test your email channels, SLA rules and knowledge base needs against Zammad in a trial environment.
Core stack: PostgreSQL, Redis and proxy
Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime websocket communication, and runs behind Nginx or Apache as a reverse proxy. Plan these as separate components that your team patches, backs up and monitors, because each has its own failure modes. Ask your platform team whether it already operates these versions, and confirm the exact support matrix for the Zammad release you plan to deploy before sizing hosts.
Elasticsearch and Memcached decisions
Elasticsearch is optional but strongly recommended, because Zammad uses it for faster search, reporting and searching the content of email attachments. Memcached is needed for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Decide the topology first: a single host keeps the stack smaller, while a clustered design adds Memcached and an Elasticsearch cluster that you must operate and back up.
Choose the install path early
Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers only the Zammad application, not Kubernetes-specific issues, so cluster operations stay with your platform team or another partner. Choose the path against your existing operations skills and backup tooling, and confirm the support scope in writing before the platform goes live.
FreeScout as a lighter option
FreeScout is a self-hosted shared inbox and helpdesk that teams sometimes evaluate when they want a simpler setup and an email-first workflow. It is a reasonable trial candidate for small support teams with straightforward channels. Confirm its SLA handling, knowledge base depth, CRM linking options and license terms directly with the project, since these features may differ from both Zoho Desk and Zammad and are outside this page's sources.
osTicket for ticket-only queues
osTicket is a long-running open-source ticketing system suited to teams whose main need is a ticket queue with departments and staff replies. Verify whether knowledge base content, automation and links to CRM accounts can be delivered with core features or will need custom development or plugins. Check the current release, PHP and database requirements, and license terms in the project's repository before comparing it with Zammad.
Running Zammad beside Zoho CRM during the transition
Keeping Zoho CRM as the system of record for accounts is the lowest-change option. Zoho CRM remains the owner of account and contact records, and Zammad holds only the support side: tickets, customers and their conversation history. The link between the two systems is a stable identifier that Zammad stores on each organization and customer record, usually the Zoho record ID, so that a ticket can always be traced back to the correct account even when names change.
- Stable external ID: Store the Zoho account ID on the Zammad organization record and the Zoho contact ID on the customer record, and never use the company name as the key.
- Contact matching rules: Define one rule for matching incoming email addresses to existing Zammad customers before the first sync, and record which address is primary for each contact.
- One-way sync: Pull account changes from Zoho into Zammad through the Zoho API on a schedule, so Zammad reflects the CRM without writing back to it.
- History stays in Zammad: Tickets created after cutover live only in Zammad, so decide whether a summary of each ticket is written back to the Zoho account record.
- Duplicate handling: Run a duplicate report on both sides before go-live and decide which record wins.
Before you commit, confirm with the integration developer which Zoho API limits apply to your edition and sync frequency.
When accounts move to a new self-hosted CRM, that CRM becomes the system of record and the identifiers have to be carried over during the migration rather than rebuilt afterwards. The Zoho backup provides CSV files that include the record IDs, so those IDs can be kept as a legacy field in the new CRM and written into Zammad. Ticket history then points to the new account through that legacy field, which lets support staff open a ticket and see the correct account without manual lookups.
- Legacy ID field: Create a field in the target CRM that holds the original Zoho ID for every account and contact, and load it during the first import.
- Two-way mapping table: Keep a table of old ID to new ID for each object type, and reuse it for Zammad, the CRM sync and any reporting.
- Contact matching after import: Match Zammad customers to CRM contacts on email address first, then on the legacy ID, and log every record that matches on neither.
- Ticket references: Make sure the new CRM account ID is stored on each Zammad organization so that the link survives later changes to the CRM.
- Backup retention: Keep the Zoho export in a restricted location until the mapping table has been reconciled.
Ask the migration team to confirm which Zoho modules and custom fields the export covers, because backups do not include email content or integration data.
A phased cutover runs Zoho Desk and Zammad side by side for a period, usually by queue, channel or team, so that support can move in stages. During this period two helpdesks receive customer contact, which makes identifier discipline the main risk. The safest pattern is to route each new conversation to one system only and to keep a single lookup for which system owns each customer, so that a returning customer is not answered from two places with two different histories.
- Routing table: Maintain a shared list of which mailboxes, channels and queues are live in Zammad, and update it at each phase.
- Customer ownership: Record in Zammad and in Zoho which system holds the open tickets for each account, and move open tickets with their history rather than closing them in one system and reopening them in the other.
- Email address changes: Where a customer writes from a new address, add it to the existing Zammad customer instead of creating a second record.
- Read-only history: Import closed Zoho Desk tickets into Zammad when the queue moves, or keep Zoho Desk read-only for lookups, and document which option applies.
- Parallel reporting: Report on both systems for the overlap period so that SLA figures are not split across two dashboards without a reconciliation.
Confirm with the Zoho administrator how long your Zoho Desk subscription and data remain available after the cutover, and whether exported ticket history can be retained.
Moving Zoho Desk tickets, SLAs and knowledge base into Zammad
This sequence moves open tickets, history, SLA rules, roles and knowledge base content from Zoho Desk into a self-hosted Zammad instance, with a cutover plan that keeps customer contact channels working.
Inventory channels, SLAs and roles
Your team lists every channel that feeds Zoho Desk (email addresses, web forms, chat, phone logs, social accounts or integrations), every SLA rule with its response and resolution targets, every business hours calendar, and every agent role, group and automation. Each item gets an owner and a target in Zammad. The step is done when the inventory is signed off by the support lead and someone from IT, and each channel has a named Zammad destination.
Confirm the import path for Zoho Desk data
Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, so Zoho Desk usually needs a different path. Confirm with Zammad or your implementation partner whether the Zammad API or custom development is the right route for your data, and ask how each Zoho Desk object (tickets, comments, attachments, contacts, organizations, tags and custom fields) maps to Zammad objects. The step is done when a written mapping and a chosen import method are approved, with any gaps listed.
Export tickets, attachments and contacts from Zoho Desk
Using the export options your Zoho Desk edition and admin rights provide, the team extracts tickets with their conversation history, attachments, contacts and organizations, and records which fields and date ranges are included. Confirm with Zoho which export formats and limits apply to your account before the run. The step is done when a complete export is stored in a restricted location, record counts are reconciled against Zoho Desk, and a sample of tickets with attachments has been checked by hand.
Load a test import into a staging Zammad
The implementation team loads the mapped export into a staging Zammad instance built on PostgreSQL and Redis, using the import method confirmed earlier. Agents then review a set of open, closed and merged tickets for correct states, owners, timestamps, attachments and customer links. Problems go back into the mapping and the load repeats until the sample is clean. The step is done when the support lead signs off the staging results in writing.
Rebuild SLAs, roles, groups and automations
Using the inventory from the first step, the team recreates SLA policies, business hours, groups, roles, permissions and trigger or macro equivalents in Zammad, and configures third-party login through your identity provider if you use one. Each SLA is tested with a sample ticket so escalation and breach behavior matches the Zoho Desk rules. The step is done when every SLA and role test case passes and the support lead accepts the configuration.
Migrate knowledge base articles
Knowledge base articles, categories, images and public or internal visibility settings are exported from Zoho Desk and recreated in Zammad's knowledge base, or in a separate knowledge base tool if your page list places it elsewhere. Links to articles from email templates, the website and macros are updated to the new URLs. The step is done when a content owner has reviewed each published article and a list of redirects or broken links has been resolved.
Cut over DNS, mail routing and live channels
During a planned window, the team switches support mailboxes and forwarding rules to Zammad, updates DNS records for the help portal and web forms, and reconnects chat or phone integrations. Zoho Desk stays read-only for a period so agents can look up history. Test emails are sent from outside and inside your network, and a monitored rollback plan is written before the switch. The step is done when inbound tests create tickets in Zammad, outbound replies arrive with correct headers, and the rollback plan has been rehearsed.
Link tickets back to CRM accounts
After support is live, the team matches Zammad organizations and customers to the accounts and contacts in your CRM using a shared key such as email domain or CRM record ID, and stores that link on each ticket. Confirm with your CRM team which identifier is stable across both systems before matching begins. The step is done when a sample of accounts shows the correct tickets in both systems and the unmatched records are listed for manual review.
What drives the cost of moving from Zoho Desk to Zammad
The Zammad software carries no license fee, so the cost of this move sits in the components around it: infrastructure, search and cache services, migration work, support and people. Each one has a different owner, a different timing and a different driver, and a quote should show them separately.
Software license and support tiers
Self-hosted Zammad is licensed under AGPLv3 and has no license fee. Zammad sells optional 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 Zammad's pricing page. These are recurring and optional, so ask each vendor or partner whether a support contract is needed for your uptime and response expectations, and check the scope of each tier before comparing it with a retainer.
Hosting and database infrastructure
Your recurring infrastructure bill covers application servers, a PostgreSQL 15 or newer database, a Redis 7 or newer instance for realtime updates, and a reverse proxy. Costs rise with agent count, attachment volume and backup retention. Ask for the server sizing, storage growth assumptions and whether backups and disaster recovery sit in the quote or in your own budget.
Search and cache services
Elasticsearch is optional but strongly recommended for faster search, reporting and searching attachment content. Multi-instance deployments such as containers or cluster nodes also need Memcached, while single installations can use the file system cache. Each service adds nodes to patch, monitor and back up, so decide early whether you need Elasticsearch in the first release and size it from ticket and attachment volume.
Migration and import work
Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, but Zoho Desk is not on that list. Expect custom development or API-based import for tickets, comments, attachments, agents, groups and SLA rules. Ask the implementer to show a field mapping, a test import of a sample of closed and open tickets, and how historical attachments and time stamps will be preserved. This is usually the largest one-time cost.
CRM account linking and integration
Linking tickets back to Zoho CRM accounts after the move requires a mapping of account identifiers and a decision on whether the link is a stored reference or a live sync. Each approach has a different build cost and maintenance load. Ask for the matching rules, the ownership of the integration code and a plan for changes to CRM records after cutover.
Internal admin time and training
Most of the recurring labor sits with your own administrators: patching the Zammad release line, managing Redis and Elasticsearch, reviewing security releases and maintaining SLA and channel configuration. Training support agents on the new interface and rebuilding macros and triggers also takes time. Ask the quote to state who performs each task, how many hours of training are included and what handover documentation is delivered.
Questions buyers ask before replacing Zoho Desk with Zammad
How much effort does moving from Zoho Desk to Zammad take?
The effort depends mostly on how many channels, custom fields, automations and historical tickets you need to carry over, not on Zammad's license, which is free for self-hosted use. The main drivers are the number of mailboxes and channels to reconfigure, how many SLA and trigger rules must be rebuilt by hand, the volume of ticket history to import, and how many agents need retraining. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through the Zammad API or custom development, so confirm early whether Zoho Desk is covered by a migrator or needs a custom import. Ask any implementation partner for a written scope that lists each of these items before agreeing a timeline.
Can our team run the Zoho Desk to Zammad move internally?
A team with Linux, PostgreSQL and reverse proxy experience can install Zammad from the package, Docker Compose or Helm chart documentation, but the cutover itself needs people who know your Zoho Desk configuration. Internally, you will need someone to stand up the stack, someone to map queues, SLAs and macros, and someone to test email and channel routing before go-live. Zammad's requirements call for PostgreSQL 15 or newer, Redis 7 or newer, and Nginx or Apache, and Elasticsearch is optional but strongly recommended for search and attachment content. Be honest about bandwidth: if the same people run daily support, the migration will compete with that work, so many teams bring in outside help for the cutover window.
What does the Zammad move need from IT and support staff?
IT owns the hosting, identity, mail and network work, while support leads own the process design and acceptance testing. On the IT side, expect to provision the database, cache, search and application tiers, configure outbound and inbound mail, set up TLS and the reverse proxy, and connect single sign-on. Zammad supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab sign-in, so confirm which of these your identity provider supports. Support staff need to review queues, SLA targets, escalation rules and the knowledge base content before import. Also plan for backups and upgrades, since Zammad published security releases for both the 6.5 and 7.x lines in October 2026, and you will need a routine for applying them.
Do Zoho CRM account links to tickets survive the move to Zammad?
Links survive only if you plan a shared key, because Zoho Desk and Zammad do not share an internal identifier. Export the Zoho CRM account IDs and the matching Zoho Desk contact or organization IDs, then store the CRM account ID on each Zammad organization or customer record, using a custom field or the API. After import, check a sample of tickets from each major account and confirm the link resolves to the correct CRM record. Whether the Zoho CRM side can read these links back depends on how your CRM is hosted and integrated, so confirm that with your CRM administrator and the Zammad API documentation before relying on it.
How are SLAs and knowledge base content moved from Zoho Desk?
SLA definitions and knowledge base articles move through different paths, and neither moves perfectly by default. Zammad provides SLA and escalation settings in its admin area, so the business hours, response and resolution targets have to be rebuilt and then tested against historical tickets. Knowledge base content is usually exported as articles or HTML and then mapped into the knowledge base you choose, which may be Zammad's own knowledge base or a separate wiki. Confirm with your support lead which articles, attachments, categories and permissions must survive, and whether embedded images and internal-only content need separate handling. Review a sample of articles after import, since formatting often breaks.
Does Zammad's Kubernetes support cover Kubernetes issues?
No, Zammad's support on Kubernetes covers only the Zammad application, not Kubernetes-specific problems. Zammad documents a Kubernetes Helm chart, but cluster design, networking, storage classes, ingress and node operations remain your responsibility or your platform team's. Multi-instance deployments such as containers or cluster nodes also need Memcached, while single installations can use the file system cache. Before choosing Kubernetes, confirm who will operate the cluster, how persistent volumes for attachments are backed up, and which party handles cluster-level incidents. Docker Compose is a simpler option for smaller teams, and the choice should follow your existing platform skills rather than the feature list alone.
Does Zammad have a license cost, and what does support add?
Self-hosted Zammad has no license fee under AGPLv3, but you still pay for hosting, staff time and any optional vendor support. Zammad's 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, according to that page. Those subscriptions are a separate purchase from the software and cover vendor support, not the migration itself. Your recurring costs will be infrastructure, backups, upgrades and administration time. Ask any implementation partner for a quote that separates one-time migration work from recurring operations and states which items are optional.
What should we confirm with DeployOpen before a Zoho Desk migration?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask how the written scope covers channel reconfiguration, SLA and trigger rebuild, data import, the CRM account linking method, identity integration, backup and upgrade routines, and acceptance testing. Ask which items are one-time and which are retained as ongoing support or upgrades. DeployOpen does not publish a price list, so a quote follows from the agreed scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence you need will come from independent auditors.
How Zammad's identity and hosting setup affects security reviews
A security review of a self-hosted Zammad deployment will start with how people sign in and which components hold the data. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Decide early which of these your identity provider can serve, because agents and administrators should authenticate through the same controlled path as the rest of your staff. Confirm with your identity team which protocol and claims mapping they want, and confirm the exact provider list in the Zammad third-party applications documentation for the version you plan to run.
The hosting stack is where most review questions land. Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime websocket communication, so both services need access control, encryption in transit where they cross network segments, and backup coverage of their own. Choose between Nginx and Apache as the reverse proxy based on the TLS termination, header and logging standards your security team already enforces, and document which layer terminates TLS. Multi-instance deployments such as containers or cluster nodes also need Memcached, so the number of moving parts grows with the architecture. Ask your architects to map every dependency to an owner before the review begins.
Patch cadence deserves a written plan. Zammad published security release 6.5.5 on 15 October 2026, in the same period as the 7.2.1 and 7.2.2 security releases, so fixes were issued in parallel for the 6.5 and 7.x lines. If you run an older line, confirm with Zammad which branch receives fixes and how long it stays supported, and set an internal window for applying security releases to the application, PostgreSQL and Redis. Reviewers will ask how quickly you can apply a security release, so a tested staging upgrade path is worth building before go-live.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted Zammad inside your own cloud account, data center or air-gapped network, so ticket data stays under your control. We start with a written scope covering channels, SLAs, knowledge base and CRM account links before any build work begins.
How we scope
- We inventory the Zoho Desk channels, mailboxes, SLA rules, macros and knowledge base articles you actually use.
- We define which Zoho CRM account fields must link to Zammad customers, and which history stays archived.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Zammad on your infrastructure with PostgreSQL, Redis and the reverse proxy your standards require.
- We configure groups, roles, SLAs, triggers, third-party login and the migration path agreed in scope.
- We run security testing and document the configuration, backups and access controls before cutover.
How we hand over
- You receive architecture, configuration and runbook documentation covering installation, upgrades and backups.
- We walk your admins through ticket rules, reporting and the CRM linking approach so your team can operate it.
- We prepare the evidence your internal or external auditors may request, though audit reports come from them, not us.
How we support
- Ongoing support, version upgrades and continuous security testing are available as retainers after handover.
- Security releases for Zammad should be scheduled into your change process, and we can plan and apply them under a retainer.
- Ask any provider to confirm response scope in writing, including coverage for the Zammad application and the platform beneath it.
