What a Zammad migration involves
Teams move from Zendesk, Freshdesk or OTRS to self-hosted Zammad for a few recurring reasons: they want to remove per-seat subscription fees for a helpdesk they already run, they need the ticket data to stay in infrastructure they control, and they want to retire a separate tool or two by consolidating email, chat, forms and phone into one platform. Zammad is licensed under the GNU Affero General Public License version 3, so the software itself carries no license fee when self-hosted. The migration cost is therefore mostly staff time, infrastructure and any support subscription you choose, which is why the scope of the data move matters so much.
The scope covers tickets with their articles and history, users, organizations, groups and attachments. Zammad includes built-in migrators for Zendesk, Freshdesk, Kayako and OTRS. For any other system, the data has to go through the Zammad API or through custom development. Before anyone runs an import, confirm with the source vendor and in your own environment which objects you can export, how attachments are delivered, and whether custom fields, macros, triggers and SLA rules will be recreated by hand. Those rebuilt items are often the largest unplanned task.
The short answer is that a team with a strong Zammad administrator and a small, clean data set can often migrate in-house, using a staging instance, a test import and a documented checklist. Larger ticket histories, many connected integrations, data that needs reshaping before import, or a hard cutover window that cannot slip usually justify bringing in a partner. Ask any partner for a written scope that names each object type, the migrator or API route used for it, the test rounds planned, and who signs off the cutover.
Decision point: before choosing a route, count your tickets, attachments and agents, list the integrations that write to or read from the current helpdesk, and note when the old system must be switched off. Those four facts usually decide whether the work stays in-house.
What the work includes
A Zammad migration runs as a sequence of work packages, each with a defined output. The cards below cover what we plan and build, and the deliverables you receive at the end.
Source assessment and data inventory
We inventory tickets, users, organizations, attachments, macros, triggers, SLAs and integrations in Zendesk, Freshdesk or OTRS to decide what moves, what gets archived and what is retired. Confirm early whether attachment volume and ticket history length will affect import duration and storage sizing on your target.
Target design for groups, roles and channels
We design the Zammad groups, roles, channels, custom object attributes and organization model that replace the source system's structure. Decisions made here determine how the migrator maps agents, customers and ticket states, so they should be signed off before any test import runs.
Infrastructure prerequisites for the Zammad stack
We prepare the target stack: PostgreSQL 15 or newer, Redis 7 or newer for realtime websocket communication, a supported reverse proxy (Nginx or Apache), and Elasticsearch where search and attachment search matter. Check sizing, backups and network access to the source system before the first test run.
Running the migrator
We run the built-in Zammad migrators for Zendesk, Freshdesk, Kayako and OTRS, or the Zammad API for other systems, against a non-production instance first. Each run is logged so that a failed batch can be rerun without duplicating records.
User and permission mapping
We map source agents, administrators and end users to Zammad roles and group access, and decide how duplicate customer identities are merged. Confirm who owns each mapping decision, because wrong role assignment is a common cause of agents seeing tickets they should not.
Reconciliation of counts and samples
We compare record counts by object type and check randomly selected and high-value tickets field by field against the source. Discrepancies are logged with a cause and an agreed resolution, and the reconciliation report is the evidence base for cutover approval.
Test cycles and sign-off
We run repeated test migrations with your business users to validate workflows, triggers, macros, SLAs and reporting. Test sign-off is recorded against defined acceptance criteria, so go-live is approved against documented results rather than informal agreement.
Cutover runbook and hypercare
We write the step-by-step cutover runbook covering the final delta import, DNS and email routing changes, freezing the source system and rollback criteria. Hypercare follows go-live with a defined window for triaging migration defects and reviewing reconciliation exceptions.
What drives effort and duration
This table lists the factors that change how much work a Zammad migration from Zendesk, Freshdesk or OTRS involves, why each one matters, and how to keep it manageable; ask for a written estimate per driver.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Ticket and attachment volume | Every ticket, article and attachment is read, transformed and imported, and large attachment sets extend import runs and storage planning. | Agree a retention cut-off in writing, archive old tickets outside Zammad, and ask the team to size attachment totals from the source export before scoping. |
| History depth and closed tickets | Keeping years of closed tickets multiplies import time, verification work and search index rebuild effort. | Decide which closed-ticket age ranges must be live, and move older records to read-only archive exports. |
| Custom fields and ticket states | Each source field and state must map to a Zammad object attribute or state, and unmapped values need decisions from business owners. | Inventory fields and states early, retire unused ones, and sign off the mapping table before any test import. |
| Agents, customers and duplicate accounts | User records, roles and identities must be matched, and duplicate customer accounts create merge work and wrong ticket ownership. | Deduplicate the source user list before export, define agent roles in advance, and agree rules for matching customers by email address. |
| Organization hierarchy | Organizations, domains and parent-child relationships must carry over so customer context and permissions stay correct. | Document the hierarchy as it is used today, remove stale organizations, and confirm which levels Zammad needs to represent. |
| Email channels and inbound routing | Mailboxes, forwarding rules and inbound addresses must move so new tickets reach the right group after cutover. | List every address and forwarding rule, plan a dated switch of mail routing, and test inbound and outbound mail in a staging environment. |
| Integrations, macros and triggers | Each integration, macro and automation built on the old tool needs rebuilding, replacing or retiring, and this is often the largest unplanned task. | Export a list of active automations, rank them by business use, and decide which to rebuild, replace or drop before design starts. |
| Multiple brands and groups | Separate brands, inboxes or groups add mailbox, group and permission configuration and more cutover checks. | Consolidate groups where possible and confirm each brand's sender identity and templates before the build. |
| Source data quality | Broken references, malformed emails, encoding faults and missing fields slow the import and create manual correction work. | Run a data quality scan on the export, fix known defects at the source, and set rules for records that are skipped or corrected. |
| Environments and test cycles | Each test import needs a clean target, and every rerun repeats validation, so more cycles mean more effort. | Agree the number of environments and test cycles up front and use a fixed reference export for repeatable runs. |
| Compliance evidence requirements | Records of data transfer, retention, access changes and sign-off may be required by your assessors, adding documentation and reconciliation steps. | Ask your assessor what evidence they expect, define it in the scope, and collect it during testing rather than after cutover. |
| Target edition and hosting model | Infrastructure choices, such as single or multi-instance deployment and the support tier, shape how the import is run and tested. | Fix the hosting model and edition in the written scope, and confirm with Zammad which migration method applies to your source version. |
Migration phases and outputs
The sequence moves tickets, users and organizations into Zammad in controlled passes, so each phase closes with a documented output before the next one starts.
Inventory the source data
The team reviews the Zendesk, Freshdesk or OTRS instance to count ticket volumes, attachments, users, organizations, groups, custom fields, macros, triggers, automations and integrations. Each object type is classified as migrate, rebuild or retire. The output is a signed data inventory and a list of source-side owners for every category.
Design the target model and mappings
Source states, priorities, groups, roles and custom fields are mapped to Zammad equivalents, and gaps are decided in writing. Agent and customer roles, organization assignments and channel addresses are defined. The output is an approved field and object mapping document that the migrators and any API scripts will follow.
Build the non-production environment
DeployOpen installs Zammad in your infrastructure with the database, cache, search and reverse proxy your design calls for, matching the production layout as closely as practical. Identity and mail connections are configured for testing. The output is a working staging instance, a build record and access for the client team.
Run a trial import
The chosen migrator, or the API for other sources, loads a copy of the source data into the staging instance. Import logs, errors and skipped objects are captured for each run. The output is a trial import report that lists counts by object type and every rejected record with its cause.
Reconcile and fix in cycles
Counts, sample tickets, attachments, timestamps, ownership and customer links are compared against the source. Mapping or script fixes are applied and the import is repeated until the agreed reconciliation criteria pass. The output is a reconciliation log showing each discrepancy, its resolution and the final passing run.
Validate with agents in acceptance testing
Named agents and supervisors work through their real queues on staging, covering search, macros, triggers, SLAs, notifications and reporting. Defects are logged and triaged against the scope. The output is a signed acceptance record listing accepted behavior, open items and any agreed exceptions.
Cut over to production
Ticket creation is frozen on the source, a final delta import captures changes since the last run, and DNS, mail routing and channel endpoints are switched to Zammad. Post-switch checks confirm inbound email, outbound notifications and logins. The output is a cutover runbook record with timestamps and validation results.
Support the team through hypercare
For an agreed period set in the written scope, DeployOpen monitors logs, queues and mail flow, resolves migration-related defects and helps agents adjust to the new workflows. Source access is kept for reference as agreed. The output is a closure report confirming handover to your support owners.
What teams keep in-house and what they outsource
This table shows which parts of a Zammad migration from Zendesk, Freshdesk or OTRS usually stay with the internal team and which are commonly handed to a partner, with the skills each part needs.
| Work part | Usually in-house or outsourced | Skills needed |
|---|---|---|
| Source system access and export | In-house, with partner support on export scripts | Admin rights on the source helpdesk, API tokens, data privacy approval for exported records |
| Business rules for ticket states and SLAs | In-house, partner documents and tests | Service owners who know current escalation paths and SLA targets |
| Agent and admin training | In-house, partner may supply materials | Team leads who can teach their own queues and macros in Zammad |
| Final sign-off on data | In-house only | Data owners who can judge completeness of tickets, customers and organizations |
| Zammad installation and reverse proxy setup | Often outsourced if the team lacks Linux and proxy experience | Linux administration, Nginx or Apache, TLS certificates |
| Migrator runs and reconciliation scripting | Usually outsourced for the first run, then shared | Ruby on Rails knowledge for Zammad, SQL, log analysis, record counting across systems |
| API-based imports from other systems | Outsourced when the source is not one of the built-in migrators | REST API design, authentication, rate limiting, field mapping |
| Cutover coordination and email routing | Shared, with the internal team owning mail records and DNS | MX and DNS changes, mail flow testing, change windows agreed with the business |
| Post-cutover support | In-house for daily work, partner optional for a defined period | Helpdesk operations, PostgreSQL and Redis monitoring, patch handling |
What usually goes wrong
Most Zammad migrations from Zendesk, Freshdesk or OTRS fail at the edges: exported data, identities, mail routing and the moment of cutover. Each risk below has a prevention step to agree before the first import runs.
Missing attachments and inline images
Attachments and images embedded in ticket bodies can be dropped or left pointing at the old tool's URLs when the export is incomplete or access to the source file store is restricted. Check a sample of tickets with attachments on both sides, and confirm with your migration lead how inline images are rewritten before you sign off the import.
Duplicate users and organizations
Repeated test imports, or a second run after a partial failure, can create duplicate customer accounts and organizations that split a customer's ticket history. Plan a clean target instance for each run, match identities on a stable key such as email address, and compare user and organization counts against the source after every import.
Ticket states and priorities that do not map
Source statuses, priorities and custom fields rarely line up one to one with Zammad's states and priorities, so tickets can land in the wrong queue or lose meaning. Write the mapping table before the first run, agree it with the support leads who use the queues, and check a sample of closed and pending tickets afterwards.
Lost time and SLA history
Response and resolution timestamps, reopen counts and SLA breach history may not carry over in a form that reporting can use, which breaks historical service-level reports. Ask the vendor or migration lead exactly which timestamps are imported, and decide with the service owner whether history is archived in the source tool and kept for reference.
Mail forwarding not changed at cutover
If MX records, forwarding rules or connector routes still point to the old helpdesk, new customer emails keep landing in the retired tool after go-live. Use a mail routing checklist that lists every inbound address, group mailbox and forwarding rule, and confirm each one routes to Zammad with a test message before the old system is closed to new mail.
API rate limits and plan limits during export
Exporting large histories through a source tool's API can hit rate limits or plan-level restrictions, causing partial pulls, throttling or failed jobs that run for days. Ask the source vendor for your current limits, schedule exports in windows that fit them, and keep a frozen copy of the source export so a retry never depends on live access.
Undocumented triggers and automations
Automations in the old system, such as routing rules, auto-replies, escalation macros and webhook calls, are often unknown to the people who depend on them. Inventory every active rule and integration with its owner before cutover, then rebuild the ones still needed as Zammad triggers and test each one against real ticket scenarios.
Search not indexed after import
Imported tickets and attachments do not appear in search results if the search index is not rebuilt once the data is in place. Where Elasticsearch is used, schedule an index build after the final import, then search for known ticket numbers, customer names and attachment text to confirm results return.
No agreed rollback point
Without a defined point of no return, teams cannot decide whether to revert to the old tool when problems appear during cutover, and new tickets end up split across both systems. Agree the rollback trigger, the last safe time to restore the source, and who makes the call, then rehearse the full cutover on a copy before the production date.
How the work changes by starting point
Both sources are hosted helpdesks, so the first task is getting a complete, approved export out of the vendor account before any mapping starts. Zammad includes migrators for both, but export formats and supported objects differ, so confirm them in the Zammad migration documentation for your source version.
- Mapping: Map agents, groups, roles, organizations and custom ticket fields to Zammad groups, roles and custom object attributes. Decide how source statuses and priorities map to Zammad states.
- Testing: Run the migrator against a staging instance and spot-check closed tickets, tickets with attachments and customer records.
- Cutover: Decide whether all history is migrated or only a defined window, and plan a delta run for tickets created during testing.
- Data handling: Record who holds the export file and where it is stored while it moves to your environment.
OTRS and Kayako installations are often self-hosted and heavily configured, so the source database and its customizations usually matter more than the standard export. Older data models and custom schema can fall outside what the built-in migrator expects. Confirm which OTRS and Kayako versions the migrator documentation covers before you commit to a method.
- Schema review: Inventory custom dynamic fields, queues, states, priorities and any direct database changes before choosing an extraction method.
- Mapping: Map each custom field to a Zammad custom object attribute, or decide to archive it outside the helpdesk.
- Testing: Compare record counts per object type between source and target, and test tickets with long histories and many articles.
- Cutover: Freeze source changes for the final extract and confirm the pre-extraction database backup can be restored.
When the source has no built-in migrator, the Zammad API is the main route, and most of the effort is custom development. Zammad documents that other systems can be imported through its API or through custom development, so put that scope in writing before work starts.
- Mapping: Write a field-level map for tickets, articles, users, organizations, attachments, tags and timestamps, including how original authors and ownership are preserved.
- Build: Treat the import code as a maintained asset with version control, reruns that do not create duplicates, and logs of failed records.
- Testing: Confirm any limits the API enforces on request rates and attachment sizes, and verify that imported timestamps match the source.
- Cutover: Capture records created after the final extract, then retire the import credentials once the switch is complete.
The deployment model changes where the import runs, how storage is sized and who supports each layer. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, and its Kubernetes support covers only the Zammad application, not the cluster itself.
- Kubernetes: Storage, ingress and scaling choices in the Helm chart affect where attachments live and how long the import job runs. Cluster-level issues stay with your platform team or cluster provider.
- Multi-instance: Container and cluster deployments need Memcached in addition to Redis, so confirm the cache design before running imports across several instances.
- Compose or package: A single node keeps the import path simple and uses the file system cache, but you must plan disk space for the export, attachments and search indexes.
- Cutover: Confirm the search index is rebuilt after import and that search services are sized for the imported volume.
In restricted networks, the export leaves the source system on approved media and enters the target through a controlled path. The migration runs entirely inside the enclave, so every package, container image and dependency must be staged in advance.
- Transfer: Agree the approved media, a transfer log, checksums and the person who signs off each import file.
- Staging: Mirror installation packages or container images and migrator dependencies into the enclave before the migration window.
- Data handling: Confirm whether exports and attachments contain personal or regulated data, and apply the classification rules that cover the media and the target.
- Testing and cutover: Run the migration and verification on an enclave copy, and plan a second approved transfer for data created during testing.
What you need to provide
Before we scope a Zammad migration from Zendesk, Freshdesk or OTRS, we need six things from your side: admin access to the source tool with export rights, a data inventory or sample export, a decision on where Zammad will run, named business owners, a list of integrations and automations, and agents for test cycles. Access comes first. Ask your current helpdesk administrator to confirm that the export role can read tickets, articles, attachments, users, organizations, groups and custom fields, and to check whether attachment storage sits in the platform or in an external bucket.
Business owners should sign off on the data model before any import runs. That means the ticket states and pending reasons you actually use, which SLAs must carry over and how they map to Zammad settings, which groups and roles exist, and which closed tickets are obsolete. Ask your support leadership to agree the data retention and deletion rules in writing, including whether personal data from old tickets moves at all. Your compliance lead should sign off on any retention requirement that applies to your sector.
Your team must also control the email domain and DNS records, because inbound and outbound mail routing changes at cutover. Confirm who can edit those records and how quickly changes take effect. Agree a cutover window with support leadership so that agents are not handling live tickets in two systems at once. Expect agents to test imported tickets in a staging instance across more than one cycle, and name the people who will do that work and approve each test result.
Frequently asked questions
How much does a Zammad migration from Zendesk, Freshdesk or OTRS cost?
The cost follows the written scope, so no single price applies to every migration. Effort rises with ticket and attachment volume, the number of source systems, how much custom field, group and workflow mapping is needed, and how many test rounds you require. Self-hosted Zammad has no license fee, so the cost is the implementation work, plus any infrastructure and support you choose. The drivers section on this page explains each factor. Ask for a quote that lists the migration, test cycles, cutover support and any integrations as separate line items.
How long does a helpdesk migration to Zammad take?
The schedule is set in the written plan once the scope and data volumes are known. Duration depends on how much history you move, how many test cycles your teams need, how long sign-off takes, and whether integrations must switch over at the same time. Your source system keeps receiving tickets until cutover, so a final incremental load is usually planned for the cutover window. Ask for a timeline with named milestones and a list of the dependencies that sit on your side.
Are the built-in Zammad migrators enough for Zendesk or Freshdesk data?
The built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, which handles many standard setups. They may still need mapping work for custom fields, workflows, organizations or unusual data structures. Systems outside that list can be imported through the Zammad API or through custom development. Before you decide, run the migrator against a sample export from your own source version and review the results with your agents.
What happens to attachments and ticket history during a Zammad migration?
What arrives in Zammad depends on what each migrator imports from your source version, so confirm it in a test run before cutover. Check ticket articles, internal notes, timestamps, customer and organization links, and attachments separately. Large attachment sets increase storage needs and migration time. Searching attachment content requires Elasticsearch, which is optional but strongly recommended, so ask your engineers how the search index is built after the data load.
Can the old helpdesk stay read-only after cutover to Zammad?
It can, if the source product offers a read-only or restricted setting for your plan, and you should confirm that option with its vendor before cutover. Keep the old system available for reference, export an archive for retention, and stop routing new inbound email to it so new tickets land only in Zammad. Write retention rules, legal holds and any audit access into the cutover plan so the old system's status is documented.
What does our team need to prepare before a Zammad migration starts?
Start with access, decisions and people. Your team should prepare:
- Admin access and a test export from the source system
- Decisions on groups, roles, SLAs, custom fields and which closed tickets to move
- Named testers and a sign-off owner for each team
- Target infrastructure for PostgreSQL, Redis and, if used, Elasticsearch
- An email channel plan, including mailbox routing and DNS changes
- An agreed cutover window and a rollback plan
How DeployOpen scopes, delivers and hands over a migration
DeployOpen plans and runs Zammad migrations from Zendesk, Freshdesk or OTRS inside infrastructure you control, starting from a written scope that names the source data, the target Zammad instance and the cutover approach. The work covers the built-in migrators, test imports, cutover and the documentation your team needs to run the result.
How we scope
- Inventory tickets, users, organizations, groups and attachments in the source system before choosing a migrator
- Record which source objects map to Zammad roles, groups, organizations and custom object attributes
- Agree in writing which data is moved, which is archived and which is left behind, and the cutover window
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
How we build
- Stand up the target Zammad environment with PostgreSQL 15 or newer and Redis 7 or newer in your infrastructure
- Run the Zendesk, Freshdesk or OTRS migrator against a copy of the source data in a test instance
- Check imported ticket counts, attachments, timestamps, agent assignments and customer links against the source
- Use the Zammad API for any source system outside the built-in migrators, and document each mapping decision
How we hand over
- Run a rehearsed cutover with a documented rollback path and a named owner for each step
- Deliver mapping records, import logs, reconciliation reports and the runbook used for the production import
- Document the configuration, integrations and any custom scripts so your team can maintain them after go-live
- Walk your administrators through daily operation, upgrades and where the migration artifacts are kept
How we support
- Support after go-live can be provided as a retainer covering Zammad upgrades, patches and follow-up fixes
- Retest imports and integrations when Zammad minor or security releases change the application
- Confirm with Zammad which support subscription, if any, fits your team, since self-hosted use has no license fee
- Agree the support boundary, response expectations and ownership of the Elasticsearch and database layers in the written scope
