Migrate from Kayako to Zammad: what the move involves
If your support team runs cloud-hosted Kayako and wants to move to self-hosted Zammad, start by confirming two limits. The Zammad Kayako migrator covers cloud-hosted Kayako only, so a self-hosted Kayako Classic installation needs a different route. And custom states, priorities and types from Kayako Scale plans are not transferred, so they must be recreated in Zammad before or after the import. Both limits shape the plan from the first meeting, because they decide what is imported automatically and what your team must rebuild by hand. The effort depends on three things you control. The first is how much custom configuration your Kayako instance carries. Every custom state, priority and ticket type you have added needs an equivalent in Zammad, along with the workflows that depend on them. The second is how much history you keep. Importing years of closed tickets takes longer to validate than importing only open work, and it raises questions about how historical ticket states are displayed. The third is how many integrations must be rebuilt. Email routing, chat channels, forms, phone connections and any Kayako API consumers each need a decision on whether to recreate them in Zammad or retire them. Before you commit to a date, inventory these three areas with the people who own the support workflows. List every custom state, priority and type, record which reports and automations depend on each, and identify which external systems read from or write to Kayako. Confirm with your Kayako administrator that the instance is cloud-hosted and that the API access your plan provides is available to the account that will run the import. Ask your migration partner to show how each item maps in the written scope, so the quote reflects the real work rather than a generic import. Plan for the cutover itself as a business decision, not only a technical one. Agents need time to learn Zammad's ticket model, and customers will continue writing to the old address until email routing changes. Decide which ticket history agents must see in Zammad on day one, and which can stay in an archive. Agree on a freeze window, a rollback path to Kayako and a named owner for each integration that changes during the move. Finally, ask any partner or internal team to document what will not carry over, in writing, before work starts. A clear list of unsupported elements, the decisions still open and the items you must recreate manually gives your leadership team an accurate basis for approving the scope and for comparing quotes.
Which Kayako data maps cleanly to Zammad and which does not
This table compares common Kayako data objects with their Zammad counterparts and notes where the built-in migrator carries data across, where it does not, and where a separate check is needed. Read each row as a starting point, then confirm it against the current Zammad Kayako migration documentation before you plan the import. The main takeaway is that custom states, priorities and types from Kayako Scale plans must be recreated or mapped before import.
| Kayako capability | Zammad equivalent | Migration notes |
|---|---|---|
| Cases | Tickets | Confirm in the current Zammad Kayako migration documentation that case history and ticket fields are carried over as expected for your data. |
| Customers and organizations | Users and organizations | Map customer accounts and their organization links, then check duplicate contacts and email addresses before the test import. |
| Agents | Agents (users with agent roles) | Agent accounts need a planned login path after the move. Confirm how passwords and sign-in behave in the current documentation. |
| Groups | Groups | Confirm group membership and agent access mapping in a test import so routing matches your existing setup. |
| Standard ticket states | Standard ticket states | Confirm that the default open, pending and closed style states have a documented mapping before relying on them. |
| Standard priorities | Standard priorities | Confirm the documented mapping for default priority levels and check that reporting uses the expected values. |
| Custom ticket states, priorities and types (Kayako Scale plans) | Recreated Zammad values or mapped existing values | Not transferred from Kayako Scale plans. Recreate these values in Zammad before import or map them to existing values. |
| Attachments, macros, triggers and automations | Attachments, triggers and automations | Not covered by the mapping above. Run a separate check against the documented migrator output and rebuild automation logic by hand where needed. |
Why self-hosted Kayako Classic needs another route
The Zammad Kayako migrator supports cloud-hosted Kayako only. Self-hosted installations, Kayako Classic included, are not supported by the built-in migrator. If your helpdesk runs on Kayako Classic, you cannot treat the Zammad migrator as a ready-made import tool, and the project plan has to start from a different assumption: data leaves Kayako through a route you design and build, then enters Zammad through the Zammad API or through custom development from Zammad. That changes the scope, the skills needed and the order of work.
This is a scope decision, not a configuration detail. An export and a custom import mean the team must define which Kayako objects are in scope (tickets, comments, attachments, customers, organizations, agents and groups), map each one to a Zammad object, decide how attachments and time stamps are carried across, and prove the result with test imports before any cutover. Each of those steps adds work that the cloud migrator would otherwise handle. Ask your partner or internal team to list these objects and mapping decisions in writing before anyone estimates effort or timelines.
Confirm which Kayako product you run before you go further. Kayako Classic (self-hosted) and the cloud-hosted Kayako product follow different migration routes, and the answer decides whether the built-in migrator is an option at all. Check the product name on your license or contract, the hostname that serves your helpdesk, and whether your administrators can reach the database and file storage directly. Record the answer with the version your team is running, since the migration plan, the export method and the list of data you can extract all depend on it.
Also check which Kayako features your team depends on. The Zammad documentation notes that custom ticket states, priorities and types are not transferred from Kayako Scale plans. Your custom Kayako fields and workflows may need the same planning on a self-hosted route, so list them early and decide whether each one maps to an existing Zammad setting, becomes a custom object, or is retired. Ask the people who run your queues to confirm these lists, because gaps found after cutover are costly to fix.
Which documented import paths Zammad offers for Kayako
Zammad documents three ways to bring Kayako data across: a built-in migrator for cloud-hosted Kayako Scale, the Zammad API for other source data, and custom development where the API falls short. The right route depends on which Kayako product you run, what your Kayako plan exposes, and how much of your history and configuration must survive the move.
Built-in Kayako migrator
The built-in migrator is the first route to evaluate for cloud-hosted Kayako Scale. It is the only documented Kayako importer in Zammad, so it is the path most teams should test first. Before you plan around it, confirm with Kayako that your plan grants the API access the migrator needs. Check the limits too: custom ticket states, priorities and types are not transferred from Kayako Scale plans, so those will need manual mapping after import.
Self-hosted Kayako Classic gap
The built-in migrator does not support self-hosted Kayako installations, commonly called Kayako Classic. If your helpdesk runs on servers you operate, this card is your decision point: the migrator will not connect to it. Confirm your exact Kayako product and version with your vendor contact before scoping. Plan a different route, such as an API-based extraction or an export you map yourself, and budget time to validate it on a copy of your data.
Zammad API for other source data
The Zammad API lets you create tickets, users, organizations and articles from data you extract yourself. Use it when your Kayako data sits outside the built-in migrator's reach, or when you need a controlled, scripted import you can rerun. The work shifts to your team or your partner: you extract the source data, transform it into Zammad's model, and load it in a repeatable order. Verify the API token permissions and rate behavior on your own instance before a full run.
Custom development from Zammad
Custom development covers cases the API alone does not handle well, such as attachments with unusual formats, history that must map onto custom states, or field mappings that need business rules. This route adds code you must own, test and maintain across Zammad upgrades. Scope it in writing before work starts, including who owns the mapping rules, how exceptions are logged, and how the import is verified against source record counts.
Mapping states, priorities and types
Custom ticket states, priorities and types from Kayako Scale are not transferred by the built-in migrator. Whichever route you choose, you must decide how each custom value maps to a Zammad state, priority or ticket type before the import starts. Document the mapping table, agree it with support leads, and check that reports and automations still work after the move. This decision affects every other route and should be made first.
Kayako access and verification checks
Every route depends on reliable access to the source system and a way to prove the result. Confirm with Kayako which API access your plan includes, and which credentials and permissions you need. On the Zammad side, run each import against a test instance first and compare ticket, user and organization counts with the source. Keep the import logs so the cutover decision rests on evidence rather than assumptions.
How the Kayako to Zammad sequence runs, from inventory to decommission
This sequence moves cloud-hosted Kayako data and workflows into a Zammad instance you control, with each stage ending in a documented check. It finishes with a verified cutover and a recorded decommission of Kayako, so the team knows what moved, what was rebuilt and what was retired.
Inventory the Kayako plan, data and configuration
Confirm first that the source is cloud-hosted Kayako, since the built-in migrator does not support self-hosted Kayako Classic. Your administrator then lists the plan type, agent and customer counts, ticket volume, attachment size, email channels, API access, triggers, macros, SLAs and any custom ticket states, priorities and types. Custom states, priorities and types from Kayako Scale plans are not transferred, so each one needs its own row in the inventory. The step is complete when the platform owner signs the inventory and confirms the migration route in writing.
Build a Zammad test environment you control
Your infrastructure team deploys Zammad on servers, containers or Kubernetes in an environment you operate. The stack needs PostgreSQL 15 or newer for content storage, Redis 7 or newer for realtime websocket communication, and Nginx or Apache as the reverse proxy. Decide whether to run Elasticsearch, which is optional but strongly recommended for search and email attachment content. Decide on Memcached if the deployment runs several instances, such as containers or cluster nodes, since single installations can use the file system cache. The step is complete when all services report healthy and the versions are recorded.
Run a test import and review records
The migration owner runs the Kayako migrator against the test environment using a Kayako API token with the access the import needs. Review a sample of agents, customers, groups, organizations and tickets, including attachments, comment ordering and timestamps. Record each mismatch in a discrepancy log with the source record ID, the expected result and the actual result. Agent and customer accounts should be checked for role and group assignment, and any login behavior should be noted for the cutover plan. The step is complete when the log lists every open issue and each issue has an owner and a fix or an accepted exception.
Rebuild custom states, priorities and types
Because custom ticket states, priorities and types are not carried over from Kayako Scale plans, rebuild them in Zammad by hand. Map each Kayako value to a Zammad state, priority or ticket type, and mark any value that should be retired instead of recreated. Then rebuild the dependent triggers, macros, overviews and reports, since they reference those values. Test a set of representative tickets through each state change. The step is complete when the mapping sheet is approved by the support lead and the rebuilt configuration passes the test ticket checks.
Confirm incremental import behavior before planning the parallel run
Before you set dates for the parallel run, confirm in the current Zammad documentation whether the Kayako migrator supports incremental imports, meaning repeated runs that pick up only tickets changed since the last import. The answer determines whether you can keep Kayako live and sync later, or whether you must plan a single final import at cutover. Record the answer, the version of the documentation you read and any limits on the number of runs. The step is complete when the platform owner has the written answer and the parallel run and cutover plans reference it.
Run a parallel period with decided routing
During the parallel period, Kayako and Zammad both run, so you must decide where new tickets land. Choose a routing rule for each inbound channel, such as keeping email in Kayako while Zammad receives a test mailbox, or moving one team or queue first. Document who answers in each system and how duplicate threads are prevented. Compare ticket counts and sampled records between the two systems every day the period runs. The step is complete when the routing decision is signed by the support lead and the comparison shows no unexplained gaps.
Cut over to Zammad
Plan the cutover around the incremental import answer confirmed earlier. Freeze new work in Kayako, run the final import or delta import, and reconcile counts against the inventory. Then switch inbound email routing, web forms and any agent or customer links to Zammad, and confirm that the Zammad FQDN resolves as expected. Test one inbound email, one agent login and one customer ticket view before the switch is announced. The step is complete when the cutover checklist is signed and the reconciliation shows that the counts match the inventory within the exceptions already logged.
Decommission Kayako after verification
Once the cutover is verified, export a retained archive of the Kayako data in the format your retention policy requires, and store it in a location you control. Revoke Kayako API tokens, remove integrations and disable email forwarding into Kayako. Confirm with your legal and records owners that the archive meets retention obligations before you cancel the Kayako subscription. Keep the discrepancy log and the cutover checklist with the archive. The step is complete when the decommission record lists each removed integration, the archive location and the cancellation date.
What drives the cost and duration of a Kayako migration
This table lists the factors that change the cost and effort of moving from Kayako to Zammad, with why each one matters and what to request in a quote. Read it before you ask for a scope, because the Kayako product, your configuration and the hosting choice decide which route applies and who is paid for each part. The main takeaway is that the Kayako plan and hosting model shape the whole project, so confirm them first.
| Driver | Why it matters | What to ask for in a quote |
|---|---|---|
| Kayako product (Scale or Classic) | The built-in Zammad migrator supports cloud-hosted Kayako only. Self-hosted Kayako Classic needs a different route, which changes the scope and the skills required. | Written confirmation of the Kayako product and hosting model, and the route proposed for each |
| Custom states, priorities and types | Custom ticket states, priorities and types are not transferred from Kayako Scale plans, so each one must be mapped or rebuilt in Zammad. | An inventory of custom items, the mapping to Zammad equivalents, and whether rebuilding is in scope |
| Ticket and attachment volume | Larger histories and more attachments take longer to export, transfer and verify, and they raise storage and search indexing needs. | Export size estimates from your Kayako account, the test import plan and how the full import is timed |
| Number of agents and groups | Agents, groups and roles must be recreated and checked for access, which adds mapping and testing work for each team. | A count of agents, groups and roles, and the permission model to be reproduced |
| Integrations to rebuild (email, SSO, telephony) | Inbound and outbound email, single sign-on and telephony connections must be configured again in Zammad and tested with real traffic. | A list of each integration, its owner, and the test cases used to accept it |
| Hosting choice (self-hosted or hosted Zammad) | Self-hosted Zammad has no license fee, but you pay for infrastructure, operations and any support subscription. Hosted Zammad bills per agent per month. Subscription tiers and hosted rates are Zammad pricing page figures, not DeployOpen prices, so check the current Zammad pricing page before budgeting. | Who pays for hosting, operations and Zammad support, and whether the quote covers the Zammad subscription or only the migration |
What usually goes wrong in a Kayako to Zammad move and how to prevent it
Most problems in a Kayako to Zammad move come from assumptions made before the import starts, not from the import itself. The risks below cover the data model, the Kayako plan and edition, what the migrator leaves behind, and the cutover steps around login and email. Each card names one prevention step to settle before the migration window is set.
Assuming custom states and priorities carry over
Zammad's Kayako migrator does not transfer custom ticket states, priorities or types from Kayako Scale plans. Teams that built their workflow around custom values often find their queues, macros and reports point at values that no longer exist. Before the import, export the full list of custom states, priorities and types from Kayako and map each one to a Zammad state, priority or ticket type. Agree the mapping with the support leads who use it every day.
Discovering late that Kayako is Classic
The built-in migrator supports cloud-hosted Kayako only. A self-hosted installation, which Kayako sells as Classic, is not supported, so an import attempted against it cannot complete as planned. Confirm the edition, hosting model and API access on the Kayako side in the first planning meeting, before any Zammad environment is built. If the edition is Classic, the migration needs a different data route and a new estimate.
Losing history the migrator does not carry
Teams often assume a ticket import carries everything attached to a ticket. Anything outside the migrator's scope, such as data held in custom fields, integrations, saved reports or some attachments, needs a separate decision. Build an inventory of what the support desk relies on, then check each item against the migrator's documented scope in a test import. Items that are not carried should be archived or rebuilt in Zammad before cutover.
Agents and customers locked out after cutover
Users who log in to a new helpdesk for the first time often hit password resets, unverified email addresses or an incorrect external URL. Agents then cannot reach queues and customers cannot see their tickets, which turns a planned switch into a support incident. Before cutover, list every agent and customer group, confirm how each will authenticate (local password or a configured SSO provider), and test a login with one account from each group on the production hostname.
Email routing not switched at cutover
Kayako's inbound mailboxes keep receiving messages until their forwarding or connector is changed. If the mail route still points at Kayako after the cutover, new customer emails land in a system no one is watching. Write down every inbound address, its current routing and its target in Zammad, including any outbound sender addresses. Assign one named person to switch each route in a defined order and confirm with a test message to each address.
Unrealistic scope for parallel running
Running Kayako and Zammad side by side means agents must check two systems and keep answers consistent across both. Teams that plan parallel running for every queue, channel and region usually abandon it under load. Decide in advance which queues, if any, run in parallel, what each system is the source of truth for, and how long the overlap will last. Keep the scope narrow enough that the people doing the work can keep it up.
What changes for agents, customers and administrators after the move
Agents, customers and administrators will each meet a different Zammad after cutover, and the team should plan for those differences before the import starts. The most visible change is how people sign in. Kayako accounts are not a login source for Zammad, so the team has to decide which identity method Zammad will use for agents and whether customers will sign in at all or only submit requests by email and web forms. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Confirm which of these fits your identity provider and directory setup before you promise users a login path. If your organization already runs a central identity platform, check whether it can act as a SAML or OpenID Connect provider for Zammad and who will own that configuration after go-live.
Administrators should expect to rebuild configuration rather than expect it to arrive with the data. Ticket data moves through the migrator, but the working setup around it does not. Groups, roles, email channels, triggers, macros, overviews, SLAs and automations must be recreated or reviewed in Zammad's own model. Kayako's custom ticket states, priorities and types are not transferred from Kayako Scale plans, so each one needs a deliberate mapping to a Zammad equivalent or a decision to retire it. Write that mapping down as a short table with the old value, the new value, the owner and the agents affected. Administrators who skip this step often find that reports and routing rules quietly stop matching the tickets they were built for. Ticket history is also not uniform. Imported tickets and their articles become part of Zammad's records, but agents should not assume that every Kayako view, saved search or report has a counterpart. Decide which historical tickets must be searchable from day one, and confirm with the migration plan how far back the import reaches and how attachments are handled. If the business needs to keep Kayako read access for a period, confirm with your own environment how long the source system stays available and who is allowed to use it.
Communication and training have to be planned before cutover, not after the first complaint. Agents need to know their new login path, where their queues now live, how to find older tickets and which fields or states have changed. Customers need to know which address to write to, whether they must create an account, and how their existing ticket references will behave. Administrators need hands-on time with the rebuilt configuration. Assign one owner for each audience, schedule sessions before the cutover window, and prepare short written guides that reflect the mapping decisions your team actually made. Keep a named contact for the first weeks, because the first login problems and missing-queue questions usually arrive in the same few hours. Finally, treat the sign-in, configuration and history questions as release criteria. A test import should be used to confirm that a sample of agents can log in through the chosen method, that mapped states and priorities behave as planned, and that a representative set of historical tickets can be found. If any of these checks fails, the cutover date should move rather than the users absorbing the gap. Ask any implementation partner to show how they will verify each of these points in writing before work begins.
Questions buyers ask before they hire help with a Kayako to Zammad migration
Does the built-in Zammad migrator work for my Kayako plan?
It depends on whether your Kayako is cloud-hosted. The built-in Zammad migrator supports cloud-hosted Kayako only, so a self-hosted Kayako Classic installation falls outside it. Before you plan, confirm the API access your plan provides, because the import depends on it, and check the Zammad Kayako migration documentation for current requirements. Custom ticket states, priorities and types are not transferred from Kayako Scale plans, so the built-in run leaves those values behind even when your plan qualifies. A short review of your plan and its configuration, completed before any test import, shows whether the migrator covers the data you need or whether custom work is required. Ask for that review as part of the written scope.
What happens to custom states, priorities and types during the import?
Custom ticket states, priorities and types are not transferred from Kayako Scale plans, so they will not appear in Zammad after the built-in import. Decide early which of these values your teams still need, then map each one to a Zammad state, priority or ticket type that already exists or to one you create. Agent reporting and queue routing depend on this mapping, so old and new categories should line up before cutover. The mapping table is usually part of the scope, along with decisions about how to handle historical tickets that used retired values. Confirm the exact fields carried over in the current Zammad documentation and in a test import, because the list of transferred data can change between releases.
What is the migration route for self-hosted Kayako Classic?
The built-in Zammad migrator does not support self-hosted Kayako Classic, so the cloud-hosted import path cannot be used for it. Zammad documentation states that other systems can be imported through the Zammad API or through custom development. In practice, this means extracting data from the Classic installation, transforming it into Zammad objects and loading it through the API or a custom importer, with mapping, attachments and user accounts handled deliberately. This route needs more design and testing than the built-in migrator, so effort is driven by data volume, customization and how much history you must keep. Ask for the approach in writing before accepting any timeline, and confirm the extraction method against your Kayako Classic version.
Can our own team migrate from Kayako to Zammad without a partner?
Yes, a capable internal team can run the built-in migrator when the Kayako source is cloud-hosted and the data model is simple. The work still requires Zammad administration, PostgreSQL and Redis operations, a reverse proxy, a test environment, data mapping and a controlled cutover. The hardest parts are usually the mapping decisions for states, priorities and types, verification of tickets, attachments and users, and the single cutover where email routing and logins change together. Check whether your team has time for repeated test cycles and whether one person owns sign-off. A partner adds the most value when your data uses many custom values, when you need a route for Kayako Classic, or when the deadline leaves little room for rework.
What does our team need to provide for a Kayako migration?
Plan to provide four things. First, access to the Kayako instance with the API permissions the migration requires, plus an owner who can grant and revoke them. Second, staff for testing and sign-off, including agents who know the queues and an administrator who can confirm the mapping. Third, infrastructure for Zammad, which runs on PostgreSQL 15 or newer, requires Redis 7 or newer and uses Nginx or Apache as a reverse proxy. Elasticsearch is optional but strongly recommended for faster search and attachment content, and Memcached is needed for multi-instance deployments. Fourth, decisions on SSO, email channels and data retention. DeployOpen works inside your own cloud accounts, data centers or air-gapped networks, so you provide and control that environment.
What does a Kayako to Zammad migration quote depend on?
A quote follows from the written scope, so it depends on what that scope includes. The main drivers are the Kayako plan and whether it is cloud-hosted or Classic, the volume of agents, tickets, attachments and users, and the number of custom states, priorities and types that need mapping. Other drivers include the number of Zammad environments, integrations such as SSO through SAML or OpenID Connect, and the number of test and cutover cycles. The scope should also state whether documentation, handover and post-cutover support are included. Ask for deliverables, assumptions, exclusions, acceptance criteria, and who pays for any third-party licenses or hosting. Most engagements are fixed-scope, so agree the assumptions in writing before work starts.
What does a Zammad support subscription cover, and how fast is the response?
A Zammad support subscription is sold by Zammad, separately from DeployOpen's implementation work, and it covers support for the Zammad software. According to the Zammad pricing page, self-hosted Business support costs 2,999 EUR per year with a 6-hour response time, Enterprise costs 5,999 EUR per year with a 4-hour response time, and Corporation costs 9,999 EUR per year with a 2-hour response time. Self-hosted Zammad has no license fee, so the subscription is a recurring cost to weigh against the skills you already have in-house. On Kubernetes, Zammad support covers the Zammad application only, and Kubernetes-specific issues need a separate route. Confirm the exact coverage with Zammad before you buy, and ask DeployOpen separately about a retainer for ongoing operations.
How much does hosted Zammad cost per agent each month?
Hosted Zammad is billed per agent per month. According to the Zammad pricing page, the Starter plan costs 7 EUR per agent with annual billing and covers up to 5 agents, Professional costs 16 EUR per agent and covers up to 35 agents, and Plus costs 25 EUR per agent with unlimited agents. The hosted service runs in a data center in Germany. Hosted pricing covers the service Zammad operates, so it follows a different cost model from self-hosting, where you pay for infrastructure, operations and any support subscription. Migration work is quoted separately from either hosting option, based on the written scope. Confirm current prices and tax treatment on the Zammad pricing page before you compare options.
How DeployOpen scopes, delivers and supports a Kayako to Zammad migration
DeployOpen plans, implements, integrates, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a Kayako 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 once the migration closes.
How we scope
- Confirm whether your Kayako is cloud-hosted Scale or a self-hosted Kayako Classic installation before anything else.
- The written scope lists which Kayako data moves into Zammad and which items need a documented manual step.
- Custom states, priorities and types from Kayako Scale plans are not transferred, so the scope records how each one is mapped.
How we build
- Map Kayako statuses, priorities and ticket types to Zammad states, priorities and ticket attributes before the first import run.
- Build the Zammad target in your own infrastructure with PostgreSQL 15 or newer and Redis 7 or newer, as documented.
- Run the built-in migrator against a copy of the source data and check imported record counts against the source.
How we hand over
- Deliver a test import report listing what moved, what was mapped by hand and what stayed in the source system.
- Document the cutover runbook, including who freezes Kayako writes, when DNS or mailbox routing changes and how agents log in.
- Hand over configuration, admin notes and the archived export so your team can run Zammad after the project closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the migration closes.
- Zammad sells its own self-hosted support subscriptions, so confirm which one your team needs before cutover.
- Agree in the written scope which post-cutover questions, such as password resets for agents and customers, fall under support.
