Which open-source alternative to Zendesk fits your team
For customer and agent ticketing, Zammad is the open-source platform to evaluate first, and it can be self-hosted in your own infrastructure. GLPI is the complement to consider if you also need internal IT service management, asset inventory and configuration management. Most teams that replace Zendesk for external support only need Zammad, while teams whose help desk also serves employees, devices and change control should plan for both. Teams usually start looking for alternatives at a renewal, after a pricing or plan change, when a data residency rule applies, or when they want their ticket history under their own control. Zendesk's own export documentation shows why plan level matters for that last point: JSON, CSV and XML 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 switch exports on because they are not enabled by default. Those details are worth checking against your current contract before you plan a move, since they determine how much of your history you can take out without a support request. Before you choose, confirm three things in your own environment: which Zendesk plan you are on, whether exports are enabled for your account, and how many tickets you hold. Zendesk's help center notes that its CSV export omits ticket comments and descriptions, that XML exports are capped at 500 MB and unavailable above 200,000 tickets, and that JSON is recommended for larger accounts. Those limits shape the migration path more than any feature comparison does.
Open-source options that can replace Zendesk ticketing
Zendesk ticketing maps most directly to Zammad, a self-hosted helpdesk with a built-in Zendesk migrator. GLPI covers a different part of the job: ITIL incident handling and asset records for internal IT. The cards below set out what each option does, what it replaces, and where the trade-offs sit before you commit to a migration.
Zammad as the ticketing core
Zammad is a self-hosted helpdesk licensed under GNU AGPLv3, with its source code owned by the Zammad Foundation and developed with the community. It covers the agent ticketing, email channels and customer-facing workflow that Zendesk users depend on most. Check channel support, reporting and integrations against your own Zendesk configuration, since triggers, macros and third-party apps rarely map one to one. Confirm feature parity for each workflow you rely on.
Built-in Zendesk migrator
Zammad includes a migrator that imports from Zendesk, along with Freshdesk, Kayako and OTRS. Migration is all or nothing, works only on a new Zammad instance, and accepts one source system per run, so plan a clean target rather than an upgrade of a working install. Migrating from Zendesk requires an API token created by a full administrator, and user passwords are not migrated. Users will need to reset their passwords after cutover.
Support contracts for self-hosting
Zammad GmbH sells hosted plans in German data centers and support contracts for self-hosted installations, named Business, Enterprise and Corporation. Self-hosting moves hosting, patching, backups and upgrades to your team or your implementation partner, so the support tier is a decision about who answers when something breaks. Ask which tier covers the versions you run, response expectations, and what the contract excludes. Compare the tiers against your own on-call model.
Migration rate limits and plan dependency
The Zendesk migrator's throughput depends on the rate limits of your Zendesk plan, which means a large account can take longer to pull than a small one. Migrations are not differential, so changes made in Zendesk after the import must be re-entered or handled in a cutover window. Confirm your Zendesk plan limits with Zendesk before scheduling. Set a freeze window for ticket changes before the final run.
GLPI for internal IT service
GLPI is free asset and IT management software under GPL-3.0. It covers ITIL incident, problem, change and service level management, along with asset inventory, configuration management, a knowledge base and contract management. It fits internal IT and asset-driven service desks better than customer-facing support queues, so use it alongside Zammad rather than as a direct Zendesk swap. Decide early which team owns each queue.
How Zendesk capabilities map to Zammad and GLPI
This table maps the main Zendesk capabilities to Zammad, which covers customer-facing ticketing, and GLPI, which covers ITIL and asset work. Read each row for the covering option, then the gap column for what you must confirm or rebuild before cutover. The main takeaway is that Zammad replaces most of Zendesk's ticket workflow, while integrations, add-ons and export fidelity need explicit checks.
| Zendesk capability | Zammad (primary option) | Coverage notes and gaps |
|---|---|---|
| Ticket list and views | Zammad ticket overviews with filters and agent-defined views | Confirm that your saved views and macros-based filters have equivalents; rebuild them rather than expecting a direct import. |
| Multichannel email and web intake | Email channels, web form and chat channels in Zammad | Confirm each channel type you use (phone, messaging, social) against the current Zammad channel list before committing. |
| Agent workflows and automation | Triggers, schedules and macros in Zammad | Zendesk triggers and automations are not carried over by the migrator, so plan to recreate and test each one. |
| Knowledge base | Zammad knowledge base module | Confirm article import and multilingual needs; Zendesk Guide content is not covered by the Zammad migrator and must be moved separately. |
| Reporting and analytics | Zammad reporting and dashboards; GLPI reports for ITIL metrics | Zendesk dashboards must be rebuilt; confirm that the metrics you rely on are available or export raw data for an external tool. |
| Customer and organization records | Zammad users and organizations, migrated by the Zendesk migrator | User passwords are not migrated, so customers and agents must reset or re-authenticate after cutover. |
| API access | Zammad REST API with token authentication | Your Zendesk integrations need an audit; confirm each Zammad endpoint and token scope before switching clients. |
| Data export | Zammad export and the migrator reading Zendesk JSON, CSV or XML | Zendesk's CSV export omits ticket comments and descriptions, so use JSON or XML for full history; XML is capped at 500 MB and not available above 200,000 tickets. |
| ITSM and asset records (internal IT) | GLPI incident, problem, change, asset and knowledge base modules | GLPI is not a Zendesk replacement for customer support; use it only where internal IT ticketing and asset inventory are in scope. |
What you give up when leaving Zendesk and how to work around it
Moving from Zendesk to Zammad is mostly a data question. The built-in migrator and Zendesk's own exports cover the ticket history, but they come with limits on passwords, re-runs, plans and export format that shape the cutover plan. Each card below names one limit and the workaround that keeps the move on schedule.
User passwords do not migrate
Zammad's Zendesk migrator does not carry user passwords across, so every imported user must set or reset access on the new instance. Plan a communication step before cutover, and confirm how Zammad sends login links or invitations to imported agents and customers. Agents and customers who rely on single sign-on may need identity provider mapping configured before the first login, not after. Test a sample of accounts end to end in a staging instance first.
No differential migrations
The migrator does not support differential runs, so changes made in Zendesk after an import are not picked up by a second import. Treat the first import as a rehearsal, then schedule a single final import during a short freeze window. Agree with support leads which tickets are closed before the freeze, and record the cutover time so the team knows which data is current.
All-or-nothing imports on a new instance
A migration runs as a whole, and it works only on a new Zammad instance, not one already carrying live tickets. If an import fails partway, you restart the process rather than repair the failed part. Build the target instance from a clean install, keep the Zendesk account untouched until the new system is accepted, and keep a dated export of the source as a fallback.
One source system per migration
Each migration accepts one source system. Organizations that consolidate Zendesk with Freshdesk, a spreadsheet or a legacy help desk must bring those sources in through separate processes and reconcile duplicate customers and organizations by hand. Map the source inventory before scoping, and decide in advance which system wins when the same customer appears in more than one place.
Rate limits set by your Zendesk plan
Zendesk API rate limits depend on the plan, so a large account takes longer to pull than a small one. Ask Zendesk which limits apply to your plan and whether a higher tier changes the import window. Schedule the import during a low-traffic period and confirm the expected run time in a staging trial before the production cutover.
Exports need a plan and a support request
Zendesk's JSON, CSV and XML exports are not available on Team plans, and they are off by default. The account owner must ask Zendesk support to enable them, so start that request early. CSV also omits ticket comments and descriptions, and XML is capped at 500 MB and unavailable above 200,000 tickets. For large accounts, request JSON and keep an independent archive of the full conversation history.
Migrating from Zendesk to Zammad step by step
This sequence moves Zendesk ticket history, users and configuration into a self-hosted Zammad instance without interrupting agent work. Each stage ends with a check that tells you whether to continue, repeat the pilot or stop.
Inventory the Zendesk account and plan
The Zendesk account owner confirms the current plan, the number of tickets, users, groups, organizations, triggers, automations, macros, SLAs and custom fields, and records which integrations depend on the account. Plan tier matters here because JSON, CSV and XML exports are available on Suite Growth and higher and Support Professional and higher, not on Team plans. Ask Zendesk support to confirm the plan's API rate limits, since the Zammad migrator's speed depends on them. The step is done when you have a written inventory signed off by the support lead and the account owner.
Enable exports and create the API token
Exports are not enabled by default, so the account owner asks Zendesk support to turn them on. A full administrator then creates the API token that Zammad's Zendesk migrator needs, and you store it in your secrets manager rather than in a ticket or chat. Confirm that the token belongs to an account with full administrator rights, because the migrator will not work with a lower role. The step is done when a test API call from the migration host succeeds and the export option appears in the Zendesk admin interface.
Choose the export format and volume
Select JSON for accounts with more than 200,000 tickets, since Zendesk recommends it at that size. XML exports are capped at 500 MB and are unavailable above 200,000 tickets, and CSV omits ticket comments and descriptions, so neither is suitable as the sole record of history. Keep the export as an archive copy even if the migrator is your main path. The step is done when the export file is generated, its size and record count match the inventory, and it is stored in a location your security team has approved.
Map groups, roles, SLAs and fields
Working with the service owner and the team leads, map each Zendesk group to a Zammad group, each Zendesk role to a Zammad role, and each Zendesk SLA policy to Zammad's service level agreements. Decide which custom ticket fields are kept, renamed or retired, and which automations are rebuilt as Zammad triggers rather than copied. Record the mapping in a shared document that each owner signs. The step is done when every Zendesk object in the inventory has a target or an explicit retirement decision.
Run a pilot on a new Zammad instance
Provision a new self-hosted Zammad instance, because the built-in migrator works only on a new instance. Run the full migration against it using a copy of the Zendesk data, and do not expect to rerun it incrementally: migrations are all or nothing and differential migrations are not supported, so each rerun starts from a clean target. Check that tickets, attachments, organizations and agents appear correctly, and confirm that user passwords are not carried over, so users must reset them. The step is done when the pilot reconciliation shows matching ticket counts and the agents have reviewed a sample of migrated tickets.
Operate a parallel run
Keep Zendesk live while agents work in the pilot instance with a limited group of test users, and route test email to Zammad. Compare ticket routing, SLA timers, notifications and reporting between the two systems and log every difference with its owner. Because the migration cannot be applied as a delta, record any tickets created in Zendesk during the parallel period and handle them manually or in a planned final import. The step is done when open differences are resolved or accepted in writing by the service owner.
Cut over channels and freeze Zendesk
Plan a cutover window with the service owner, then repoint email addresses, web forms, integrations and any API clients to Zammad. Take a final export from Zendesk, freeze new ticket creation there, and confirm that all channels now deliver to Zammad. Post a notice to customers and agents describing the change and the password reset steps. The step is done when a test ticket on each channel arrives in Zammad and no new tickets are created in Zendesk.
Retain the archive and decommission Zendesk
Keep the final Zendesk export in encrypted storage for the retention period set by your legal and compliance teams, and record where it is held and who can access it. Cancel or downgrade the Zendesk subscription only after your records confirm that the retention obligation is covered, and ask Zendesk in writing how it handles account data after closure. Remove the stored API token and disable the integrations that pointed at Zendesk. The step is done when the archive location and retention owner are documented and the Zendesk account is closed or downgraded with written confirmation.
Which option fits by situation
If your customer support team runs on a Zendesk Suite or Support plan and wants the same queues, macros and agent workflow on open-source software, Zammad is the closest fit. It covers multichannel ticketing, agent collaboration and customer self-service, and it ships with a migrator that reads Zendesk data directly. Plan the move as a rebuild of your workflows, not a copy of Zendesk's configuration.
- Migration source: The built-in Zendesk migrator needs an API token created by a full administrator in Zendesk.
- Passwords: User passwords are not migrated, so customers and agents will need to set new credentials.
- Incremental moves: Differential migrations are not supported, so plan a cutover window rather than rolling changes across weeks.
- Rate limits: Migration speed depends on your Zendesk plan limits, so confirm them before you schedule the run.
- Integrations: Confirm which Zendesk apps and channels your team depends on and whether Zammad has an equivalent for each.
Before committing, confirm which Zendesk features your agents use daily and test them against a Zammad instance built from a sample of real tickets.
If the renewal price has moved up and you are considering a lower tier, the cost question is different. A cheaper Zendesk tier can remove the data exports you need for a migration, so check that before you downgrade. Self-hosting shifts cost from a subscription to infrastructure, staff time and support, and those costs recur in different ways.
- Export access: JSON, CSV and XML exports are available on Suite Growth and higher and Support Professional and higher, not on Team plans.
- Export setup: Exports are not enabled by default, so the account owner must ask Zendesk support to turn them on.
- Export format: CSV omits ticket comments and descriptions, so use JSON for a complete record.
- Size limits: XML exports are capped at 500 MB and are unavailable above 200,000 tickets, so use JSON for larger accounts.
- Support contract: Zammad GmbH sells support contracts named Business, Enterprise and Corporation, and you should compare them with your internal staffing before ruling out self-hosting.
Ask for your current export entitlement and ticket volume in writing before you compare any quote.
If a regulator, customer contract or internal policy requires that ticket data stay in a specific country or inside your own infrastructure, you have two different choices to separate. Zammad GmbH offers hosted plans in German data centers, which is a managed service run by the vendor. Self-hosting Zammad places the application and database in your own cloud account, data center or air-gapped network, which is a separate decision with its own operating model.
- Hosted SaaS: Zammad GmbH's hosted plans run in German data centers, so confirm the exact location against your residency rule.
- Self-hosting: You own the servers, database, backups and patching in your environment, and Zammad is licensed under GNU AGPLv3.
- Governance: The Zammad source code is owned by the Zammad Foundation, independent of Zammad GmbH, which can matter for long-term planning.
- Subprocessors: Ask the hosting provider for the list of subprocessors and any support access from outside the region.
- Backups: Confirm where backups and exports are stored, since exports often contain full customer records.
Confirm the hosting location, support access path and backup location in writing before you select a model.
If the Zendesk instance is used by an internal IT team for service requests and needs ITIL processes and asset tracking, Zammad is not the complete answer. GLPI is free asset and IT management software under GPL-3.0 that covers ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management. It is designed for IT operations rather than customer support queues.
- Scope: GLPI covers incident, problem, change and service level management with asset inventory and configuration management.
- Knowledge base and contracts: Contract management and a knowledge base are included, so you can consolidate tools.
- Edition and support: GLPI is edited and maintained by Teclib', which also runs GLPI Network, a hosted offering with a free 45-day trial.
- Version planning: GLPI 12.0.0 was published on October 7, 2026, so confirm the version and upgrade path before you build.
- Data mapping: Zendesk exports do not map directly to GLPI's ITIL objects, so plan how you will carry over ticket history and requesters.
Before you choose GLPI, list the ITIL processes you need and confirm each one against the current GLPI release notes.
Questions buyers ask before replacing Zendesk
How much effort does a Zendesk to Zammad migration take?
The effort depends mostly on how much history you keep, how many custom fields, triggers, macros and views you rebuild, and how many agents and integrations must be re-pointed. Zammad's built-in Zendesk migrator handles tickets and users, but its migrations are all or nothing and work only on a new instance, so you should plan a trial run on a copy before the cutover. The migrator documentation describes the steps, and the Zendesk-side preparation is short. Ask any implementation partner for a written breakdown of configuration rebuild, integration work, testing and cutover, since those items usually outweigh the data import itself.
Can an internal team migrate from Zendesk to Zammad without outside help?
A capable internal team can run a small migration, especially if the account is simple and the team has Linux, database and email operations experience. The harder parts are running a production-grade install, configuring authentication, backups, and monitoring, and rebuilding workflows that your agents depend on. Teams with compliance obligations often need documented controls and evidence, which is a separate workload from the import. Decide honestly whether you have staff who can own the system after go-live, because the open-source license is free but the operating work is not.
What access and details does a Zendesk migration require from us?
Zammad's Zendesk migration documentation says you need an API token created by a full administrator in Zendesk. Before starting, confirm which plan you are on, because rate limits depend on the Zendesk plan and affect how long the import runs. Also confirm whether your export settings allow data export, since Zendesk's JSON, CSV and XML exports are available only on Suite Growth and higher and Support Professional and higher, not on Team plans. Collect a list of agents, groups, custom fields, and integrations so the target configuration can be planned in advance.
Do passwords and attachments carry over from Zendesk to Zammad?
User passwords do not carry over in the Zammad migration, so every user must set up a new login on the Zammad side. Plan how users will authenticate afterwards, whether through local accounts, your existing identity provider or a password reset flow, and tell agents and customers before cutover. Attachments are a separate check: confirm in a test migration that files, inline images and linked content arrive intact, because export formats differ in what they include. Zendesk's CSV export omits ticket comments and descriptions, so do not rely on it as a complete copy.
How do Zendesk export size limits affect the replacement choice?
Export limits matter when you want an archive or a fallback copy outside Zendesk. According to Zendesk's help center, XML exports are capped at 500 MB and unavailable above 200,000 tickets, and JSON is recommended for accounts above that ticket count. If your account is large, plan on JSON and confirm the export works before you cancel anything. Also note that exports are not enabled by default: the account owner must ask Zendesk support to turn them on, so start that request early in the project.
Does Zammad require a differential sync during the cutover?
Zammad's Zendesk migration does not support differential migrations, so a second import will not pick up only the tickets created since the first run. Plan the cutover window so that Zendesk is frozen or redirected while the final import runs, or accept a manual reconciliation step for late tickets. Test this sequence on a copy first. Ask your team to define a freeze period for agents, a rollback point, and an owner for each step.
When should we ask an implementation partner to help?
Ask for a partner when the migration touches regulated data, many integrations, strict access controls, or evidence requirements for an audit you must pass. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, so independent auditors remain responsible for those. DeployOpen does not publish a price list, so request a quote based on a written scope.
How DeployOpen scopes, migrates and supports a Zendesk replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Zendesk replacement, that means working from a written scope, building Zammad in your cloud account, data center or air-gapped network, and handing over the documentation your team needs to run it.
How we scope
- Confirm which Zendesk plan and export method you have, since export availability depends on plan tier and an owner request to support.
- Inventory ticket volume, attachments, custom fields, macros, triggers, SLAs and integrations that must carry over or be rebuilt.
- Agree in writing which data is migrated, which is archived, and which workflows are rebuilt in Zammad before work starts.
How we build
- Deploy Zammad on infrastructure you control, with hardening, access control and network placement agreed in the scope.
- Run a trial migration on a new instance, since Zammad's built-in Zendesk migrator works only on a new instance and is all or nothing.
- Test imported tickets, users, roles and integrations against the agreed checklist, and document the results before cutover.
How we hand over
- Provide runbooks covering installation, configuration, user onboarding, backup and restore, and upgrade steps for your staff.
- Deliver evidence and control documentation that your compliance team or independent auditors can review, without us issuing any attestation.
- Walk your administrators through daily operations so your team can run the platform without depending on us for routine tasks.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, agreed separately from the initial scope.
- Confirm with Zammad GmbH whether a self-hosted support contract fits your needs, since its Business, Enterprise and Corporation tiers are separate from DeployOpen's services.
- Schedule periodic backup restore tests and upgrade reviews so your team knows the platform still works after changes.
