How to migrate from Zoho Desk to Zammad without a built-in migrator
If a renewal, per-user pricing or a data residency requirement has pushed you toward self-hosting, know this first: Zammad has no Zoho Desk migrator, so the move is a custom import from a Zoho Desk backup. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk only. The work is usually led by an IT or support platform team, often with help from an implementation partner who has done Zammad imports before. The effort and risk sit in three places: extracting the data from Zoho Desk, moving attachments, and mapping your Zoho structure onto Zammad. The backup is a ZIP of CSV files, and it does not include the attachment files themselves, so you will need to fetch those separately through the Zoho Desk API. You then load tickets, articles and contacts through the Zammad API, or commission custom development from Zammad if the volume or the mapping is complex. Confirm with Zammad and with your own Zoho admin what the API rate limits and token permissions are before you estimate timelines, because neither is a figure this page can give you.
Plan the mapping before any data moves. Decide how Zoho departments map to Zammad groups, how Zoho teams and agent roles map to Zammad roles, and how your Zoho SLAs and escalation rules will be rebuilt in Zammad's own SLA and trigger settings. Some Zoho behavior may have no direct equivalent, so list those gaps and agree how each will be handled before cutover. Run a test import on a non-production Zammad instance, check ticket counts, threads and attachments against the source, and only then schedule the final load. Keep the old Zoho Desk account readable until you have verified the migrated data and have an archive of the backup. Ask any implementation partner for a written scope that names the import method, the attachment handling, the test plan and the acceptance checks, since that document, not a generic price, is what you will compare across quotes. The Zammad migration documentation is the natural starting point for your own team.
Which Zoho Desk capabilities map cleanly to Zammad
This table maps each Zoho Desk capability in scope for the move to its nearest Zammad equivalent and rates how cleanly the data or setting carries across. Read status as clean, needs rework or gap, and confirm SLA, automation and AI feature parity in the Zammad version you deploy before you commit to a design.
| Zoho Desk capability | Zammad equivalent | Migration status |
|---|---|---|
| Ticket history and threads | Zammad tickets, articles and ticket history | Needs rework: no built-in Zoho Desk migrator, so import through the Zammad API or custom development |
| Contacts and accounts | Zammad customers and organizations | Needs rework: map contact fields and decide how duplicate customers are merged |
| Attachment files | Zammad ticket and article attachments | Needs rework: fetch files through the Zoho Desk API, since they sit outside the CSV backup |
| Knowledge base articles | Zammad knowledge base, if enabled in your version | Needs rework: confirm the feature set, then rebuild categories and article structure |
| Departments and teams | Zammad groups and agent roles | Needs rework: map each department to a group and agree agent permissions before import |
| SLAs and escalation rules | Zammad service level and escalation settings | Needs rework: confirm SLA parity in your version, since calendars and targets rarely copy directly |
| Automation, workflows and macros | Zammad triggers, macros and overviews | Needs rework: rebuild each rule manually and test it, because logic does not transfer automatically |
| Channels (email, web form, chat, social) | Zammad email channels, web forms and available integrations | Needs rework: confirm each channel exists in your version and set up mailboxes again |
| Reporting and dashboards | Zammad reporting, which uses Elasticsearch | Needs rework: rebuild reports and confirm that Elasticsearch is in the target design |
| Single sign-on | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab login | Clean: supported third-party login methods are available, so confirm your identity provider setup |
| AI features | Confirm available AI functions in your Zammad version | Gap: do not assume equivalence; confirm each Zoho Desk AI feature you use before planning |
What Zoho Desk data can leave the platform and what must be rebuilt
Zoho Desk's documented backup gives you a starting inventory of tickets, threads, contacts and knowledge base articles, but it does not hold everything a support operation depends on. The cards below separate what the export carries, what needs a separate API pull, and what has to be configured again in Zammad before cutover.
The CSV backup as inventory
The backup arrives as a ZIP of CSV files covering tickets, threads, contacts and knowledge base articles. Treat it as the inventory you reconcile against, not as a finished import set. Count records per file, compare them with the live Zoho Desk views for the same period, and note which ticket IDs need to stay stable so that threads, contacts and articles link correctly after import.
Forum topics stay outside the export
The backup does not include forum topics. If your community content matters to customers, decide early whether it moves into a knowledge base article, a separate archive or a Zammad-hosted solution. Ask Zoho Desk support which forum content can be exported by other means, and record the answer, because this affects the scope and timeline of the migration.
Attachments need the Zoho Desk API
Attachment files are not part of the CSV backup, so they must be retrieved through the Zoho Desk API and matched to the ticket and thread records they belong to. Confirm the API scopes your account can grant, plan for rate limits on large attachment sets, and check that every attachment reference in an imported thread resolves after the move.
User accounts and passwords
Agent and customer passwords are not part of the export, so plan for every user to sign in to Zammad under a new credential or through a federated login. Map each Zoho Desk agent role to a Zammad role and group before import, and confirm with your migration partner or Zammad how the import path handles user records and email addresses that already exist.
SSO through SAML or OpenID Connect
If your organization signs agents in through a central identity provider, configure SAML or OpenID Connect in Zammad before the cutover window. Zammad also supports Microsoft, Google, GitHub and GitLab logins. Test the sign-in path with a pilot group of agents and confirm that group membership from the identity provider maps to the correct Zammad roles.
Mail routing, apps and automations
Zoho Desk integrations, third-party apps, inbound and outbound mail routing, and automation rules do not move with the data. Inventory every Zoho Desk mailbox, forwarding rule, webhook and connected app, then rebuild each one in Zammad, including its email channels, DNS records and triggers. Test inbound routing with live mail before you change any production forwarding rules.
The migration sequence from inventory to decommission
The sequence turns a Zoho Desk help desk into a tested Zammad instance and a documented cutover, with each step producing an artifact the next one depends on. Because Zammad's migrators are all or nothing and only run on a new instance, the pilot and the final import must be repeatable from the same inputs.
Inventory departments, teams, SLAs and mailboxes
Your support lead and a Zoho Desk administrator list every department, team, agent group, SLA policy, automation rule, channel and inbound mailbox, then record which of them each one maps to in Zammad. Work out in advance how Zoho Desk departments and teams translate to Zammad groups and roles, and which SLAs need to be rebuilt by hand in Zammad. The output is a signed-off mapping sheet, and the step is done when every active mailbox and channel has a named owner and a target.
Export the Zoho Desk backup
A Zoho Desk administrator runs the backup from the admin console and downloads the ZIP of CSV files, which hold tickets, threads, contacts and knowledge base articles. Confirm with Zoho which content is excluded, such as forum topics and attachment files, and plan to fetch those separately. Store the archive in a restricted location with a checksum, since it contains personal data. The step is done when the archive opens, row counts match Zoho Desk reports, and the export date is recorded.
Extract attachments through the Desk API
Because the CSV backup does not contain attachment files, a developer uses the Zoho Desk API with a token scoped to read tickets and attachments to download each file and store it next to its ticket ID. Confirm the API scopes, rate limits and token lifetime for your Zoho data center and plan before writing the script. Keep a manifest that links each attachment to its ticket and records its size and checksum. The step is done when the manifest count matches the attachment references in the ticket threads.
Build the transformation and import code
Zammad includes no Zoho Desk migrator, so a developer either writes a script against the Zammad API or commissions custom development from Zammad. The code maps customers to Zammad users and organizations, threads to articles, statuses and priorities to Zammad states and priorities, and attachments to their stored files, following the mapping sheet from the first step. Keep the script in version control with a configuration file for each environment. The step is done when a sample of a few hundred tickets imports into a scratch instance and a reviewer confirms field-level results.
Run a pilot on a new Zammad instance
Deploy a fresh Zammad instance with PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, then run the full import against it. Zammad's migrators work only on a new instance and are all or nothing, so the pilot must be repeatable: rebuild the instance from the same deployment definition and rerun the same script with the same inputs. Record the run time, errors and any manual fixes, and have agents test their views, SLAs and notifications. The step is done when two consecutive rebuilds produce identical record counts and the agents sign off on the test cases.
Run the production import and a parallel period
Freeze Zoho Desk intake for a short, agreed window, take a final backup, and run the same tested script on a clean production instance. Keep Zoho Desk open for new tickets and compare both systems during the parallel period, so that agents and reporting can be checked against each other. Document every difference and decide whether it needs a fix or a note to the team. The step is done when the count and sample checks match and the support lead approves moving to cutover.
Cut over mailboxes and channels
Change the MX records, forwarding rules or connector settings so that inbound mail, web forms and any API integrations point to Zammad, and update the customer-facing support addresses and links. Verify inbound and outbound email with test messages from each channel, and confirm that replies thread correctly with the migrated history. Plan a rollback path that restores the previous routing if a channel fails. The step is done when every mailbox in the inventory receives and sends through Zammad and the change record is closed.
Decommission Zoho Desk after the read-only period
Once cutover is stable, confirm with Zoho the dates on which your Zoho Desk subscription ends and the account moves to read-only or closes, and retain the final backup under your records policy. Remove API tokens, webhooks and integrations that point to Zoho, and revoke agent licenses so that no one keeps working in the old tool. Keep the archived backup and the attachment manifest accessible for the retention period your compliance team sets. The step is done when Zoho access is removed, the archive is verified, and the migration record is signed.
How to run Zoho Desk and Zammad in parallel and cut over
The parallel period is where most migrations succeed or fail, so decide its shape before any data moves. Keep new tickets in Zoho Desk while historical data is loaded into a separate Zammad instance on your own servers. Zammad has no built-in Zoho Desk migrator, so the historical load depends on the backup and API route described earlier, and it will be a one-time bulk import. Agree in writing which system is the system of record on each date, and decide how tickets that are open at cutover will be handled: either they are closed in Zoho Desk before the window, or they are recreated in Zammad with a reference back to the original Zoho Desk ticket number. Pick one approach per ticket class and document it for agents.
Plan the channel switchover as a sequence of reversible steps. Start by forwarding a test mailbox to Zammad and confirming that inbound messages create tickets with the right customer, group and state. Then redirect production mail forwarding, web forms and any chat or phone integrations one channel at a time, and keep Zoho Desk receiving mail until each channel is confirmed. Because Zammad's Zendesk migrator does not support differential migrations, the final delta step cannot be an automated top-up of Zoho Desk changes, so any tickets or replies created after the bulk load must be re-exported and imported by a custom script in the same way. Plan that script and its test runs before the cutover window, not during it. Confirm with Zoho the current backup interval and the expiry period of the download link, since both determine how recent your final export can be. Schedule the final export so it finishes inside the window you can afford to keep both systems live.
What drives the cost and duration of a Zammad migration
This table lists the factors that change how much a Zoho Desk to Zammad migration costs and how long it takes, separating one-time migration work from recurring running costs. Read each row as a lever: the driver explains why it matters, and the second column shows how to keep it under control before you request a quote.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Ticket and thread volume | Each exported ticket, thread and contact must be mapped and imported through the Zammad API or custom code, so larger datasets extend test and reconciliation cycles. | Agree a retention cut-off with compliance, archive closed tickets older than it, and import only what agents need to work from. |
| Attachment volume | Zoho Desk backups exclude attachment files, so each file must be fetched separately through the Desk API, then stored and indexed on your Zammad server. | Confirm which attachments are legally required, skip duplicates and very old files, and size storage and Elasticsearch indexing before the trial import. |
| Number of departments and teams | Each Zoho Desk department must map to a Zammad group, with its own roles, agents and routing rules, and each mapping needs review by the owning team. | Consolidate departments before migration, document the target group structure in writing, and limit migration scope to active teams. |
| SLA and automation complexity | Zoho Desk SLAs, escalation rules and workflow automations are not carried over as-is, so each one must be rebuilt, tested and signed off in Zammad. | Inventory every SLA and automation, retire unused rules, and reproduce only the rules that still drive decisions. |
| Mailbox and channel count | Each inbound address, web form, chat or social channel needs its own Zammad channel configuration, email routing and test cases. | Remove dormant mailboxes, consolidate forms, and confirm which channels stay live on day one. |
| Custom fields and layouts | Custom ticket fields must be recreated as Zammad object attributes, and any values pulled from Zoho Desk need type mapping and validation. | Limit custom fields to those used in reporting or routing, and define field types in a shared spreadsheet before development begins. |
| Depth of SSO integration | Connecting Zammad to your identity provider through SAML or OpenID Connect requires attribute mapping, role sync and testing with agents and administrators. | Choose one identity provider, agree the attribute set early, and confirm which login methods Zammad supports in your environment. |
| Team capacity and skills | Migration needs an administrator for the Zoho Desk export, a developer for the API import, a Zammad administrator, and agents for acceptance testing, and shortages extend the schedule. | Name owners for each role before the project starts, and ask the implementation partner to state the staff time it assumes in the written scope. |
| Recurring hosting and services | After go-live, servers, PostgreSQL 15 or newer, Redis 7 or newer, Elasticsearch and Memcached for multi-node setups recur as infrastructure costs, and Zammad support plans named Business, Enterprise and Corporation carry published annual prices of 2,999, 5,999 and 9,999 EUR (Zammad pricing page). | Size components to actual user and ticket load, decide whether a support subscription is needed, and ask for a quote that lists each recurring component separately. |
What usually goes wrong in a Zoho Desk to Zammad migration
Most failed moves from Zoho Desk to Zammad trace back to a few gaps: what the export leaves out, what the target system does not inherit, and how the cutover is timed. Each card names one risk and the step the team can own to prevent it before the import runs.
Attachments missing from the backup
The Zoho Desk backup is a ZIP of CSV files covering tickets, threads, contacts and knowledge base articles, and it does not include the attachment files themselves. Attachments therefore have to be fetched separately through the Desk API and matched back to their tickets. Ask the team who owns that download, confirm the API scope and rate limits with Zoho, and check a sample of tickets for attached files after the import.
SLA and escalation rules left behind
SLA targets, escalation paths and automation rules configured in Zoho Desk do not carry over into Zammad. Zammad has its own SLA and trigger model, so each rule must be rebuilt and tested against real ticket states. List every active SLA, escalation and automation before the export, map each one to a Zammad equivalent or a documented decision to drop it, and have support leads sign off on the map.
Users recreated without passwords
Zammad's Zendesk migrator does not migrate user passwords, and the same limit should be assumed for any custom import from Zoho Desk. Agents and customers arrive as accounts that cannot sign in until they reset access or use a configured single sign-on provider. Decide the login method before cutover, such as SAML or OpenID Connect, and confirm which accounts need a welcome message or a password reset.
Mailbox routing errors at cutover
Inbound email for support addresses keeps flowing to Zoho Desk until the mail routing changes, so tickets can land in two systems during the switch. Plan the cutover with the mail administrator, lower DNS or forwarding time in advance, and test each support address with a sample message. Keep Zoho Desk receiving mail for a defined period and confirm that replies go out from the right sender.
Backup aging before the import
A Zoho Desk export is a point-in-time copy, so tickets created after it are not in Zammad unless a second export runs. Confirm how often backups can be generated on your plan, how long download links remain valid, and whether a final delta run is needed. Set a freeze date for new configuration changes and schedule the last export close to cutover.
All-or-nothing import failing late
Zammad's built-in migrators work only on a new instance, import one source per migration, and are all or nothing, so a failure late in the run can mean starting over. Test the import on a copy of the data first, count tickets, users and organizations after each run, and keep the destination instance empty until the rehearsal passes. Record the time each run takes so the production window is realistic.
How the migration changes by team size and starting point
A small team using Zoho Desk mostly as a shared inbox usually has one or a few mailboxes, few departments and simple routing. The migration scope is narrow: most of the work is the ticket history, the contacts and a short list of mailbox and notification settings to recreate. Because the data volume and configuration are small, the sequence can stay close to a single pass: export, build a test instance, import, check a sample of tickets, then switch mail routing. Attachments still need separate handling, since the Zoho Desk backup does not include the attachment files themselves.
- Mailboxes first: List every inbox, its forwarding address and its signature, then create the matching groups in Zammad before importing anything.
- Contacts and organizations: Check how customer records were stored in the CSV files and decide whether duplicates should be merged before import.
- Attachments: Plan a separate fetch through the Desk API for files, because they are not in the backup archive.
- Cutover: Redirect the support address only after a test ticket flows end to end in the new instance.
- Retention: Confirm how long the Zoho Desk account stays readable after cutover, and keep the export archive.
Confirm with your Zoho Desk administrator which mailboxes are active before you start, since inactive ones are easy to forget.
A multi-department support organization usually has several teams, escalation paths, SLA targets and automation rules that depend on each other. Here the migration is a mapping project as much as a data move. Departments in Zoho Desk have to be translated into Zammad groups and roles, and the SLA and automation logic has to be rebuilt by hand, because a data export does not carry it across as working rules. Expect the sequence to run in stages, with each department validated before the next one moves, so that routing errors do not spread across the whole organization.
- Department map: Document which agents belong to which department, who can see which tickets and who can reassign them, then reproduce that model in Zammad groups and roles.
- SLA rebuild: Write each SLA target in plain terms and configure it again in Zammad. Do not assume an exported setting will work unchanged.
- Automation inventory: List triggers, macros and assignment rules, and mark which ones still matter, since some are often obsolete.
- Staged cutover: Move one department at a time and keep the Zoho Desk history available for reference during overlap.
- Reporting baseline: Record current SLA and volume figures so you can confirm the new reports match before retiring the old ones.
Ask your implementation partner or Zammad contact how custom development would handle any Zoho-specific fields that do not map cleanly.
A team that also needs single sign-on or fast search across its ticket history adds two components to the plan. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers, so identity configuration has to be decided before agents log in. Elasticsearch is optional for Zammad but strongly recommended, because it powers faster search, reporting features and searching email attachment content. Both change the infrastructure and the testing effort, so they belong in the design phase, not as a later add-on.
- Identity provider: Confirm which provider is the source of truth, how agent roles are passed through and how accounts are provisioned and removed.
- Search index: Plan Elasticsearch sizing and the reindex after import, and test searches against the migrated history.
- Attachment search: Decide whether attachment content must be searchable, since that depends on the index being in place.
- Access testing: Verify that group permissions still apply when users sign in through SSO.
- Operations: Assign ownership for the identity connection and the search cluster, since both need patching and monitoring.
Confirm supported providers and the required Elasticsearch version against the Zammad requirements documentation before you commit to a design.
Questions buyers ask before moving from Zoho Desk to Zammad
Does Zammad have a built-in migrator for Zoho Desk?
No. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, so Zoho Desk is not among them. The routes that remain are exporting a Zoho Desk backup of CSV files, fetching attachments through the Desk API, and importing through the Zammad API or through custom development from Zammad. Each route needs mapping work for departments, teams, SLAs and states before any data moves. Confirm the current list of supported sources with Zammad before you plan, because the built-in list is the first thing to check.
What does a Zoho Desk to Zammad migration cost, and what drives it?
Zammad itself has no license fee when self-hosted. The cost sits in the work and the infrastructure. Cost components include the migration engineering (scripts or API import, attachment handling, mapping and test runs), the servers for Zammad with PostgreSQL and Redis, Elasticsearch if you want attachment search and reporting, and the staff who run the system afterward. Costs rise with the number of tickets, the size and count of attachments, the number of departments and SLAs to map, and how much history you keep. Ask any quote to itemize these components and to state what is one-time and what recurs.
How long does the migration take, and what sets the pace?
No duration is fixed by the vendor, so the timeline depends on your data and scope. The main pace setters are the volume of tickets and attachments, the rate limits on the Zoho Desk API, how many departments, teams and SLAs must be mapped and agreed, and the number of test imports needed before cutover. Zammad's documentation notes that migrations are all or nothing and work only on a new instance, so plan for at least one full rehearsal. Ask for a written schedule that lists each phase and the decisions that gate it.
What must our team provide before the migration starts?
Start with a Zoho Desk export and an administrator who can create or approve API access. Your team should also name owners for each department, agree which teams and SLAs carry over, and decide which closed tickets and old history to keep. Engineers need a target server or cloud account, a database and a mail setup for inbound and outbound channels. Business owners must sign off mapping decisions and test results. Confirm these responsibilities in the written scope so that gaps show up before the import, not after.
Can our own team run the migration without an outside partner?
Yes, if you have engineers who can work with the Zoho Desk export format, the Desk API and the Zammad API, and who can run and secure a Zammad installation. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, so the platform itself is accessible. The harder parts are attachment retrieval, mapping rules and repeatable test runs. Zammad's Kubernetes support covers only the application, so your team would own Kubernetes-level issues. Teams without that skill set usually scope an implementation partner for the migration and hand over the runbook.
What happens to attachments and ticket history?
The Zoho Desk backup contains CSV data for tickets, threads, contacts and knowledge base articles, but it does not include the attachment files themselves. Those must be fetched through the Desk API as a separate step, then linked to the imported tickets. Forum topics are also not in the backup. Confirm with Zoho how attachment download limits apply to your plan and whether older history is retained. Build a check that compares ticket counts and attachment counts between source and target after each test import.
Do we need a Zammad support subscription to run the migrated system?
No. Self-hosted Zammad has no license fee, and support subscriptions are optional. Zammad lists Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year on its pricing page. Whether you need one depends on your internal skills, your uptime expectations and how many people can handle incidents. Ask Zammad what each tier includes and compare that with the staff time you would otherwise spend on upgrades, security releases and troubleshooting.
Running Zammad after the move: hosting, upgrades and security releases
Before cutover, settle the hosting stack, because Zammad replaces a managed service with components your team must run. Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime websocket communication, and supports Nginx or Apache as the reverse proxy. Elasticsearch is optional but strongly recommended, since it provides faster search, reporting and searching the content of email attachments. Memcached is needed only when you run several Zammad instances, such as containers or cluster nodes; a single installation can use the file system cache. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers the application only, so the cluster, storage and networking remain your responsibility. Confirm the current requirements in the Zammad software requirements page before sizing hosts.
Plan upgrades as a recurring task, not a one-time setup. Zammad published security releases on both the 6.5 and 7.x lines in parallel, so you may need to patch more than one branch depending on the version you deploy. Decide who watches the Zammad releases page, how quickly security fixes are applied, and which maintenance window each upgrade uses. Take a database and attachment backup before every upgrade, and rehearse the upgrade on a copy of production that includes migrated Zoho Desk data. Confirm with Zammad which version and branch receive security support for your deployment, and whether a self-hosted support subscription changes your response expectations.
Treat the Zammad host as a security boundary that holds customer personal data. Restrict access to the database and Redis to the application tier, terminate TLS at the reverse proxy, and integrate sign-in through a third-party provider such as SAML or OpenID Connect where your identity platform supports it. Keep the migration credentials, including the Zoho Desk API client details, out of the running system once the import is complete. Write down who is on call for the stack, how backups are restored and where logs go, because these duties do not transfer to Zoho when you leave its cloud. Ask your implementation partner to document this runbook as part of the scope.
How DeployOpen scopes, runs and supports the migration
The sequence below turns a Zoho Desk export into a working Zammad instance in your own infrastructure, with a written scope, a tested import and a documented handover. Each step ends with a check you can verify before the next one starts.
Agree the fixed-scope written statement of work
DeployOpen and your team agree in writing on the systems in scope, the Zoho Desk data to move, the Zammad environment, the deliverables and the timeline before any work starts. Your team confirms who holds the Zoho Desk administrator access, which departments, teams and SLAs must map across, and whether attachments and knowledge base articles are included. The output is a signed statement of work that states what is excluded, so the quote follows directly from that written scope.
Inventory the Zoho Desk export
DeployOpen works with your administrator to request the Zoho Desk backup and list what it contains, including the ZIP of CSV files for tickets, threads, contacts and knowledge base articles. The inventory also records what the backup leaves out, such as forum topics and attachment files, and how those items will be retrieved separately through the Desk API. The check is a reconciled inventory that your administrator reviews and signs off, with record counts that match the source.
Map departments, teams, SLAs and roles
DeployOpen maps Zoho Desk departments to Zammad groups, Zoho Desk teams and agent roles to Zammad roles, and SLA rules to Zammad service level settings, using a mapping sheet your service owners approve. Ticket statuses, priorities and custom fields are matched or flagged for a decision. The output is an approved mapping document, and each unresolved item is logged with an owner.
Deploy Zammad in your infrastructure
DeployOpen installs Zammad inside your own cloud account, data center or air-gapped network, using the packaged, Docker Compose or Kubernetes Helm route your platform team selects. The build includes PostgreSQL 15 or newer, Redis 7 or newer for realtime updates, a supported reverse proxy, and, where your deployment needs it, Elasticsearch and Memcached. Zammad support covers the application only, so your platform team keeps ownership of the Kubernetes layer if that route is chosen. The check is a running staging instance with the agreed software versions recorded.
Build and test the import
DeployOpen builds the import using the Zammad API or custom development, because Zammad has no built-in Zoho Desk migrator. Attachments are fetched through the Desk API and linked to their tickets. The team runs the import against a copy and compares ticket counts, timestamps, requesters, comments and attachment links with the source. Known gaps, such as comments that the CSV files omit, are fixed or documented before the pilot.
Run a pilot with a subset of agents
A small group of agents works in Zammad using a migrated subset of tickets and channels, while your service owner checks routing, SLA timers, notifications, knowledge base content and reporting. Third-party login, such as SAML, OpenID Connect or Microsoft, is tested with your identity provider. Issues are logged and fixed in the build. The output is a pilot sign-off record listing accepted behavior and open items.
Cut over, harden and back up
DeployOpen plans the cutover window with your team, runs a final export and import, switches inbound email and channels, and confirms the Zoho Desk export is archived. The production instance is hardened to the agreed configuration and a backup and restore routine is tested, so you can prove recovery before go-live. The check is a successful restore test and a cutover checklist signed by your service owner.
Hand over documentation and offer retainers
DeployOpen delivers runbooks, configuration records, the mapping document, the test results and the restore procedure, and trains the administrators who will run Zammad. Ongoing upgrades, support and continuous testing can be added through a separate retainer agreed in writing. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. The handover closes when your team signs the acceptance record.
