Migrate from Zendesk to Zammad

How long does a migrate from Zendesk to Zammad project take?

The built-in Zammad Zendesk migrator covers groups, organizations, users and tickets, so the move does not need custom development for those objects. How long the project takes depends on scope, data volume and how carefully the team plans its single cutover. This page does not state a duration or price because the scope, deliverables and timeline have to be agreed in writing before work starts. Any figure given before that point would be a guess about your data and your team.

Scope starts with the data itself. Count the groups, organizations, users and tickets, and find out how far back the ticket history goes and how many attachments it carries. Check the Zendesk side early: the migrator needs the Zendesk URL, an administrator email address and an API token created for the migration, so confirm that your Zendesk plan and account permissions allow that access. Search the data for Cyrillic strings as well, because the migrator cannot import objects that contain them. Each of these findings can add mapping, cleanup or a rerun to the plan.

Cutover drives most of the schedule risk. The migrator does not run differential imports, so the team must choose one cutover point, stop new work in Zendesk for the freeze window, run the final import and then switch email routing and channels to Zammad. Before that, run a test import against a non-production Zammad instance to measure how long the import takes and to find failures while they are cheap to fix. The length of the freeze window and the number of test cycles are decisions your team should make with the partner, not after the import has started.

Cost follows the same drivers. Self-hosted Zammad has no license fee, so the quote covers the services and the infrastructure you run: migration analysis, the test and final imports, validation, agent and administrator time, and the hosting you provide. The migration is a one-time effort, while hosting, updates and any support subscription recur. Ask for a written quote that lists the objects in scope, the data volume you assumed, the number of test imports, the cutover plan and freeze window, the acceptance criteria, and the Zendesk access you will provide.

What maps cleanly from Zendesk to Zammad and what does not

This table compares Zendesk objects with their Zammad equivalents and shows whether each one moves through the built-in migrator, needs manual recreation or needs a decision. Read the migration path column first, then use the notes to plan cleanup before the single cutover. The main takeaway is that tickets, users and organizations are the objects the migrator is built to carry, while automation logic and SLAs need deliberate rebuilding.

Zendesk object	Zammad equivalent	Migration path	What to check
Groups	Groups	Built-in migrator	Needs a Zendesk API token. Confirm API access for your Zendesk plan first.
Organizations	Organizations	Built-in migrator	Review duplicate or overlapping organization names before the test import.
Users (agents and end users)	Agents and customers	Built-in migrator	Passwords are not carried over, so plan resets and login communication for after cutover.
Tickets and comments	Tickets and articles	Built-in migrator	Objects containing Cyrillic strings cannot be migrated. Scan for them before the run.
Attachments	Ticket attachments	Built-in migrator	Confirm supported attachment handling in the Zammad Zendesk migration documentation.
Views and macros	Overviews and macros	Manual recreation	Rebuild filters, column layouts and macro actions in Zammad syntax for each team.
Triggers and automations	Triggers and scheduled jobs	Needs a decision	Decide which rules to keep, since logic and conditions must be reviewed one by one.
SLAs	SLA definitions	Needs a decision	Rebuild business hours and escalation rules, and confirm the feature set in your Zammad version.
Custom fields and brands or channels	Object attributes, email addresses and channels	Manual recreation	Recreate fields with matching types, and map each brand to a sender address, group and channel.

Which Zendesk import paths Zammad documents

Zammad documents a built-in Zendesk migrator, a route through its API for objects the migrator does not cover, and custom development as the last resort. Each path asks something different of your team, so confirm the scope of your Zendesk data before you pick one.

Built-in Zendesk migrator

Zammad includes a migrator for Zendesk that imports groups, organizations, users and tickets. It needs your Zendesk URL, an administrator email address and an API token created for the migration. Before choosing it, confirm that your Zendesk plan and administrator role allow token creation, and check whether any records contain Cyrillic strings, because the documentation states that those objects cannot be migrated. Plan those records as a separate task.

Zammad API for uncovered objects

Objects outside the migrator's scope, such as custom fields, macros, triggers or views you need to carry across, can be created through the Zammad API. Your team writes a script that reads the data from Zendesk and posts it to Zammad, so it needs developers comfortable with both REST APIs and your data mapping. Confirm which object types you need, how Zammad IDs will be matched to Zendesk records, and how you will test the script before cutover.

Custom development from Zammad

