Which open-source alternative to Freshdesk fits your support team
For customer support ticketing, Zammad is the main self-hosted option to evaluate against Freshdesk. GLPI fits only if IT service management is also in scope, such as internal IT incidents, change control, asset inventory and a configuration database alongside customer requests. If your renewal or pricing review is the trigger, decide early which of those two workloads you are actually moving, because that choice drives the platform, the migration plan and the staff who will own it.
Teams usually start looking elsewhere for a few recurring reasons: a renewal that forces a new commercial conversation, a change in pricing or packaging, a requirement to keep ticket data in a specific jurisdiction or on infrastructure the organization controls, or a growing concern about depending on one vendor's hosted platform for years of case history. Self-hosting addresses the residency and lock-in concerns directly, since the data sits in your cloud account or data center. It also moves operational duties to you, including upgrades, backups, access control and monitoring, so the trade-off should be weighed before the decision is made. Zammad is licensed under GNU AGPLv3 and its source code is owned by the Zammad Foundation, independent of Zammad GmbH, which is useful context when you assess long-term control of the software. Confirm the license obligations with your legal team if you plan to modify the code.
Before you commit, check three things in your own environment. First, confirm which Freshdesk data you need to keep, because Freshdesk's XML export from the account administration area covers tickets, solutions, forums and customers, and that scope will shape what you migrate. Second, list the integrations your agents rely on today, such as telephony, chat or internal systems, since none of them move with the data. Third, ask whether your support team needs ticketing only or a combined service desk. If the answer is ticketing only, Zammad is the starting point. If the answer includes IT service management, evaluate GLPI in the same pilot.
Open-source options that can replace Freshdesk ticketing
Freshdesk is a customer support ticketing product, so the replacement question starts with Zammad, which is built for agent-facing ticketing. GLPI covers a different part of the work, internal IT incidents and assets, and is useful mainly if your Freshdesk use extends into IT operations. The cards below set out what each option fits, what it costs to run, and what to check before you commit.
Zammad for customer support ticketing
Zammad is licensed under GNU AGPLv3 and its source code is owned by the Zammad Foundation, independent of Zammad GmbH, which develops it with the community. Its built-in migrator imports from Freshdesk, so a support team moving off Freshdesk has a direct path. Migrations are all or nothing and work only on a new instance, so plan a clean target rather than an in-place upgrade. Confirm that the migrator carries the attachments, custom fields and automation rules your team relies on before you retire the Freshdesk account.
Freshdesk XML export as a fallback
Freshdesk account administrators can export tickets, solutions, forums and customers as XML from Admin, Account, Account Details, Export data, on all plans. Use this file as the source of record and your independent copy, even if the Zammad migrator handles the import. Ask Freshdesk what the export does not include, and test a sample import into a staging Zammad instance before the cutover. Keep the export in your own storage, since it contains customer personal data.
Self-hosted or hosted Zammad with vendor support
You can run Zammad yourself in your own cloud account or data center, or use the hosted plans that Zammad GmbH runs in German data centers. Self-hosting shifts operational work to your team, including upgrades, backups, mail connectors and monitoring. Zammad GmbH sells support contracts for self-hosted installations named Business, Enterprise and Corporation. Ask each tier what response commitments, upgrade help and hardening guidance it includes, and compare them with an implementation partner's fixed scope.
Rebuilding automation and reporting
Ticket data often moves more easily than the workflow around it. Triggers, macros, SLAs, routing rules, and the reports your managers read usually need to be recreated in Zammad's own model. Inventory every Freshdesk automation before migration, mark which ones are still needed, and test each one with real ticket samples. Plan for this rebuild as a distinct workstream, because it is the most common source of surprises after go-live.
GLPI for internal IT incidents
GLPI is free asset and IT management software under GPL-3.0. It covers ITIL incident, problem, change and service level management, asset inventory, configuration management, a knowledge base and contract management. It suits internal IT teams that need an asset register next to their ticketing, and it is a weaker match for external customer support conversations. Its maintainer, Teclib', also runs GLPI Network, a hosted offering with a free 45-day trial.
Confirming fit before you commit
Before choosing, run a short proof of concept with a representative queue, your real mailbox routing and your reporting needs. Confirm channel support for chat, social and phone integrations you use today, because those connectors vary by product and version. Ask whether the migrated data includes Freshdesk ticket history with original timestamps and agent assignments. Record the answers in writing so the scope and cost follow from confirmed facts.
How Freshdesk capabilities map to Zammad and GLPI
This table compares the main Freshdesk customer support capabilities with Zammad, the self-hosted helpdesk this migration targets, and GLPI, which covers ITIL service management for internal IT. Read each cell as a starting point: Zammad's current documentation should confirm channels, SLA rules, automation conditions and reporting before you commit to a design.
| Freshdesk capability | Zammad | GLPI |
|---|---|---|
| Email-to-ticket | Email is a core channel for ticket creation and replies. Confirm inbound and outbound mailbox setup against current Zammad documentation. | Ticket creation by email is available, but customer support workflows are less central than in Zammad. Confirm mailbox collector setup. |
| Agent collaboration | Shared ticket views, internal notes and ticket assignment. Confirm group and role permissions for your team structure. | Assignment to users and groups with ITIL roles for requesters, assignees and observers. Confirm fit for non-IT support teams. |
| SLAs and escalations | SLA rules are supported. Confirm the exact conditions, calendars and escalation actions your plan needs in current documentation. | Service level management is covered under the ITIL scope. Confirm how targets map to your existing Freshdesk SLA policies. |
| Automations and triggers | Triggers and scheduled actions are supported. Confirm which conditions and actions match your Freshdesk automations, since these rarely convert one to one. | Business rules and automatic actions are available. Expect to rebuild most automations by hand. |
| Knowledge base and solutions | Knowledge base is available as a built-in module. Confirm public access, categories and migration of Freshdesk solution articles. | Knowledge base module covers internal articles. Public customer-facing portal use usually needs additional work. |
| Customer portal | Customers can view and reply to tickets through the web interface. Confirm branding and self-service options for your deployment. | Self-service portal exists for requesters. Confirm whether it meets external customer needs. |
| Reporting and dashboards | Built-in overviews and reporting. Confirm the metrics you rely on in Freshdesk reports and plan to recreate any missing ones. | Statistics and dashboards are available for tickets and assets. Confirm report exports and custom reporting needs. |
| Multichannel (chat, phone, social) | Channel support varies by edition and integration. Confirm chat, phone and social channels against current Zammad documentation before planning. | Not a multichannel contact center. Pair with a separate telephony or chat tool if needed. |
| API access | REST API is available for tickets, users and organizations. Confirm endpoints needed for integrations and rate limits for your hosting. | REST API is available for assets and tickets. Confirm coverage against your integration list. |
What you give up when leaving Freshdesk and how teams work around it
Freshdesk's XML export moves tickets, solutions, forums and customers, but a helpdesk also carries configuration that lives inside the admin console. The cards below cover what typically stays behind, how to inventory it before cutover, and the workarounds teams use to rebuild it in Zammad. Confirm each item against your own Freshdesk account, since the export contents are the part of the migration this page can describe with confidence.
Automations and ticket rules
Freshdesk automations route, prioritize and escalate tickets based on conditions set in the admin console. The XML export contains ticket records, not the rule definitions, so these do not arrive as working logic. Inventory every active rule before cutover and recreate each one as a Zammad trigger or an equivalent mechanism. Test escalations and any time-based behavior with sample tickets, because timing logic is easy to misconfigure and hard to spot in daily use.
Custom reports and dashboards
Reports and dashboards your team built in Freshdesk live in that product, so they do not move with the export. The export gives you the underlying ticket records, which you can parse to rebuild historical figures outside Zammad. Ask who owns each report, which fields it depends on, and whether metrics such as first response or resolution time can be reproduced from exported timestamps. Agree the baseline definitions before cutover so trend lines remain comparable.
Portal and widget configuration
The Freshdesk export covers tickets, solutions, forums and customers, but not the portal theme, widget placement or contact forms that surround that content. Those need to be recreated in Zammad's own configuration. Solution articles and forum posts arrive as content records, so review formatting, embedded images and internal links after import. Check that public URLs customers have bookmarked still resolve, or plan redirects for the ones that do not.
Third-party app integrations
Connections to chat, telephony, CRM and marketplace apps are configured inside Freshdesk and are not part of the data export. Inventory each one with its business owner, its data direction and the credentials it uses. For each, decide whether Zammad offers a suitable channel or integration, whether a connector must be built, or whether the integration can be retired. Confirm expected behavior with the owning team before you switch off the Freshdesk connection.
Rebuilding through the Zammad API
The Zammad API is the usual route for recreating objects the migrator does not carry, such as scripted group, role and ticket field setup, and for pulling ticket history into reporting. Create a dedicated API token with only the permissions the script needs, and keep setup scripts under version control so the rebuild is repeatable between staging and production. Confirm endpoint coverage for each object type against the Zammad documentation for your version, since not every object is exposed the same way.
Single source and cutover limits
Zammad's migrator runs all or nothing, works only on a new instance and accepts one source system per migration. If you are also consolidating a second helpdesk into the same Zammad, plan a separate run and a reconciliation step, since one import will not merge two sources. Stop writes in Freshdesk during the final export window and agree in advance who signs off the last delta before the switch.
How to migrate from Freshdesk to Zammad step by step
This sequence moves customer support from Freshdesk to a self-hosted Zammad instance in controlled stages, so each stage produces evidence that the next one can rely on. It ends with a verified cutover and a retired Freshdesk account.
Inventory agents, groups, SLAs and integrations
Your support operations lead and a Freshdesk administrator list every agent, group, role, business hour calendar, SLA policy, automation rule, email inbox and integration that feeds or reads from Freshdesk, such as chat, telephony, billing or the product's own help widgets. Record which items you intend to rebuild in Zammad and which you will retire. The step is complete when the list has an owner and a disposition for every line, signed off by the team that depends on each item.
Export account data as XML
A Freshdesk account administrator opens Admin, Account, Account Details, then Export data, and requests the XML export of tickets, solutions, forums and customers. Freshdesk offers this export on all plans. Store the archive in a restricted location, record its date and the account it came from, and confirm that the file opens and contains the expected ticket and customer counts. The export is your baseline for the migration and for any later reconciliation.
Map fields, states and roles to Zammad
Your support lead and the Zammad administrator compare Freshdesk ticket statuses, priorities, custom fields, agent roles and group structures against Zammad's object model, then write a mapping table that names the target for each one. Decide how to handle attachments, merged tickets, and customer records that appear under more than one email address. Confirm with Zammad's migration documentation which items the built-in migrator carries over and which need manual work. The mapping is complete when every Freshdesk field has a documented target or an agreed reason to drop it.
Run a pilot on a new Zammad instance
Your platform team provisions a new, self-hosted Zammad instance in your own environment and runs the built-in Freshdesk migrator against a copy of the export. The migrator is all or nothing, works only on a new instance and accepts one source system per migration, so the pilot must use a fresh instance rather than a live one. Support agents then test sample tickets, customer lookups, SLA timers, notifications and reporting. The pilot is complete when the test cases you wrote in step one pass and the team signs off on the results.
Rebuild configuration and integrations
Your Zammad administrator recreates the items the migrator does not carry across, such as triggers, schedules, email channels, SLA rules, macros and integrations with chat or telephony systems. The DeployOpen team, or your own engineers, documents each rebuilt item against the disposition list from step one. Confirm the result with a second person who did not build it. The step is complete when every item marked for rebuild has a tested replacement and a recorded owner.
Operate Zammad and Freshdesk in parallel
For a defined period agreed with your support leadership, new inbound requests go to Zammad while Freshdesk stays available for existing conversations and reference. Agents work in both systems and log discrepancies in a shared list. Your team compares ticket volumes, response handling and SLA reporting between the two systems each day. The parallel run is complete when discrepancies are resolved and leadership agrees that Zammad handles production work reliably.
Cut over email routing and DNS
Your network and email administrators switch inbound support addresses, forwarding rules and any web form endpoints from Freshdesk to the Zammad instance. The team runs a final incremental import of any tickets created after the original export, then freezes Freshdesk for new work. Test each channel by sending a message from outside your organization and confirming it appears in Zammad. Cutover is complete when every support channel reaches Zammad and a documented rollback plan has been tested.
Decommission Freshdesk and retain records
After cutover is stable, your compliance lead confirms the retention requirements for historical tickets and customer data, and the administrator stores the final XML export in an approved archive. Then the team cancels the Freshdesk subscription, removes integrations and revokes agent access, and confirms the vendor's data deletion steps in writing. The step is complete when the archive is verified, access is removed and the contract is closed with a written confirmation from the vendor.
Which option fits your support situation
If your main driver is where customer records live, self-hosted Zammad moves the ticket store into infrastructure you choose, such as your own data center, a private cloud account or an air-gapped segment. Zammad is licensed under GNU AGPLv3 and its source code is owned by the Zammad Foundation, so you can run it without a vendor-hosted tenant. Your team, or a partner such as DeployOpen, then owns hardening, backups, patching and access control.
- Hosting location: You decide the region, network segment and storage encryption, and you document them for your data protection assessment.
- Vendor access: Confirm what remote access, if any, your support contract requires, because Zammad GmbH's support options for self-hosted installations are separate from hosted plans.
- Backups and restore: Define retention, off-site copies and a tested restore procedure, since none of this comes with a hosted service.
- Integrations: Map every connector that exports ticket data, including email gateways and chat tools, so no copy leaves your boundary by accident.
- Migration scope: Freshdesk's XML export has to be imported into a new Zammad instance, and the migrator works only on a new instance and is all or nothing.
Before committing, confirm with your legal and security teams which data categories may leave the organization and which must stay inside the self-hosted boundary.
If the driver is subscription cost, compare the Freshdesk renewal against the full cost of running Zammad yourself. Self-hosting removes per-agent licensing but replaces it with infrastructure, administration, upgrades and, if you want one, a vendor support contract. The software itself is free to use, so the comparison depends on labor and hosting, not on a license fee.
- Recurring costs: Hosting, storage, monitoring, backups, and the staff time spent on upgrades and security patches recur every year.
- One-time costs: Migration planning, data mapping, template rebuilding and user training are paid once, mostly as project effort.
- Support contract: Zammad GmbH sells Business, Enterprise and Corporation support contracts for self-hosted installations, so ask whether you need one and what response terms it provides.
- Hosted alternative: Zammad's hosted plans run in German data centers, which may cost less to operate than your own platform, so price both before deciding.
- Quote request: Ask any implementation partner for a fixed-scope quote with written deliverables, and ask Zammad GmbH for current pricing directly, since no price is confirmed here.
Build a three-year total cost model with your finance team, using your own agent count and ticket volume, before comparing it with the Freshdesk renewal.
If your support workflows depend on custom logic, Zammad is worth testing early because its source is open and it exposes an API for ticket, user and organization data. Customization is possible, but how deep it can go, and how it survives upgrades, must be confirmed against the version you plan to run. Treat every custom change as code that needs review, testing and an upgrade path.
- API access: Confirm the endpoints and authentication methods your integrations need, such as ticket creation, automation triggers and reporting.
- Extension language: Zammad is built with a Ruby-based stack, so confirm with your engineers how extensions are written, packaged and tested before you promise custom features.
- Upgrade impact: Record every custom change, because each Zammad upgrade can affect them and needs regression testing.
- Freshdesk features: Map Freshdesk-specific automations, custom fields and scheduled rules, since not all of them will have a one-to-one equivalent.
- Reporting: Check whether the reports your managers use can be rebuilt from the data Zammad exposes.
Ask your Zammad contact or the project documentation to confirm each customization you need, and run a proof of concept on a copy of your Freshdesk export before you design around it.
If the same team also handles employee IT requests, asset inventory and change control, GLPI may fit better alongside Zammad, or instead of it. GLPI is free software under GPL-3.0 and covers ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management. Customer-facing ticketing and internal IT service management are separate jobs, so the split between the two tools should be decided deliberately.
- Two-tool model: Keep Zammad for external customer tickets and use GLPI for internal incidents, assets and change records, with a documented handoff between them.
- Single-tool model: Use GLPI for both only if your customer support volume and workflow needs are modest, and test that fit with real queues.
- Asset data: GLPI's inventory and configuration management can replace spreadsheets, but the initial data load is a project in its own right.
- Vendor and edition: GLPI is edited by Teclib', which also runs a hosted offering, so confirm which support options your team needs.
- Version: GLPI 12.0.0 was published on October 7, 2026, so confirm the release you install and its upgrade notes.
Define who owns each tool and each data set before migration begins, because unclear ownership is the most common cause of duplicate tickets.
Questions buyers ask before moving off Freshdesk
How long does a Freshdesk to Zammad migration take?
No duration is fixed by the migration tooling itself, so the timeline depends on the size and shape of your Freshdesk data and on how much rebuilding your team needs to do. The main drivers are the volume of tickets and attachments in the XML export, how many agents, groups, roles and SLA rules must be recreated by hand, how many integrations and automations must be rebuilt, and how much cutover testing your support operation requires. Because Zammad's built-in migrator is all or nothing and runs only on a new instance, plan a dry run on a staging system before the cutover date. Ask any partner for a written scope that lists each of these items and the deliverables that close them out.
Can our own team migrate from Freshdesk to Zammad without a partner?
Yes, if your team has the skills and time to run a self-hosted Zammad instance, use the built-in migrator and rebuild the operational configuration by hand. The migrator is documented by Zammad, and Freshdesk administrators can export their account as XML from the Admin area on all plans. What is harder to judge in advance is the rebuild work: groups, roles, SLAs, email channels, macros, triggers and integrations all need to be checked against how your support team actually works. Many organizations split the work, keeping the business rules and agent training in-house while bringing in outside help for hosting, hardening, backup and cutover. Decide which parts you can own before you commit to a timeline.
What does the work require from our internal team?
The work needs named people from support operations, IT or platform engineering, and security or compliance. Support operations owns the decisions about queues, categories, SLAs, macros and what an agent sees on screen. Platform or IT engineers own the server, database, storage, email routing, backups and upgrade process in your own infrastructure. Security or compliance reviews access control, data retention, encryption and how customer personal data is handled during the export and import. Someone must also sign off on the test results and the cutover plan. Confirm these roles in the written scope, because gaps usually appear around email channels and customer data handling.
What does the Freshdesk XML export not carry over?
The Freshdesk export covers tickets, solutions, forums and customers as XML, but the account configuration around that data is not the same as the data itself. Expect to rebuild agent accounts and their permissions, groups, business hours, SLA policies, automation rules, canned responses, email and mailbox setup, custom ticket fields where the mapping is not direct, and any apps or integrations you connected to Freshdesk. Check attachment handling, time zone settings and any ticket status or priority values that do not map one to one. Test a sample of closed and open tickets, including their history and notes, before you accept the migration as complete. Confirm every item against the current export file and Zammad's migration documentation, since the exact coverage can change between releases.
Can Zammad's built-in migrator run more than once?
No. Zammad's migrator runs all or nothing, works only on a new instance and accepts one source system per migration, according to Zammad's migration documentation. It does not run as a differential sync, so changes made in Freshdesk after the import will not be picked up by a second pass into the same instance. In practice, this means you should run a rehearsal on a throwaway instance to find problems, then freeze Freshdesk changes or plan a final export and a fresh import on a clean target at cutover. Ask your team to confirm the current behavior in the version you intend to deploy, because migrator rules are the kind of detail that changes across releases.
What does a Zammad support contract cover?
Zammad GmbH offers support contracts for self-hosted installations under the names Business, Enterprise and Corporation, according to its pricing page. These contracts are a vendor relationship with the company that develops Zammad, and they are separate from the open-source license, which is GNU AGPLv3 and does not require a subscription to use. Compare the contract tiers on the pricing page and ask Zammad GmbH to confirm in writing which response times, channels, upgrade help and escalation paths each tier includes. A contract is an ongoing recurring cost, so include it in your total cost of ownership next to hosting, staff time and any outside services. Do not assume a contract covers your customizations or your hosting environment unless the written terms say so.
What recurring costs do we take on after the move?
After cutover, the recurring costs are the infrastructure that runs Zammad, the people who operate and patch it, backups and storage for ticket history and attachments, and any vendor support contract you choose. Freshdesk subscription fees stop only when your account is closed, so run both systems in parallel for the agreed period and budget for that overlap. Costs rise with ticket volume, attachment size, number of agents, email channels and the number of integrations you maintain. Ask any partner to separate one-time work, such as the migration and rebuild, from ongoing retainer work, such as upgrades and monitoring, in the quote.
What carries over from Freshdesk and what must be rebuilt
Plan on the records moving and the routing logic being rebuilt. Freshdesk's XML export, found under Admin, Account, Account Details, Export data, covers tickets, solutions, forums and customers, and it is available on all plans. Zammad's built-in migrator reads that Freshdesk source and imports the customer and ticket history. Those are the records your agents and auditors will search. Everything that tells the system how to act on those records sits in configuration, and that configuration is not the same thing as data. Treat the two as separate workstreams with separate owners and sign-off.
Expect to recreate the triggers, SLA policies, automations, mailboxes, macros, business hours and portal branding in Zammad by hand. Freshdesk's rules for routing, escalation and response targets depend on how your team built them, so each one needs a written equivalent in Zammad's trigger, overview and SLA settings before cutover. Inbound email addresses must be reconnected to Zammad's mail channels, and the help center's look and content must be rebuilt separately. The Zammad migration documentation states that migrations run all or nothing, only on a new instance and from one source system at a time, so a partial retry is not an option. Test on a scratch instance first.
Before you commit, run a test Freshdesk export and compare the XML fields against a sample of real tickets. Confirm how attachments, ticket time stamps, custom fields, tags, agent assignments and customer organizations are represented after import, and confirm the exact field coverage with the Zammad version you plan to run. Build an inventory of every Freshdesk rule and mailbox, then assign each one to a rebuild item with an owner. If you want an implementer to write that inventory and run the rebuild, the scope, deliverables and timeline are agreed in writing before work starts, and the quote follows from that scope.
How DeployOpen scopes, migrates and supports your Zammad move
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Freshdesk to Zammad, we start with a written scope that covers the data export, the migration run, and the parts of the helpdesk that must be rebuilt by hand.
How we scope
- We confirm which Freshdesk XML export components you need: tickets, solutions, forums and customers.
- We map agent groups, roles, SLAs, automations and email channels to Zammad equivalents before any build starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- We stand up a new Zammad instance in your environment, since the built-in migrator only runs against a new instance.
- We run the migration as a full import, test it against a copy of the data, and check ticket counts and attachments.
- We rebuild triggers, macros, email channels and reporting, then test each workflow with your support team.
How we hand over
- We document the architecture, the migration steps, the configuration decisions and the rebuilt workflows.
- We write runbooks for backups, upgrades and user management so your own staff can operate the system.
- We agree a cutover plan with a rollback path and a defined window for the final Freshdesk export.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after go-live.
- Zammad GmbH offers support contracts for self-hosted installations, and we can help you compare them with a retainer.
- Ask us to confirm which parts of the Freshdesk setup, such as third-party integrations, need a post-migration review.
