How to migrate from Freshdesk to Zammad without a partial import
If your Freshdesk renewal, data residency rule or lock-in concern is pushing you toward Zammad, know this first: Zammad ships a built-in Freshdesk migrator, and it only works on a new Zammad instance, all or nothing. A migration either completes in full or does not land at all, so you cannot run it against a production instance that already holds tickets. The Zammad team documents this in its migration documentation, which is the first read for anyone planning the work. The support operations lead usually owns the cutover decision, a Zammad administrator runs the import and configuration, and an implementation partner is often brought in for the target hosting, integrations and testing. Each of these roles should be named in writing before the import starts.
Plan the sequence around the all-or-nothing rule. Stand up the target instance first, confirm the PostgreSQL 15 or newer, Redis 7 or newer and reverse proxy requirements in the software requirements, then run a rehearsal import on a throwaway instance. Because the migrator accepts one source system per migration and the import cannot be repeated on the same instance, the rehearsal shows which ticket fields, agents, groups and attachments need manual cleanup. Keep Freshdesk running until the production import is verified. Before you cancel anything, have a full account export from Freshdesk's Export data page in Admin, Account, Account Details as a fallback copy. That XML file is your recovery path if the import fails or a later audit asks for source records. Confirm with Zammad and your own environment exactly which objects carry over, and budget for rebuilding automations, macros, SLA rules, mailboxes and channel settings by hand.
Which Freshdesk capabilities map cleanly to Zammad
This table compares the main Freshdesk capabilities with their nearest Zammad equivalents and marks each as clean, needs rework, gap or verify. Zammad's migrator works only on a new instance and is all or nothing, so most rows need rebuilding or checking after import. Items not confirmed in Zammad's documentation are marked verify and should be checked against the current release before you set a cutover date.
| Freshdesk capability | Zammad equivalent | Status | What to confirm |
|---|---|---|---|
| Tickets and conversation history | Zammad tickets with articles and attachments | Needs rework (verify) | Which ticket fields and conversation history the migrator imports in the current release |
| Email channels | Zammad email channels and mailboxes | Needs rework | Recreate inbound and outbound addresses, then test routing and replies on the new instance |
| Agents, groups and roles | Zammad agents, groups and roles | Needs rework (verify) | Which agent accounts, group memberships and roles import, and how to reset passwords and set up SSO afterward |
| Knowledge base (solutions and forums) | Zammad knowledge base | Verify | Whether Freshdesk solutions and forums load into Zammad's knowledge base or need manual rebuilding |
| Automations and workflow rules | Zammad triggers, overviews and schedules | Gap (verify) | Freshdesk automation rules are not carried over; rebuild and test each one in Zammad |
| SLAs and escalations | Zammad service level agreements | Verify | Supported SLA targets, business hours and escalation logic in the current release |
| Satisfaction surveys | Customer satisfaction surveys in Zammad | Verify | Whether survey responses are exported and whether Zammad offers an equivalent survey |
| Mobile apps | Browser access for agents | Verify | Whether Zammad provides an agent mobile app in the current release; plan for browser access meanwhile |
| Reporting and dashboards | Zammad reporting, supported by Elasticsearch | Needs rework | Which Freshdesk reports you need, then rebuild them and confirm coverage against Zammad's reporting features |
What the Freshdesk export and migrator carry, and what you rebuild
The Freshdesk XML export is your fallback copy, and Zammad's migrator is the import path. Neither one moves every part of a working support desk, so the cards below separate what arrives in Zammad from the configuration you must recreate and test. Treat each card as a checklist item for the migration plan.
Freshdesk XML export as fallback
An account administrator runs the export from Admin, Account, Account Details, Export data, and Freshdesk includes tickets, solutions, forums and customers as XML on every plan. Keep this file as an independent copy before you start, whatever the migrator does. Confirm with Freshdesk that the export is complete for your account size, then store it under your own retention rules. The XML is not a ready import file for another helpdesk, so plan a conversion step if you rely on it.
Zammad migrator on a new instance
Zammad's built-in migrator imports from Freshdesk, and it works only on a new instance. Migrations are all or nothing, so a failed run is not a partial success you can finish by hand. Plan a rehearsal on a throwaway instance, check the imported ticket counts and states against Freshdesk, and only then run the production import. Accept that the migrator takes one source system per migration.
Integrations and macros to rebuild
Freshdesk integrations, such as marketplace apps connected to billing or chat tools, do not move with the data. Macros, the canned responses agents click to send, also need to be recreated in Zammad's own format. Inventory every integration and macro in Freshdesk, decide which have a Zammad equivalent, and assign an owner to rebuild each one. Test them with agents before the cutover date.
Triggers, automations and SLAs
Freshdesk automations, such as ticket assignment rules and escalation logic, must be rewritten as Zammad triggers, schedules and service level settings. Export the rules from Freshdesk as written documentation, because the export is not a configuration you can load into Zammad. Ask the team that owns routing to sign off the rebuilt rules against a set of sample tickets. Confirm that response and resolution targets match the agreed service levels.
Third-party login through SAML and OIDC
Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Agent and admin sign-in is a separate configuration from the migrated user records, so confirm that every agent can sign in through your identity provider before cutover. Plan a fallback local admin account in case the identity provider is unavailable. Check that group or role mappings carry the permissions your agents have today.
Mailbox connections and passwords
Email channels are the most common cause of lost support messages after a helpdesk move. Freshdesk inbound and outbound mailboxes, forwarding rules and DNS records must be pointed at Zammad, and the old forwarding must be switched off in the right order. Confirm that user passwords are not part of the migration, so customers and agents must reset or sign in through configured login methods. Test inbound and outbound mail on each address before you retire Freshdesk.
Freshdesk to Zammad migration steps from inventory to decommission
This sequence moves support operations from Freshdesk to a self-hosted Zammad instance in controlled stages. Each step produces a record that the next step depends on, so the team can prove what moved, what was rebuilt and what was retired.
Inventory Freshdesk data and configuration
Support leads and the Freshdesk administrator list every group, agent role, mailbox, channel, automation, SLA, canned response, knowledge base article and integration in use. The list also records which fields and custom attributes staff rely on daily and which integrations push or pull data. Output: a written inventory list with an owner for each item, reviewed by the support manager. The step is done when every active channel and workflow has a named target in Zammad or a documented decision to drop it.
Archive a full Freshdesk export
A Freshdesk account administrator runs the account export from Admin, Account, Account Details, Export data. The export covers tickets, solutions, forums and customers as XML and is available on every plan. Store the file in your own encrypted archive with checksums and a retention owner, because it is your fallback copy if the migration must be repeated. The step is done when the archive opens, the record counts are logged and someone outside the migration team confirms the copy is retrievable.
Build a fresh pilot Zammad instance
The platform team deploys Zammad on infrastructure you control, using the package, Docker Compose or Helm options that match your operations standard. Confirm the software requirements for PostgreSQL, Redis and the reverse proxy in the Zammad documentation, and decide early whether Elasticsearch and Memcached are needed. Pin the instance to a current release line and record the version. The step is done when the pilot runs, admin login works through your identity provider and the configuration baseline is saved as code or a documented runbook.
Run a rehearsal migration
Import the Freshdesk export into the pilot using Zammad's built-in Freshdesk migrator, which works only on a new instance and accepts one source system per migration. Because migrations are all or nothing, a failed run means the instance is rebuilt before the next attempt, so log every run with its start time, outcome and error output. Read the migration documentation before the rehearsal to confirm which objects the migrator handles. The step is done when a clean run completes and the log shows the reproducible steps.
Validate the migrated data with support agents
Agents and team leads check a sample of migrated tickets, including old threads, attachments, customer records, tags and states, against the Freshdesk export. They also rebuild each item the migrator does not carry over, such as automations, SLAs, macros, mailboxes and knowledge base content, following the inventory from the first step. Record each test case with a pass or fail result and a named reviewer. The step is done when the signed-off test cases cover every workflow in the inventory and the open defects have owners.
Run Freshdesk and Zammad in parallel
Route a limited set of inbound email and web form traffic to Zammad while Freshdesk stays live as the system of record for everything else. Compare response handling, routing and notifications between the two systems each working day, and log every discrepancy with its root cause. Keep customer-facing reply addresses unchanged during this phase. The step is done when the discrepancy log is empty or every open item has an accepted workaround signed by the support manager.
Cut over channels and retire Freshdesk access
Plan the final migration window with the support manager, then run the full migration to a new production instance, repeat the validation checks and switch inbound mail, web forms and integrations to Zammad. Disable Freshdesk automations and outbound messages so customers do not receive duplicate replies. Keep the Freshdesk account read-only for reference. The step is done when a cutover record lists the switch time, the DNS and mail changes, the validation results and the owner who approved go-live.
Decommission Freshdesk and retain the archive
Once the retention period set by your legal and records owners has been agreed in writing, cancel the Freshdesk subscription and confirm the vendor's account closure steps in writing. Keep the archived XML export and the migration logs under your retention policy, and confirm who may access them. Remove Freshdesk API keys, webhooks and single sign-on connections. The step is done when the decommission record shows cancellation confirmation, credential removal and the archive location with its owner.
Why the all-or-nothing rule shapes the cutover plan
Zammad's built-in Freshdesk migrator is all or nothing, works only on a new instance and accepts one source system per migration. In practice, that means a failed or unsatisfactory run is not repaired in place. You stop, reset to a clean Zammad instance and run the migration again from the start. Plan for that as the normal path for the first attempt, not as an edge case. The cutover schedule should assume that more than one full run may be needed before the data is accepted, and the number of rehearsals should be agreed with the support lead and the administrator who will run the import, not left to whatever time is free before go-live.
The same rule drives the freeze window. Because each run imports a complete snapshot, tickets, customers and agent changes made in Freshdesk after a run starts will not appear in Zammad unless you run again. Decide when Freshdesk changes stop, who is allowed to make exceptions, and how agents record work done during the freeze. Ask the Zammad team and your own change board to confirm the current rules on differential or repeat runs in the Zammad migration documentation before fixing the window, since these limits can change between releases.
Keep Freshdesk active and its export intact until your business has formally accepted the Zammad data. Acceptance should be a written check against record counts, sample tickets with their conversations and attachments, and the customer list, signed off by named owners. Until that sign-off, Freshdesk remains the system of record and its XML export from the account settings remains your fallback copy. Do not cancel the Freshdesk subscription, delete the export or switch email routing to Zammad before acceptance is recorded.
How the migration changes by team size and starting point
A small team that handles support mainly through email usually has a short list of groups, a handful of agents and few automations. The migrator's all-or-nothing rule matters less here because a full import is quick to check by hand. The main work is confirming that the mailbox addresses, agent accounts and signatures land where your agents expect them, and that inbound email routing works on the new Zammad instance before cutover.
- Scope: one or two rehearsal imports on a fresh instance are often enough, since there are few objects to compare.
- Rebuild work: mailbox channels, email templates and a small set of triggers usually need manual recreation.
- Agent accounts: confirm that each agent can sign in and that user passwords are reset, because passwords are not carried over.
- Ticket history: spot-check old tickets, attachments and customer records against the XML export.
- Cutover: plan a short window in which both systems are checked for inbound mail.
Before you start, ask your Zammad partner to confirm which channel settings and triggers from your current account they will rebuild and which you will recreate yourself.
A team that runs several brands, product lines or regional queues in one Freshdesk account usually has many groups, routing rules, SLAs and automations that depend on each other. Here the migration is less about moving records and more about deciding how the Zammad structure maps to the old one. Each brand may need its own groups, roles and email addresses, and each automation must be read against the new trigger and overview model before it is rebuilt.
- Scope: plan the group and role map first, then rehearse the import until the structure is settled.
- Rehearsal count: expect several imports on fresh instances, since each change to the mapping means another full run.
- Rebuild work: routing rules, escalation logic and reporting views usually need redesign rather than copying.
- Access control: confirm that agents see only the brands they serve after the import.
- Parallel checks: compare ticket counts and assignments per group against the XML export.
Ask your implementer to show how each Freshdesk group, automation and SLA maps to a Zammad object, and to list anything with no direct equivalent.
A team with years of tickets, heavily customized ticket fields, custom integrations or a long list of legacy automations faces the largest rebuild. Historical data is often the bigger risk, because older tickets may use fields, statuses or tags that no longer exist in daily use. The all-or-nothing rule means that one bad record can cause a rerun, so the team should budget for a longer rehearsal cycle and a clear decision on what history must be kept online.
- Scope: decide which closed-ticket years must be migrated and which can stay in the Freshdesk export archive.
- Rehearsal count: plan several runs, with each run checked against record counts and sample tickets.
- Custom fields: map each custom field to a Zammad object field or drop it with a documented reason.
- Integrations: every API connection and app that writes to Freshdesk must be rebuilt or retired.
- Fallback copy: keep the XML export as an archive so the original data stays available if a later question arises.
Confirm with the vendor and your own team which custom fields and integrations will be rebuilt, and what they will cost in admin time, before you agree on a fixed scope.
What drives Freshdesk to Zammad migration cost and duration
This table lists the factors that change the one-time migration effort and the recurring running costs when moving from Freshdesk to self-hosted Zammad. Read each row as a question to answer in your own environment before requesting a quote. The main takeaway is that the software itself carries no license fee, so most of the cost sits in data volume, rebuild work and the infrastructure and support you choose.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Ticket and attachment volume | Zammad's migrator runs all or nothing on a new instance, so a large export takes longer to load and retest. Attachments add storage and transfer time on top of ticket records. | Confirm volumes from the Freshdesk export before scoping. Decide early whether closed tickets older than a set period need to move at all. |
| Number of agents and roles | Agents, groups and role permissions must map to Zammad users and access rules, and passwords do not carry over, so users must set up new logins. | Clean up inactive agents before export. Agree a role model with the business before the migration run. |
| Groups, automations and workflows to rebuild | Freshdesk automations, ticket fields, SLAs and canned responses are not a like-for-like copy in Zammad, so each one is rebuilt and tested by hand. | Inventory existing automations and drop those no longer used. Ask the implementer to list each item as carried over, rebuilt or retired. |
| Identity integration | Agent and customer sign-in through SAML, OpenID Connect or a directory provider needs configuration, testing and an agreed fallback for admin accounts. | Confirm the identity provider and protocol early. Ask for test accounts in a staging instance before cutover. |
| Self-hosted infrastructure | Zammad requires PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy such as Nginx or Apache. Optional Elasticsearch improves search and attachment content search, and Memcached is needed for multi-instance deployments. | Reuse existing database and monitoring platforms where your standards allow. Size the Elasticsearch footprint only if search and attachment indexing are required. |
| Zammad support contract | Self-hosted support subscriptions are a recurring cost, published by Zammad GmbH at Business 2,999 EUR per year, Enterprise 5,999 EUR per year and Corporation 9,999 EUR per year (Zammad pricing page). These are separate from the one-time migration work. | Compare the tiers against your internal admin capacity. Ask the implementer and Zammad which response times and channels each tier includes. |
| Items to request in a written quote | A quote should separate one-time work from recurring work, so you can compare options on equal terms. | Request: scope of data loaded, a list of rebuilt items, test and cutover plan, infrastructure assumptions, backup and upgrade responsibilities, and any Zammad subscription cost shown as a separate line. |
What goes wrong in a Freshdesk to Zammad migration and how to prevent it
Most failed Freshdesk to Zammad moves trace back to the same few gaps: an import that cannot be partly undone, data that was never checked after load, and cutover steps that nobody owned. Each card below names one risk, the signal that shows it is happening, and the prevention step to put in your plan before the freeze begins.
A failed run needs a new instance
Zammad's built-in Freshdesk migrator is all or nothing and works only on a new instance, so a run that stops partway cannot be patched in place. Your team may have to start over on a fresh server, which adds time to the project. Rehearse the full import on a clean instance before the production run, record the duration and every error, and confirm that the production target is empty before you start. Ask your implementation partner to document the rollback path in writing.
Attachments or history missing after import
Freshdesk tickets, customers and knowledge content are only as complete as the export you take from them, and gaps often appear in attachments, long conversation threads or customer records. Once the production system is live, these gaps are harder to fix. Keep the Freshdesk XML export as a fallback copy, store it under access controls, and sample tickets from each queue, including old closed ones with attachments, against the source system after the import.
Automations and routing rules lost
Freshdesk automations, SLA timers, escalation paths and group assignments are the logic agents depend on every day, and they do not appear in a data export in the same form they run in Freshdesk. Agents may notice missing escalations only after a customer complains. List every active Freshdesk automation before the migration, map each one to its Zammad equivalent, and test each rule with a sample ticket. Assign one owner to sign off each rule before go-live.
Email routing not cut over
Customers keep writing to the old support address until the mail flow changes, so tickets can arrive in Freshdesk after the data has moved to Zammad. Some messages may be split between two systems and nobody notices until a customer asks why a reply never came. Test each Zammad mailbox with inbound and outbound messages before cutover, then change forwarding or DNS records in a single planned window. Keep the Freshdesk mailbox live for a documented period so late messages are still answered.
Identity mismatches with SSO
Agents and customers who sign in through SAML, OpenID Connect, Microsoft, Google, GitHub or GitLab need a matching account in Zammad, or they will see duplicate profiles or no access at all. Name or email differences between the identity provider and the migrated records create the most confusing cases. Compare the identity provider attributes with the migrated email addresses for every agent and key customer, and test one login per role. Confirm the exact login options your Zammad setup supports in the admin documentation.
Freshdesk changes during the freeze
Any ticket, agent or setting changed in Freshdesk after the export is missing from Zammad unless the team plans for it. Without a defined freeze, the gap grows with each working day of the migration. Agree a freeze window with support leads, block new configuration changes in Freshdesk during that time, and repeat the export once the freeze starts so the final copy matches the last working state. Name one person who owns the cutover decision and records the export time.
Freshdesk to Zammad migration cost, time and what it needs from your team
What does a Freshdesk to Zammad migration actually cost?
The Zammad software itself carries no license fee when self-hosted, so the cost is made of components: infrastructure to run Zammad, the migration work itself, optional support, and the admin time to operate and rebuild configuration. Infrastructure and admin time recur, while the migration work and initial configuration are largely one-time. Zammad GmbH publishes 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 its pricing page, but a support contract is optional. Ask any provider for a quote that separates each component so you can compare it with your current Freshdesk spend.
How long does a Freshdesk to Zammad migration take?
No supplied figure gives a reliable duration, so treat any number you hear as an estimate to be checked against a written scope. The main drivers are the number of tickets and attachments, how many agents, groups, macros and automations must be rebuilt, how many channels and mailboxes connect to the new instance, and how much cleanup the data needs before import. Because Zammad's migrator works only on a new instance and is all or nothing, a clean rehearsal and a defined cutover window add time but reduce rework. Ask for a timeline tied to phases and named deliverables.
Can an internal Freshdesk admin run the migration alone?
Often yes for a small or mid-size team with a simple setup, provided someone has Linux, PostgreSQL and Zammad administration experience and time to rehearse the import. The migrator itself runs from Zammad's administration interface, but the hard parts are provisioning a new instance with PostgreSQL 15 or newer and Redis 7 or newer, configuring the reverse proxy, and rebuilding what does not carry over. Teams without that skill set usually bring in outside help for the infrastructure and rehearsal. Be clear with yourself about who will patch Zammad after go-live, because upgrades continue long after the migration.
What does the migration need from support leads?
Support leads decide what the new system must do on day one, which is the most important input to scope. They need to confirm which groups, queues, SLAs, macros, triggers, views and customer-facing templates must exist at cutover, and they should supply examples of tickets that show how agents actually work. They also need to agree which closed tickets are worth migrating and how long to keep history, and to test the rebuilt workflows with a few agents before go-live. Plan for this review time in the schedule, since skipped validation is the most common source of post-launch complaints.
Is a Zammad support contract required to migrate?
No. Zammad is licensed under AGPLv3, and self-hosted use does not require a paid subscription. A support contract is optional and is useful when you want a vendor to respond to production issues under defined terms. Compare the Business, Enterprise and Corporation tiers against your internal capacity and your uptime needs, and check what each tier covers before you buy. Whatever you choose, confirm in writing who handles upgrades and security releases, since Zammad published security releases on more than one line in October 2026.
What is the Freshdesk XML export for if the migrator works?
The XML export is your fallback copy. Freshdesk account administrators can export tickets, solutions, forums and customers as XML from Admin, Account, Account Details, Export data, on all plans. Keep this copy until the new system has been validated, because if a migration run fails or must be repeated, the export gives you an independent source. Note that the export is not a ready-made import file for Zammad, so any alternative path would require conversion work. Confirm with Freshdesk which data the export includes before you rely on it for records retention.
What should I request in a quote for this migration?
Ask for a written scope that lists the ticket and attachment volumes, the channels to connect, and the workflows to rebuild, along with the phases, deliverables and acceptance criteria. Request separate line items for infrastructure setup, the rehearsal and final migration, configuration rebuild, user and identity integration, testing, training, cutover support and any post-launch support or upgrade work. Ask which items are one-time and which recur, what is excluded, how a failed migration is handled, and whether the fallback export is part of the deliverables. DeployOpen plans and implements self-hosted platforms in your own infrastructure and prices from the agreed scope.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Freshdesk to Zammad move, we start with a written scope that fixes what is migrated, what is rebuilt and what is retired, then run the work against that scope.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory the Freshdesk export, including tickets, solutions, forums and customers, and record what the Zammad migrator will and will not import.
- The written scope lists the automations, views, mailboxes and roles to rebuild in Zammad, so nothing is assumed to carry over.
How we build
- We stand up a fresh Zammad instance in your environment, since the built-in Freshdesk migrator only runs on a new instance.
- We run test migrations against a copy of the export and check ticket counts, customers and attachments before any cutover.
- We rebuild groups, roles, SSO, email channels and notifications, and test each one against the agreed scope.
How we hand over
- We document the migration run, the field mapping decisions and the rebuilt configuration so your team can repeat or audit them.
- We keep the original Freshdesk XML export as a fallback copy, stored under your retention rules, and document how to restore from it.
- Handover covers admin training and a runbook for daily operation, with the open items recorded against the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Zammad version upgrades, backups and periodic security testing of the instance, scoped in writing.
- Confirm with us and with Zammad GmbH which support tier, if any, fits your team, since Zammad's support contracts are separate from our work.