When neither the migrator nor the API covers a requirement, Zammad documents custom development as the last option. This means building import logic against Zammad's internals or data model, which carries the highest maintenance cost and the most upgrade risk. Ask whether the requirement is needed at go-live or can be handled after cutover, and confirm the upgrade path with your Zammad release line before committing to this route.

Confirm the data inventory first

Whichever path you choose, list every Zendesk object type in use, including custom fields, attachments, macros and automations, and mark each one as covered by the migrator, needing the API, or needing custom work. This inventory decides the route. Without it, teams often discover gaps after the single cutover, when there is no differential run to correct them.

Team skills and ownership

The migrator needs an administrator who can run the import and check results. The API and custom routes need developers who can maintain code after handover. Name the owner of each path, the person who approves the mapping, and the reviewers who will validate agent and customer data in the test import. Confirm these roles before you pick a route, since they set the staffing you must provide.

What the Zendesk migrator needs before it can run

The Zendesk migrator cannot start until you have three inputs: your Zendesk URL, an administrator email address and an API token created for the migration. Create the token under a named administrator account that the migration owns, store it in your secrets manager, and note which account it belongs to. Before you create it, ask Zammad in writing whether your Zendesk plan and that administrator role allow API token access, and which combination they have verified. Without that confirmation, the team may build the rest of the plan around a token that cannot read groups, organizations, users and tickets.

Treat the token as a short-lived credential. Limit its use to the migration window, record who can read it, and plan to revoke it once the final import is complete and verified. Confirm the administrator email address matches the account that owns the token, because a mismatch is one of the easiest ways to lose a test run. Keep a short written record of the token's creation date, owner and revocation date so your security team can show who had access to Zendesk data during the move.

Zammad documents that objects containing Cyrillic strings cannot be migrated. Find affected objects before the first test import, not during the cutover. Search the full Zendesk export for Cyrillic characters across each object type in scope: group names, organization names and domains, user names, ticket subjects, tags and custom field values. Ask Zammad which fields the limitation covers, including whether ticket comment bodies are affected, so your search matches what the migrator actually rejects. Log every hit with its object type, identifier, owner and the decision you make about it.

For each affected object, choose one path and record it: rename the object in Zendesk before export, transliterate it under a documented rule, or recreate it manually in Zammad after the import. Changing names in the source alters records that agents and customers see, so get sign-off from the support leads who own those groups and organizations. Do not edit tickets silently. After any change, re-scan the export and confirm the count of remaining hits is zero or matches your documented exceptions, then run the test import against that corrected copy.

Rate limits and import duration are not settled facts you can plan around by assumption. Zendesk API limits and the Zammad migrator's throughput both depend on current product behavior and on your data volume, so check the current Zammad documentation and the Zendesk API documentation for the limits that apply to your plan. Time the test import against a complete copy of your data, then schedule the cutover from that measured duration with a margin agreed by your operations and support leads. A cutover window built on a guessed duration is the most common cause of a rushed final import.

Migration sequence from inventory to decommission

The sequence moves Zendesk groups, organizations, users and tickets into Zammad through one tested path, from inventory to a signed-off decommission record. Each step has a named owner and a closing check, so the customer knows what has been proven before the single production cutover. Work stays inside the written scope, and the customer keeps the decisions on access, timing and retention.

