Migrate from Freshdesk to Zammad: what moves and what needs a decision
If your support team runs on Freshdesk and you want Zammad in infrastructure you control, the main work is not writing import code. Zammad ships a built-in migrator for Freshdesk, so the effort sits in planning, API access, test imports, cutover and the post-import configuration. This section sets out the decisions you need to make before anyone runs the migrator, so that the scope you hand to a partner or your own team is written against your actual data and environment.
Scope and duration depend on your environment and your data. The number of agents, groups, ticket history, attachments, custom fields, automations and the mail channels you route into Zammad all change the work. Your Freshdesk plan and the API access it allows also shape what you can extract and when. Ask for these facts to be inventoried first, because they determine the test plan and cutover window. DeployOpen provides a fixed-scope quote once the written scope is agreed, which means the inventory is the input to the price, not an afterthought.
Decisions to make early. Decide which Freshdesk objects must arrive intact, such as agents, groups, companies, contacts and tickets with their history, and which can be archived instead of imported. Decide how much closed ticket history you need in Zammad on day one. Decide whether agents keep their existing identities and how their accounts will be mapped. Decide whether customers will sign in or only receive email, because that determines how the post-import configuration and login paths are designed. Each choice changes the test cases you will need.
Checks to run before cutover. Confirm that the Freshdesk API key you will use belongs to an account with sufficient rights and that the plan allows the calls the migrator makes. Run at least one trial import into a non-production Zammad instance and compare object counts and sample tickets against Freshdesk. Note that Zammad reports progress in steps of 100 rather than showing a total, so plan your monitoring around that. Also confirm that the migrator may skip the setup wizard, which means you must set the fully qualified domain name in Zammad afterward, or links and notification emails will point to the wrong address.
Risks to plan for. The most common surprises are an incomplete FQDN after import, email channels that still point at Freshdesk during the cutover window, and agents who expect the same login behavior after the move. Plan how agents and customers will authenticate on the new system, and confirm with your identity team whether single sign-on will be configured before or after the migration. Agree a rollback plan with a named owner, and confirm with the vendor and your own environment which Zammad version and database and cache requirements apply before you build the target.
Freshdesk to Zammad migration: which data maps cleanly
This table compares common Freshdesk objects with their closest Zammad equivalent and flags where a gap or manual rebuild is likely. Treat the migrator column as a question to answer, not a promise: the Zammad Freshdesk migration documentation and a test import against your own configuration decide what carries over. The main takeaway is that tickets, contacts and agents need validation first, while automations and content libraries usually need planned rebuilding.
| Freshdesk object | Zammad equivalent or gap | Migrator status | What to confirm |
|---|---|---|---|
| Tickets and conversations | Zammad tickets with articles for the conversation history | Confirm which ticket fields and conversation history the migrator imports | Compare ticket counts and latest update times in a test import against Freshdesk |
| Contacts | Zammad customer users | Confirm which contact fields, such as email, name and phone, are carried | Check that a sample of imported customers receives notifications in the test environment |
| Agents | Zammad agent users with roles | Confirm agent roles and whether any credentials are migrated | Plan password resets and confirm each agent's role after import |
| Groups | Zammad groups that control ticket access | Confirm group membership is imported and whether group access settings are carried | Rebuild group access manually where the import does not map it |
| Companies | Zammad organizations linked to customers | Confirm company-to-contact links are preserved | Verify organization membership on a sample of contacts after import |
| Custom fields | Zammad object attributes with matching types and options | Likely needs manual rebuild for field types and option lists; confirm in the documentation | Create matching attributes before the test import and compare values on sample tickets |
| Automations and SLAs | Zammad triggers, schedulers and service level agreements | Typically rebuilt rather than converted; confirm against the documentation | Document each Freshdesk rule and rebuild it in a staging instance for testing |
| Canned responses and knowledge base articles | Zammad text modules and knowledge base content | Confirm whether either is imported; treat as manual work until verified | Export the content from Freshdesk and plan its rebuild or import route separately |
How the built-in Freshdesk migrator reads your data
The documented path has two stages. Zammad's built-in Freshdesk migrator connects to your Freshdesk instance through API access, reads the objects in scope, and then imports them into Zammad. The first decision is which Freshdesk account the migrator will use. Confirm with your Freshdesk administrator that this account stays active for the whole run and that its permissions cover every object you plan to move, including tickets, conversations, contacts, companies and agents. Then confirm how Freshdesk API rate limits apply to your plan, because a large import reads continuously and the source system may slow it. Ask the administrator to avoid bulk edits and automation changes in Freshdesk during the run, since the migrator reads a live source and your cutover plan has to account for anything that changes while it runs.
Zammad does not show a total object count during a Freshdesk import. It counts in steps of 100, so the figure rises in blocks and gives you a sense of movement without a finish line. Do not read the counter as a percentage. Before the run, take object counts from your own Freshdesk exports or reports for each category in scope, and write them down as your baseline. As the import proceeds, compare Zammad's progress against those numbers, category by category, and record the time of each check. A counter that stops moving for a long period is a signal to check the job status and server logs of your installation before you assume the run is healthy. Your baseline is also the basis for the reconciliation you will do after the import completes.
The migrator may skip the setup wizard, and when it does, the fully qualified domain name (FQDN) is not set in the normal first-run flow. You must set it manually after the import finishes, and you should do so before any agent or customer relies on the system. The FQDN is the host name Zammad uses when it builds links, so it affects the links in notification emails and the addresses that agents and customers open in their browsers. If it is unset or wrong, email links can point to a host that does not serve Zammad, and agent sessions and realtime updates can misbehave if the host name users type does not match the one Zammad expects. Confirm the exact setting location in the admin documentation for your version, and compare the value with the host name in your reverse proxy configuration and TLS certificate.
Treat the FQDN check as a gate in your cutover runbook. After the import and before go-live, set the FQDN, confirm it is saved, and send a test notification to an internal mailbox. Open the link from that email in a clean browser session and confirm it lands on the production host. Sign in as an agent through the same host name your team will use, open a migrated ticket, and check that the ticket's links and attachments resolve. Record the results with the time and the version you tested against. If any step fails, fix the FQDN and proxy settings first, then repeat the check, so that the first real messages your customers receive contain working links.
Which import paths Zammad documents for Freshdesk
Zammad documents three routes for bringing Freshdesk data into a self-hosted instance: the built-in Freshdesk migrator, the Zammad API, and custom development from Zammad. The migrator is the starting point, and the other two cover data it does not reach. Each route depends on Freshdesk API access, plan settings and object coverage that the team should confirm before the migration plan is set.
Built-in Freshdesk migrator
The migrator is the documented first route for moving Freshdesk data into Zammad. It runs with Freshdesk API access that has the permissions the migrator needs, so confirm the key owner and those permissions before the test import. Confirm your Freshdesk plan level and which object types the current migrator documentation includes. During the run, Zammad counts progress in steps of 100 and does not show a total, and the setup wizard may be skipped, so the FQDN must be set afterward.
Zammad API for uncovered data
Use the Zammad API for data the built-in migrator does not cover. Your team or a partner writes a script or small tool that creates the Zammad objects it needs, which requires a Zammad API token with permissions for those objects. For each Freshdesk object type, confirm whether the migrator includes it, since anything outside that list falls to this route. Agree the mapping of IDs, states and owners on a test instance first so that reruns can be checked against the same results.
Custom development from Zammad
For data that neither the migrator nor the API can carry across, Zammad documents custom development as the remaining route. It is a separate scoped engagement with Zammad that adds build, test and maintenance effort to the plan. Ask Zammad to confirm in writing what the work covers, who maintains the code after cutover, and how it is tested against a copy of the Freshdesk export before it touches production data.
Assigning each object to a route
Most migrations combine these paths, so assign each Freshdesk object type to one route before the test import. Record which objects the migrator covers, which need API scripts and which need custom work. Verify the assignments on a test instance and keep a list of exceptions for the cutover plan. The same list shows which Freshdesk plan level and API settings each route depends on, so gaps surface before the migration window.
What changes for agents and customers after the move
Agents and customers will reach Zammad at a new hostname, and that address must be settled before anyone is invited. Zammad's Freshdesk migrator may skip the setup wizard, so the fully qualified domain name (FQDN) is not set for you during import. Set it manually after the import finishes, then confirm that links in notification emails, the customer portal and agent browser sessions all resolve to that FQDN. Test this on the staging import first, because a wrong FQDN leads to broken links in messages that have already left the system.
Login methods need a decision before cutover. Zammad supports local accounts and third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Decide which group of users signs in with which method, and whether your identity provider is the source of truth for agents. Then confirm with the Zammad documentation how migrated Freshdesk users are authenticated, whether they need a password reset, and whether an invitation email has to be sent. Plan this per user group, and test an agent login and a customer login on the new FQDN before the day of cutover.
Customers need a clear notice of the new address, what to do with existing bookmarks, and where to send new requests. Draft the message with your support leads and publish it ahead of the switch, using the channels your customers already read. Confirm with the vendor documentation whether links to old Freshdesk tickets will work after the move, and tell customers what to expect if they reply to an old thread. Keep the wording short, name the new address once, and assign someone to answer questions in the first days so that confused customers do not open duplicate tickets.
Email forwarding changes are the point where cutover most often breaks. Each support address that currently forwards to Freshdesk needs a new forwarding rule or DNS change pointing to the Zammad inbound channel, and each one should be tested with a reply from an external mailbox. Check that replies thread to the correct ticket and that outbound mail is sent from the expected sender address with valid SPF, DKIM and DMARC records. Keep the old forwarding active until the new path is verified, and decide in advance when Freshdesk stops receiving mail.
Agents need hands-on training before cutover because the Zammad interface differs from Freshdesk in layout, ticket views and navigation. Give each agent role a session on a test instance with realistic tickets from the import, and walk through the actions they use daily, such as assigning, replying, merging and searching. Also confirm which automations, triggers and macros must be rebuilt in Zammad, since they do not carry over automatically, and make sure supervisors know how roles and permissions apply. Record short guides for the most common tasks and keep them available during the first week of live use.
Freshdesk to Zammad migration sequence: from inventory to decommissioning
This sequence moves Freshdesk data into a Zammad instance you control, with each stage gated by evidence so the team knows when to advance. It ends with Freshdesk retired and an archive kept under your own retention rules.
Inventory Freshdesk configuration and API access
The Freshdesk administrator and the support operations owner list the objects the migration must carry, including agents, groups, companies, contacts, tickets, attachments, and custom fields. Confirm that the API key belongs to an account with enough rights and that your Freshdesk plan allows the API volume you expect. Record ticket and attachment counts, and note any configuration you will rebuild by hand in Zammad. This step is done when the inventory is signed off and a test API call returns the records you expect.
Build the Zammad target stack
The platform team installs Zammad with a supported method and connects PostgreSQL 15 or newer, Redis 7 or newer for realtime websocket traffic, and a reverse proxy running Nginx or Apache. Decide whether to run Elasticsearch, which is optional but strongly recommended for search and attachment content. Use Memcached only if the deployment has multiple instances, such as containers or cluster nodes. This step is done when the application starts, the proxy serves it, and each backing service passes its health check.
Run a test import into a non-production instance
The migration lead runs the built-in Freshdesk migrator against a non-production Zammad instance using a copy of the source data or sandbox credentials. Zammad counts progress in steps of 100 and does not display the total object count, so the team compares final results with the inventory from the first step. Check agent assignments, ticket states, customer records, and sample attachments. This step is done when the reconciliation report is accepted by the support operations owner.
Verify the FQDN and login paths
The migrator may skip the setup wizard, so the platform team sets the public FQDN in the system settings after the import. Test agent sign-in, customer sign-in, password reset emails, and any third-party login such as SAML or OpenID Connect that you plan to enable. Confirm outbound email and inbound channel addresses resolve to the new host. This step is done when each login path works from a clean browser session and the security owner has signed off on authentication settings.
Confirm import behavior before planning parallel operation
Before any parallel run is scheduled, the migration lead confirms with Zammad in writing whether repeated or differential imports are supported for your Freshdesk data. If they are not, the two systems will diverge once Zammad goes live, and tickets changed in Freshdesk after the import must be handled by a defined manual process. Decide which channels stay on Freshdesk, who reconciles changes, and when the parallel period ends. This step is done when the confirmation and the runbook are approved in writing.
Cut over inbound channels to Zammad
The support lead freezes configuration changes in Freshdesk, runs the final import using the method confirmed in the previous step, and checks the counts against the inventory. The platform team then switches inbound email, forms, and DNS to the Zammad host, and the support lead notifies agents and customers of the new address. This step is done when the cutover checklist is complete, inbound test messages land in Zammad, and the on-call owner confirms the first shift.
Decommission Freshdesk
Once the retention period agreed with your compliance owner has started, the team exports and stores a read-only archive of Freshdesk data in storage you control. It then revokes API keys, removes forwarding rules and integrations that point to Freshdesk, and checks the contract terms with the vendor before cancelling the subscription. This step is done when the archive has been verified, access is revoked, and the cancellation is confirmed in writing.
What drives the cost and duration of a Freshdesk migration
This table lists the factors that change the effort of moving Freshdesk data into Zammad and shows who carries each cost, whether it is one-time or recurring, and what to ask for in a quote. Use it to see which parts of your Freshdesk setup will need the most attention before you ask for a fixed-scope proposal.
| Driver | Why it changes effort | Who pays and one-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Ticket and contact volume | More tickets, conversations and contacts mean longer import runs and more checks. The migrator counts in steps of 100 and does not show a total, so progress is harder to judge on large histories. | Team or DeployOpen under fixed scope. One-time. | Estimated object counts by type, expected run time per batch and how verification sampling is sized. |
| Agents, groups and roles | Each agent needs a Zammad account, group access and role mapping. Groups and permissions that do not map cleanly add review time. | Team or DeployOpen under fixed scope. One-time, with later changes recurring. | A mapping of Freshdesk groups and roles to Zammad groups and roles, and who signs off on it. |
| Custom fields, states and automations | Freshdesk custom fields, ticket statuses and automation rules must be recreated or accepted as-is in Zammad. Each one needs a decision and a test. | DeployOpen under fixed scope for rebuild work. One-time. | A list of custom fields, automations and SLA rules with a keep, rebuild or retire decision for each. |
| Email, chat, phone and directory integrations | Inbound and outbound email channels, chat widgets, telephony and identity sources each need separate configuration and cutover steps. | Team or DeployOpen under fixed scope. One-time, with licensing recurring where a third party applies. | Channel inventory, DNS and mail routing changes, and the directory source for agent and customer sign-in. |
| Freshdesk API access and plan limits | The import depends on API access on your Freshdesk plan. Limits on available data or request rates can change the sequence and the time needed. | Team holds the Freshdesk account. Vendor-side access is a one-time check. | Written confirmation from Freshdesk of API access and any rate or data limits for your plan. |
| Infrastructure build choices | Single-server or multi-instance layouts change what is needed for PostgreSQL, Redis, Elasticsearch and Memcached. Multi-instance setups need more components and checks. | DeployOpen under fixed scope or the team. One-time build, recurring hosting and operations. | Target topology, component versions, sizing assumptions and the hosting account where it runs. |
| Testing depth | A test import on a copy of the data and checks of tickets, attachments, users and permissions take longer when the data set is large or varied. | DeployOpen under fixed scope or the team. One-time. | Test scenarios, sample sizes and the acceptance criteria agents and managers will sign. |
| Parallel run and post-import setup | Running Freshdesk and Zammad together adds duplicate work. Setting the FQDN after the import, since the wizard may be skipped, and password or login changes also need planned time. | Team pays for staff time. DeployOpen under fixed scope where included. One-time. | Length of any parallel run, who owns the post-import FQDN and login steps, and the cutover plan for customers. |
| Zammad support subscription | Self-hosted Zammad has no license fee, but a vendor support subscription is optional and changes response commitments after go-live. | Zammad vendor for support. Recurring, billed per the subscription. | Whether a Zammad support subscription is in scope and which response tier applies to your environment. |
What usually goes wrong in a Freshdesk to Zammad move
Most of these risks surface only after agents and customers start using the new system. Each one has a specific check and a named owner, so the team can close it before cutover. Assign the owners and sequence the checks in the migration plan before the first test import.
FQDN left unset after import
The migrator may skip the setup wizard, so the system FQDN is never saved during setup. Zammad then builds login links, notification emails and ticket URLs from an empty or wrong host name. After import, the Zammad administrator should set the FQDN in system settings, then confirm it by signing in from a clean browser and opening a ticket link from a test notification. Owner: Zammad system administrator.
Progress misread in steps of 100
During a Freshdesk import, Zammad does not show a total object count and advances in steps of 100. A counter that appears stalled may still be running, and a finished-looking count may not match Freshdesk. Before the test, record object counts per type in Freshdesk (tickets, contacts, companies, agents and groups), then reconcile each type against the import log after the run. Owner: migration lead, with the Freshdesk administrator confirming the source counts.
API access missing or limited
The migrator reads data through the Freshdesk API, so the API key must belong to an account with enough rights to read every object type in scope. A plan or role that restricts API access can cut the import short or leave out history and attachments. Confirm in writing with the Freshdesk account owner which plan includes API access and which rate limits apply, then run a small test pull before scheduling the full import. Owner: Freshdesk account owner, with the migration lead.
Automations and SLAs assumed to carry over
Freshdesk automations, SLA policies, macros and custom ticket fields should not be assumed to transfer as working logic. Teams that expect escalation timers or routing rules to keep running may find them missing on the first day of live use. Export the active automations and SLA policies from Freshdesk, map each one to a Zammad trigger, scheduler job or overview, and test each rule before cutover. Owner: support operations lead.
Email routing and customer links at cutover
Inbound mail still pointing at Freshdesk, forwarding rules nobody updated, and customer emails that link to Freshdesk ticket URLs all break when the old system stops receiving mail. List every inbound address and forwarding rule, set the order of the mail routing change in the cutover plan, and send a test message to each channel once the change is live. Owner: email administrator, with the migration lead.
Freshdesk changes during the test window
Tickets, contacts and agents keep changing in Freshdesk while a test import runs, so the test result is a snapshot. Records updated after the test pull will be missing or stale in Zammad. Limit agent edits to an agreed scope or keep a change log, re-check the affected object types before the final cutover, and assign one person to sign off the final set of changes. Owner: Freshdesk administrator and migration lead, jointly.
Questions teams ask before moving from Freshdesk to Zammad
How much does a Freshdesk to Zammad migration cost?
The cost is mostly labor and infrastructure, not software licensing, because self-hosted Zammad has no license fee. The main one-time costs are planning, the migration itself, testing, and hosting setup in your environment. The main recurring costs are hosting, operations, and any support subscription you choose. Migration effort rises with ticket volume, attachment size, custom ticket fields, the number of groups and agent roles to map, and the number of integrations to rebuild. Ask for a quote built from a written scope that lists the data types, the mapping decisions, the test rounds, and what is delivered. Compare that quote against the support subscription options on the Zammad pricing page, which lists annual prices for self-hosted support tiers.
Does self-hosted Zammad have a license fee?
No. Self-hosted Zammad has no license fee, and Zammad is licensed under the GNU Affero General Public License version 3. Zammad sells self-hosted support subscriptions separately. The Zammad pricing page lists the Business tier at 2,999 EUR per year, Enterprise at 5,999 EUR per year, and Corporation at 9,999 EUR per year, with response times of 6, 4 and 2 hours respectively. Hosted plans are a different model and are billed per agent per month. Confirm current figures on the Zammad pricing page before you build a budget, because prices can change. A support subscription is optional, so decide whether your team needs vendor support in addition to any partner or internal support you already plan to use.
How long does a Freshdesk to Zammad migration take?
Duration depends on how much data you move, how complete your mapping decisions are, and how many testing rounds your team needs before cutover. Import time grows with the number of objects, but Zammad does not display a total during a Freshdesk import. It counts progress in steps of 100, so your team has to estimate remaining work from those steps. Plan time for a test import on a copy of your data, a review of the results, a second import with corrections, and the cutover window. Ask any provider for a timeline that is tied to the written scope and to a test import on your own volume, not a generic figure. Use the Freshdesk migration documentation from Zammad to confirm which steps are required.
What access and information does our team need to provide?
Your team provides access, decisions, and people. Freshdesk admin access is needed to export data and to create or confirm API credentials with the permissions the migrator requires. You also need a hosting environment for Zammad, a fully qualified domain name, and a plan for email channels. Mapping decisions cover Freshdesk groups, agent roles, statuses, priorities, custom fields, company records, and how customer accounts will be created in Zammad. Testers from support, operations, and any team that reads ticket history should be named in advance. Confirm in writing who signs off each mapping decision and who approves cutover, because late changes to mapping are the most common reason for rework.
Can an internal team run a Freshdesk to Zammad migration alone?
An internal team can do it if it has people who can run Zammad in production and who can work with the Freshdesk API. Those skills include Linux administration, PostgreSQL, Redis, a reverse proxy, and Zammad application administration. The team also needs time for mapping workshops, test imports, data checks, and cutover planning, which often take more effort than the import itself. After the import, the migrator may skip the setup wizard, so someone must set the fully qualified domain name and complete the initial configuration. Decide before you start who owns each task, who handles rollback, and who supports agents on the first day. If any of those roles are unclear, a fixed-scope engagement can cover the parts your team does not want to carry.
Can a Freshdesk to Zammad migration avoid a parallel run?
It is possible to plan a migration without running Freshdesk and Zammad side by side for long, but you should confirm the exact behavior in the Freshdesk migration documentation before you commit to that approach. The main risk is tickets created or changed in Freshdesk after your last export. Those changes need a delta plan, a freeze window, or a final import that your team has tested. A short cutover window usually needs a clear freeze on new Freshdesk work, a final export, verification of record counts, and a switch of email routing and DNS. Write down the rollback step for each stage. If the documentation does not support the delta step you need, plan the cutover around that limit.
What happens to Freshdesk data after cutover?
The migration copies data into Zammad, and the original Freshdesk data stays in Freshdesk until you change or remove it. Do not cancel your Freshdesk subscription or delete data until agents and reviewers have verified the imported records and you have a retained export. Decide how long Freshdesk stays available in read-only form, who approves its removal, and how you will meet your own records retention requirements. Review your Freshdesk contract for data export and deletion terms, and confirm them with Freshdesk. Keep a documented copy of the export, the mapping decisions, and the verification results, so auditors and internal reviewers can see how the data was moved.
How does DeployOpen help with a Freshdesk to Zammad move?
DeployOpen plans, implements, integrates, documents, and supports self-hosted open-source platforms inside your own cloud accounts, data centers, or air-gapped networks. For a Freshdesk to Zammad move, that can include the Zammad environment, the migration plan, mapping workshops, test imports, the fully qualified domain name and login setup after import, and documentation for your team. Most engagements are fixed-scope, with the scope, deliverables, and timeline agreed in writing before work starts. Ongoing support, upgrades, and testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to list which migration steps are included and which remain with your team.
How DeployOpen scopes, delivers and supports a Zammad migration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including this Freshdesk to Zammad move. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
How we scope
- The written scope lists which Freshdesk data types move into Zammad and which are reviewed, mapped or left behind.
- Scoping confirms the Freshdesk API access the migrator needs, and that your Freshdesk plan provides it.
- Scope also sets the target hostname, hosting location and how agents and customers will log in.
How we build
- Stand up a Zammad test instance on PostgreSQL 15 or newer and Redis 7 or newer before any data moves.
- Run a trial import, watch progress in steps of 100, and check tickets, users and attachments against the scope.
- Set the FQDN after import, because the migrator may skip the setup wizard, then test agent and customer logins.
How we hand over
- Documentation covers the migration runbook, the FQDN and login settings, and the steps taken during cutover.
- Agents and customers receive written login guidance, including any password reset steps the cutover requires.
- Handover includes a post-import checklist your team signs off on, covering tickets, attachments and login.
How we support
- Ongoing support, upgrades and testing are available as a retainer after the cutover.
- Support can cover Zammad upgrades and patching in your infrastructure, planned against the Zammad release notes.
- Retainer scope, response expectations and any service levels are agreed in writing, so confirm them before signing.