Inventory Zendesk objects and integrations
The team lists groups, organizations, users, ticket fields, macros, triggers, automations, views and every integration that reads from or writes to Zendesk. The customer's Zendesk administrator creates the API token for the migration and confirms the Zendesk URL and administrator email address the migrator needs. Objects containing Cyrillic strings are flagged at this stage because the migrator cannot import them. The step closes with an inventory signed off by the customer, listing what moves, what is rebuilt and what is out of scope.
Build the test environment and run a test import
DeployOpen installs Zammad in the customer's infrastructure within the agreed scope and runs the Zendesk migrator into it as a test import. Engineers compare what arrived in Zammad against the inventory for groups, organizations, users, tickets and attachments, and log every object that failed or was skipped. The customer's support leads sample tickets to confirm that history reads correctly and ownership is right. The step closes when the import log is reviewed and each open issue is either fixed or accepted in writing.
Map and clean up groups, roles and automations
Using the test import results, the team maps each Zendesk group and role to a Zammad group and role. It also decides which triggers, automations and macros are recreated, simplified or retired, and removes unused or duplicate groups so agents do not inherit clutter. The customer's operations lead approves the mapping, and the team repeats the test import until sample agents and customers see the access they expect. The step closes with an approved mapping document and a test instance that matches it.
Run the single production cutover
The production cutover is one run, because the migrator does not support differential runs. The customer sets the cutover time, stops new work in Zendesk for the agreed window, and approves the message sent to agents and customers. DeployOpen runs the final import against the approved mapping, then checks object counts against the inventory. The step closes when the counts reconcile or each gap has a documented decision, and the customer confirms the go-live record.
Reset passwords and check user logins
Imported users should not assume their Zendesk credentials carry over, so the team confirms how the migrator handles credentials and plans password resets or the chosen sign-in method before cutover. After go-live, engineers and a sample of agents and customers sign in, check their group access, open and reply to a ticket, and confirm that email notifications arrive. If single sign-on is in scope, it is tested against the customer's identity provider. The step closes with a login test record signed off by the customer's support lead.
Decommission Zendesk after the retention period
Zendesk stays in place for the retention period the customer sets with its legal and compliance owners. DeployOpen does not set that period. When it ends, the team disconnects integrations that still point at Zendesk, the customer revokes the migration API token, and the customer cancels the subscription and handles any data deletion. The step closes with a decommission record listing revoked access, disabled integrations and the date the retention period ended. DeployOpen's written scope ends with that record.

Why the Zendesk move needs one planned cutover

The Zendesk migrator is not designed for differential runs, so a later run does not pick up changes made in Zendesk after an earlier import. Treat the import as a single point-in-time copy of groups, organizations, users and tickets. Anything an agent changes in Zendesk after that copy exists only in Zendesk unless someone moves it by hand. This is the main reason the team needs one planned cutover, with a clear moment after which Zendesk stops being the working system. Before you set a date, confirm this behavior in the Zammad documentation for the Zendesk migration and write down exactly what it says about rerunning the migrator.

The team has three realistic options. A short support freeze stops changes in Zendesk between the final export and go-live. It contains the risk, but it costs service time and needs customers to be told that new requests may wait. A documented manual catch-up accepts some drift: after go-live, a named person recreates tickets and comments that changed after the snapshot in Zammad and logs each one. This keeps service running, but the effort grows with the number of late changes, and every manual step is a chance for error. A delayed cutover keeps Zendesk as the system of record until the import has been tested end to end. It trades calendar time for fewer late changes, and it postpones the benefits of the new platform.

The right option depends on how fast tickets change in the window, whether Zendesk triggers and automations fire on updates, and how many inbound paths still point at Zendesk. Email addresses, web forms, chat integrations and phone routing each need a repointing step at cutover. If one of them still delivers to Zendesk after the import, new messages land in a system nobody is watching. Assign owners in advance: the support lead approves the freeze, the platform owner changes mail and DNS routing, and the Zammad administrator checks counts and samples after the import. Ask any implementation partner for a written cutover runbook that names these steps, owners and rollback points.

A test import on a copy of the data shows what the freeze needs to cover, because it reveals how long the import takes and which objects need attention before go-live. Use the results to decide the freeze window with the support team rather than guessing from ticket volumes alone. Record the final cutover decision, the export timestamp and the list of late changes handled by hand, so auditors and support leads can trace what moved and when. A single planned cutover is simpler to explain to customers and agents than a sequence of partial moves, and it leaves one clear source of truth from the day Zammad goes live.

What drives the cost and duration of a Zendesk to Zammad move

This table lists the factors that change the effort of moving Zendesk into Zammad, whether each one is paid once or kept running, what raises or lowers it, and what to request in a written quote. Use it to compare your own Zendesk footprint against the scope a partner will price, and to see where a quote could move up or down.

Driver	One-time or recurring	What raises or lowers it	What to ask for in a quote
Ticket history volume	One-time	Total ticket count and event depth per ticket drive import runtime, API calls and test rounds. Archiving closed tickets older than a cutoff lowers it.	Ticket counts by year and status, the import window, and how the quote assumes API timing for the full history.
Attachment volume	One-time	Total attachment size and count, plus any inline images, affect transfer time and storage on the Zammad side. Excluding stale files lowers it.	Attachment count and total size from Zendesk, and whether the quote covers all attachments or a defined subset.
Groups, organizations and users	One-time	Number of groups, organization records and user accounts, including duplicate or inactive users, drives mapping work and validation. Cleaning source data before import lowers it.	Counts for each object type, the mapping rules agreed for groups and roles, and how duplicates are merged.
Custom fields	One-time	Each custom ticket, user and organization field needs a matching Zammad object attribute and a mapping decision. Unused fields lowered before import reduce it.	A field inventory with types and usage, and the mapping sheet the partner will build and sign off.
Triggers, automations and macros to rebuild	One-time, with later upkeep	Zendesk triggers, automations and macros do not move as-is, so each one must be rebuilt and tested in Zammad. A smaller, consolidated set lowers it.	A list of rules by type with owners and purpose, and which rules are in scope to rebuild versus retire.
Integrations to reconnect	One-time, then recurring for licenses and hosting	Email inboxes, chat, telephony and other connected tools each need configuration and testing in the new system. Fewer connections lower it.	A connection inventory with channel, vendor and owner, and which connections the quote covers.
SSO design	One-time, then recurring for the identity provider	Choosing between Zammad's supported third-party login options and your identity provider, plus group and role mapping, adds design and test work. Reusing an existing provider lowers it.	The protocol and provider chosen, the attribute and group mapping, and who signs off on access.
Elasticsearch and hosting setup	One-time build, recurring hosting	Zammad recommends Elasticsearch for search and attachment content, and multi-instance deployments need Memcached. Sizing for your ticket and attachment volume raises the work. Reusing existing infrastructure lowers it.	Hosting architecture, sizing assumptions, backup and restore design, and which components are included in the build.
Testing rounds	One-time	Each trial import, reconciliation check and agent walkthrough adds a round. Clear acceptance criteria written before the first test lower the count.	The number of test imports included, acceptance criteria, and what a failed round costs in additional time.
Staff time for validation	One-time, paid by your organization	Your agents and admins must check data, rules and integrations before cutover. Named reviewers with set availability keep it contained.	The validation tasks the partner expects from your team, and the reviewer roles and time commitments they assume.

What usually goes wrong in a Zendesk to Zammad move

The risks below cluster around three moments: access before the import starts, data that does not arrive intact, and users who find Zammad unfamiliar after cutover. Each card names one risk and the check to run in the test import, so problems surface before the single cutover, when agents and customers depend on Zammad.

API token with insufficient rights

The Zendesk migrator authenticates with an API token created for the migration, tied to an administrator email address. A token created by an account with too few rights can read some objects and fail on others, often partway through a run. In the test import, confirm the token can read groups, organizations, users and tickets, and record which account created it. Ask Zendesk to confirm that your plan includes the API access you need.

Objects with Cyrillic strings

The Zammad documentation states that objects containing Cyrillic strings cannot be migrated with the built-in migrator. Affected records may be missing after the import, and the team may only learn of the gap when an agent cannot find a ticket. In the test import, scan the Zendesk export for Cyrillic characters in names, tags, custom fields and subjects, then decide before cutover whether to rename, recreate or handle each object by hand.

Ticket history volume and attachments

Ticket histories can be far larger than the ticket count suggests, which lengthens the production import. Attachments and inline links can also break when files or old Zendesk URLs no longer resolve. In the test import, time the run against your largest histories, then compare ticket, comment and attachment counts between Zendesk and Zammad. Open a sample of attachments and links, including links that appear in macros, saved replies and past emails.

Agents missing groups or roles

After import, agents may lack the groups or roles they had in Zendesk, so they cannot see the queues they work. This is easy to miss when only administrators check the result. In the test import, map each Zendesk group and agent role to its Zammad equivalent, then sign in as one sample agent per role and confirm the expected tickets and queues are visible and editable.

Customers unable to log in

Customers who had Zendesk accounts may be unable to sign in to Zammad if password resets were not planned. Login failures generate support contacts at the moment the team has the least capacity to handle them. In the test import, decide how customers will authenticate, whether by password reset or a third-party login such as SAML or OpenID Connect. Then trigger a reset from a migrated customer account and confirm the email arrives.

Automations that behave differently

Zendesk triggers, automations, macros and SLA rules do not map one-to-one onto Zammad's equivalents, so logic that worked in Zendesk may produce different results. Teams often discover this only when a ticket is routed or escalated incorrectly. In the test import, inventory every active Zendesk rule, rebuild each one in the test instance, run sample tickets through each path, and compare the outcome with what Zendesk did.

What changes for agents and customers after cutover

After cutover, agents and customers sign in to Zammad at its new address, so the first decision is how they will authenticate. Zendesk accounts do not give the team a sign-in method on Zammad by themselves, so confirm with the migration documentation whether user passwords carry over. Unless you verify that they do, plan a password reset for every agent and customer. Decide who triggers resets, how users prove their identity, and which help page they follow. Test the reset email on a pilot group before the production date, because a broken reset flow is the most common reason users cannot reach their tickets on the first morning.

Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Confirm which of these matches your identity setup before you move. If agents already sign in to Microsoft 365 or Google Workspace, decide whether they should use that provider in Zammad from day one. Customers who used a social login on Zendesk need a clear answer too, because their existing login may not map to a Zammad account. Settle the provider configuration, the callback addresses and the role mapping in the test instance, so that the production switch is a configuration change rather than a discovery exercise on cutover day.

Email address changes affect both sides of the conversation. Agents may see a new sender address on outbound replies, and customers may keep writing to the address they used with Zendesk. Confirm which inbound address Zammad will receive on, and whether the old Zendesk address will forward mail to it for a defined period. Update the reply-to address, signatures and any system notifications that name the old support domain. Also check that user records carry the email addresses customers actually use, because a ticket created from an address that does not match a user record can open as a new customer and split their history.

Notification templates and automation need a separate check. The Zendesk migrator covers groups, organizations, users and tickets, so confirm how your Zendesk triggers, automations, macros and email templates will be recreated in Zammad. Map each one to a Zammad trigger, notification or macro, and decide which ones are still needed. Agents will notice quickly if an acknowledgement email stops firing or a status change no longer notifies the right group. Test each template with a sample ticket in the test instance, and record who approved the final wording so that the team can answer questions after launch.

The support messages should cover both periods. Before cutover, tell agents and customers the cutover date, the new support address, the expected period when the old system stops accepting new tickets, and the password reset steps. After cutover, send a short confirmation that the new system is live, explain how to report a missing ticket or a sign-in problem, and state how long the old address will forward messages. Ask the project owner to approve each message and its timing in writing. Illustrative example: a customer who receives the reset instructions one week early is far less likely to contact the team on cutover day.

Questions buyers ask before moving from Zendesk to Zammad

How much does it cost to move from Zendesk to Zammad with outside help?

There is no fixed price here because DeployOpen does not publish a price list, and a quote follows from the written scope. The main cost components are planning and scoping, the migration build, test imports, cutover support, and any post-move hardening, documentation or training. Costs rise with the number of groups, organizations, users and tickets, the volume of attachments, the amount of Zendesk configuration that must be mapped, and the number of test rounds needed before sign-off. Zammad runs in your own cloud or data center, so hosting is a separate cost that you pay directly. Ask for a quote that lists each deliverable, marks which costs are one-time and which recur, and states what your team must provide. Zammad's own support subscription is bought from Zammad and is optional.

Does self-hosted Zammad have a license fee, and what does it cost?

Self-hosted Zammad has no license fee. Zammad is licensed under the GNU Affero General Public License version 3, so you can run the software in your own infrastructure without a license charge. Your recurring costs then come from servers, storage, backups and staff time, plus any optional support. According to Zammad's pricing page, self-hosted support subscriptions are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. Hosted Zammad is a different model: Starter at 7 EUR, Professional at 16 EUR and Plus at 25 EUR per agent per month, with Starter on annual billing, hosted in a data center in Germany. Confirm current prices, tax treatment and terms with Zammad before you build the budget, because vendor pricing can change.

What do Zammad's support tiers cover and how fast do they respond?

Zammad publishes three self-hosted support tiers, and each has a stated response time. According to Zammad's pricing page, Business responds within 6 hours, Enterprise within 4 hours and Corporation within 2 hours. The annual costs are 2,999 EUR, 5,999 EUR and 9,999 EUR. Confirm with Zammad what each tier includes, such as upgrade help, configuration questions and bug fixes, and how the response clock is measured, including whether it runs on business hours. A support subscription does not replace the planning, test imports and cutover plan that a migration needs. For budgeting, treat the subscription as a recurring line that is separate from the one-time migration project.

How long does a Zendesk to Zammad migration take?

No duration can be stated from the facts available here, so treat any number you hear as unverified until it appears in a written scope. Elapsed time depends on how much data moves, how many objects need mapping, and how long each test import takes. Zendesk API rate limits affect how long a large import runs, so timing depends on your Zendesk plan and the volume of tickets. Other drivers include the time to create the migration API token and confirm access, the number of rounds needed for test import review by agents and managers, the cutover window your operation can accept, and the time to prepare Zammad's infrastructure if it is not already in place. Ask for a timeline broken into phases, with named dependencies and the steps your team must complete before the build starts.

What does our team need to provide before the migration starts?

Start with access to Zendesk. The built-in Zammad Zendesk migrator needs your Zendesk URL, an administrator email address and an API token created for the migration. Confirm with Zendesk that your plan permits API access for this purpose. Next, inventory your data. Objects with Cyrillic strings cannot be migrated, so find them early and agree how they will be handled. On the Zammad side, you need servers or cluster nodes that meet Zammad's software requirements: PostgreSQL 15 or newer, Redis 7 or newer, and Nginx or Apache as the reverse proxy. Elasticsearch is optional but strongly recommended for faster search and attachment content search. Memcached is needed for multi-instance deployments. You also need named owners for groups, roles, email channels and final sign-off, and a clear decision on who tells users about password resets.

Can our internal team run the Zendesk to Zammad migration alone?

Often yes, because Zammad ships a built-in Zendesk migrator that covers the core import path. Whether your team should run it alone depends on skills and capacity. The work needs someone comfortable with Zendesk administration and API tokens, someone who can operate PostgreSQL, Redis and a reverse proxy, and someone who can test imported tickets against your routing, reporting and service rules. The highest risk sits in the cutover, which happens once because the migration does not run differentially, so a missed step can mean a rollback or a repeat. Ask whether your team has rehearsed a full test import, whether it can hold a cutover window, and who decides if the test results look wrong. DeployOpen plans, builds, tests and documents migrations inside your infrastructure under a fixed written scope, so you can compare that option with an internal plan on equal terms.

How does a single cutover work when there is no differential import?

A single cutover moves all of the data in one controlled window, and then agents and customers switch to Zammad. Because the migration does not run differentially, changes made in Zendesk after the final import do not carry over automatically. In general terms, the sequence runs as follows: rehearse with a test import into a non-production Zammad, check groups, organizations, users and tickets against Zendesk, fix mapping issues, freeze changes in Zendesk, run the final import, verify counts and samples, switch inbound email and other channels, and then set up user logins and password resets. Plan the freeze with agents so that no new tickets fall into the gap, and decide in advance how to handle anything created during that window. Ask for the runbook, the rollback point and the named person who makes the go or no-go call.

What happens to our Zendesk data after the migration is complete?

The migration copies data into Zammad and does not remove anything from Zendesk. Your Zendesk account keeps its tickets, users and settings until your team changes or closes it, so decide how long it stays readable for reference and who can access it. Check your Zendesk contract for export, retention and deletion terms, and confirm with Zendesk what you can export before any subscription ends. Inside Zammad, plan retention settings, backups and access roles for the migrated history, because imported tickets become part of your operating data in your infrastructure. Your data protection obligations apply to both systems during any overlap, so record which system holds the master copy after cutover and when the Zendesk copy will be retired. Ask your partner to document the final state in the handover.

How DeployOpen scopes and delivers the Zendesk to Zammad move

DeployOpen plans, implements and documents Zendesk to Zammad migrations inside infrastructure you control, starting with a written scope that covers what moves and what stays behind. Engagements are fixed-scope, so the deliverables, the test import and the cutover plan are agreed before any data is touched.

How we scope

Inventory Zendesk groups, organizations, users and ticket history to decide what migrates
Confirm the Zendesk URL, an administrator account and an API token created for the migration
Identify objects containing Cyrillic strings, which the Zammad Zendesk migrator cannot import

How we build

Stand up the target Zammad instance with PostgreSQL 15 or newer and Redis 7 or newer
Run a test import against a non-production copy and reconcile counts by object type
Document the single cutover window, since the migrator does not support differential runs

How we hand over

Deliver a runbook covering the import steps, cutover sequence and rollback decisions
Document password reset steps and the login guidance agents and customers will receive
Walk your administrators through the post-cutover checks and the open items list

How we support

Offer ongoing support, upgrades and testing as a retainer after the move
Keep the runbook current when Zammad releases change the migrator or deployment steps
Confirm the support route for the Zammad application you choose, since it is separate from your hosting platform