TL;DR: Plan a Zendesk migration as a two-to-four-week sequence of audit, rebuild, parallel testing and cutover, with a seven-week option for teams that want extra testing time. Timing matters most, because cutover brings a temporary productivity dip: the new platform should be fully live at least six weeks before peak starts, which means early October for a mid-November peak. If that date has passed, migrate in January. Cut over email first and phone last. Most Dixa customers who moved from Zendesk went live within that window, with dedicated onboarding. Macros, triggers and automations must be rebuilt rather than imported, and Explore reports must be exported before you switch. Teams usually leave over add-on and per-resolution AI costs, so compare those lines first.
If you've decided to leave Zendesk, the work ahead is a sequence of audits, exports and cutover decisions. Getting the order of audit, mapping, cutover and post-go-live QA right is what keeps CSAT steady through the switch. About 70% of Dixa's customers came from Zendesk, according to Dixa, and most teams migrated in two to four weeks with dedicated onboarding support. This checklist treats that two-to-four-week range as the main path and offers a seven-week option for teams that want extra testing time.
Migration checklist at a glance
The schedule below spans four weeks, the upper end of the range. Smaller migrations with fewer integrations can overlap phases and finish sooner.
Week 1: audit and export
- Count tickets, contacts, organisations and attachments.
- Inventory macros, triggers, automations, views, groups and custom fields.
- Map every integration and the direction its data flows.
- Export the Explore dashboards and reports you need to keep.
- Run a trial export on one date range to measure how long it takes.
Week 2: rebuild and import
- Rebuild macros, triggers, automations, SLA policies and routing rules on the new platform.
- Clean and deduplicate contacts before import.
- Import historical data, then plan a delta import for tickets that arrive later.
Week 3: test and train
- Start running both systems in parallel, and keep them running for at least a week before cutover.
- Train superusers first, then the full team.
- Test every automation and integration with dummy tickets.
Week 4: go live
- Cut over one channel at a time, with email first and phone last.
- Keep Zendesk in read-only mode for 30 days.
- Track first response time, resolution time, backlog age and CSAT daily.
The seven-week option, with two full weeks of parallel testing, is laid out under "Realistic timeline for a Zendesk migration".
The operational triggers for leaving Zendesk
Dixa's customers moved from Zendesk for a simpler platform, lower AI cost per resolution and hands-on help shipping changes. Zendesk reviews on G2 and Capterra describe the same frictions. On G2, more than 180 reviews mention a steep learning curve that makes initial setup hard. Capterra reviewers describe add-on pricing that raises costs as teams add agents, features or AI, and one says managing the add-ons can feel like a full-time job in the backend.
Planning for peak-season risk
On nShift's platform, Black Friday 2025 carried more than twice the shipments of an ordinary early-November Friday, and the peak lasted five weeks, from 17 November to 21 December. Support demand tends to follow shipping, so a platform change inside that window competes with your busiest weeks. Choose the cutover date first and build the rest of the plan backwards from it. Review your own incident log from last peak to see how much disruption your current setup caused.
Reporting limits and Explore exports
Explore dashboards and reports live in Zendesk. Zendesk's export documentation says a dashboard exports one tab at a time and a report exports from within the report, so export every dashboard and report you need before you switch. Without those exports you lose your year-over-year trend lines. Reporting is also a common reason to switch: Dixa reports that 49% of the customers who switched cited it, making it the most-cited pain in its won deals. Real-time dashboards ship with Dixa's entry plan, which means you can answer the CFO's question about queue depth on a Tuesday afternoon without exporting a spreadsheet first.
Add-on and AI costs compared
Zendesk's pricing page bills AI agents per automated resolution at $1.50 committed or $2.00 pay-as-you-go beyond an included allowance. Phone is built into its Suite plans, though call minutes and phone numbers are billed as add-ons, and teams with complex contact center needs buy the separate Contact Center add-on. Those lines grow with volume and headcount. Dixa lists Growth at €89, Ultimate at €139 and Prime at €179 per agent per month, with voice included on every plan and a 20% saving for annual billing. Mim costs €0.40 per conversation within contracted volume, whether it resolves or escalates. Dixa's Overage Price List sets the rate for conversations beyond contracted volume at €0.60.
Critical audit steps before migrating Zendesk
Start by inventorying everything that lives in Zendesk configuration, because an export of tickets doesn't recreate it: custom fields, tags, workflows, macros, triggers, automations, third-party integrations and API connections. The audit tells you what has to be rebuilt, what can be deleted and what could break the export.
Data migration scope and volume audit
Document your total ticket count, contact records and attachment volume. Volume decides how you export, because Zendesk recommends splitting large exports by date range. The full set of limits is covered under "Exporting Zendesk data before you switch".
Inventorying active macros and rules
Document the following:
- Active macros, and how often agents use them.
- Triggers and automations, including their schedules and what fires them.
- Views, and who uses them.
- Groups and their members.
- Custom fields and their purposes.
- Integrations, including connected apps, API connections and webhooks.
Inventory your current integration ecosystem
Your help desk likely feeds your CRM, BI tools, Slack channels and reporting systems. Document every integration and which direction its data flows, so no connection breaks after migration.
Mapping agent permissions for migration
Document current agent roles, group memberships and permission levels. Note which agents have admin access, which are restricted to specific brands or departments, and which have API access tokens. Replicate this structure in the new platform to avoid productivity dips.
Tracking custom field migration risks
List every custom field, its type (dropdown, text, numeric) and its current usage rate. Fields with zero usage in the last 90 days are candidates for deletion rather than migration. Fields with inconsistent data entry formats need normalisation before import to prevent duplicate records.
Zendesk migration: eight stages across two to four weeks
The eight stages are numbered in the order they happen, and the timeline later in this guide shows where each one lands. Stages that share a week run side by side.
1. Exporting Zendesk ticket history
Export tickets first, along with comments, attachments, users and organisations. Zendesk's incremental exports are limited to 10 requests per minute and return up to 1,000 records per page. At those limits, the ticket records alone for a 200,000-ticket account need about 200 requests, roughly 20 minutes of API time. That estimate excludes comments, attachments and retries, which add significantly to the total, so run a trial export on one date range to measure the real duration before you book a window.
2. Rebuild macros and rules on the new platform
Plan to rebuild macros, triggers, automations, SLA policies and routing rules on the new platform, because a ticket export doesn't recreate them. Use the rebuild to delete outdated macros and consolidate redundant responses.
3. Define triage flows and channel access
Cut over in phases. Start with one channel or one customer segment, such as email, while the rest stays on Zendesk. Write a triage flow for each channel so every conversation has an owner from the first day.
4. Reconnect integrations and workflows
Reconnect each integration you mapped in the audit, then test the rebuilt workflows against it. Give this work its own block of time in the plan.
5. Train your team for a smooth cutover
Plan for a temporary dip in agent productivity. One published migration guide estimates a 20–40% drop for the first four to eight weeks. That figure is an estimate, so treat it as a planning assumption and compare tickets resolved per hour with your pre-migration baseline. Schedule training sessions during your slowest queue hours to protect live SLAs.
6. Run parallel testing before cutover
Run both systems in parallel for at least a week before cutting over, or two weeks on the seven-week plan. Import your historical data to the new platform first, then run a delta import to bring over anything that arrived between the main import and go-live.
7. Execute end-to-end migration testing
Verify that macros fire correctly, routing rules assign conversations to the right queues, and agent permissions match your documented specifications. Test every integration point with live data before you cut over.
8. Schedule your cutover
On cutover day, pick a quiet day of the week. Point email forwarding, the chat widget, phone numbers and social accounts at the new platform, and keep Zendesk in read-only mode.
Exporting Zendesk data before you switch
Zendesk's export documentation sets the limits that shape the plan. UI exports and CSV downloads have no strict frequency limit, but exports of more than 100,000 records might time out. API exports are rate limited, and incremental exports are recommended for large datasets.
Which records to export and why
Export all ticket data, including comments, attachments and custom field values. Export user records with their tags and notes, and organisation records with their domain mappings. Export the Explore dashboards and reports you need to keep, one tab at a time.
Handling Zendesk export limitations
Match the export method to the size of the account:
- Small accounts: run a single export, then validate the record counts.
- Mid-size accounts: split exports by date range, as Zendesk recommends.
- Large accounts: use the Incremental Exports API, which allows 10 requests per minute, and plan a delta import for tickets that arrive during the migration.
Zendesk's rate-limits page lists incremental exports at 10 requests per minute, or 30 with the High Volume API add-on, which is available on Suite Growth and above.
Sanitising records before import to the new platform
Deduplicate and clean records in this order:
- Match in layers. Start with exact matches on business email, external IDs and normalised phone numbers, and use names and company names only as supporting signals.
- Send mid-confidence matches to human review instead of auto-merging them.
- Back up records first.
- Merge accounts before contacts.
- Check that tickets, notes and ownership still point to the master record.
- After go-live, use upserts tied to stable external IDs and track the duplicate rate so duplicates don't regrow.
Rebuilding Zendesk automations on the new platform
Zendesk triggers, macros and views have to be rebuilt as workflows, quick actions and assignment rules on the destination platform.
Mapping current Zendesk automations
For each element, document it and recreate it on the target platform. Map trigger logic manually, since triggers become workflow rules or automations on the target. Recreate time-based rules with the target platform's automation builder.
Changing routing rules without IT
If routing changes currently wait in an IT queue, the rebuild is the moment to change that. Dixa's Conversation Engine includes rule-based intelligent routing on every plan, with skills-based and external-data routing on Ultimate and above. In its no-code builder, your CS team can change a routing rule without IT.
Final QA checks for new automation rules
Test every automation with dummy tickets before go-live. Verify that time-based triggers fire at the correct intervals, that macros insert the correct dynamic content, and that routing rules assign conversations to the correct agent groups.
Zendesk migration cutover and risk mitigation
A migration costs your team some speed for a few weeks, and that cost is hardest to absorb when it overlaps peak season. Finish cutover at least six weeks before peak starts. In 2025 the peak on nShift's platform began on 17 November, so the deadline for a peak like that is the first week of October. If you miss that window, January, after the peak clears, is the next safe option.
Channel migration order for Zendesk
Start with email, then chat, then social, and move phone last. Email has the least real-time dependency, so it lets you verify routing and macros without live customer impact. Phone carries the highest risk of service interruption because it requires number porting. Phone migration is simpler when voice is native to the platform, since no separate telephony vendor cutover is needed. Dixa includes native voice on every plan, so phone moves with the same platform and routing as the other channels, and the number port is the only separate step.
Change freeze and rollback
Whichever platform you run, freeze configuration changes for the six weeks before peak. If you've missed the migration window, use that time to fix data and rules in your current setup instead of starting a new project. Keep Zendesk in read-only mode for 30 days after cutover. That lets you reference historical tickets if something fails to import correctly, and it gives you a rollback option if the new platform has critical failures in the first week.
Guiding your team through the migration
Every Dixa plan includes a named Customer Success Manager from day one. The CSM co-owns the migration timeline with you and stays your primary contact through stabilisation and beyond.
Setting your Zendesk migration timeline
Dixa's own figure is two to four weeks for most Zendesk migrations, with hands-on onboarding. This checklist treats that range as the main path and offers seven weeks for teams that want extra testing time. Data volume, automation complexity and the number of integrations move the timeline in either direction.
Selecting your migration superusers
Identify one agent per team or channel who will learn the new platform first. These superusers train their peers and serve as the first line of support during the transition week. Choose agents who are technically curious and respected by their peers, whatever their seniority.
Managing agent buy-in during migration
Address workflow blockers within 24 hours so frustration doesn't turn into resistance. Hold daily check-ins during the first week to surface usability problems early, then move feedback collection into your existing team standups for the first month.
Realistic timeline for a Zendesk migration
Plan the timeline backwards from the six-week buffer before peak. The table shows the full four-week sequence. If your peak starts in mid-November, week 4 should end in early October, which puts week 1 in early September, and a shorter migration can start later. Adjust the weeks below to your own peak start date.
Seven-week option for extra testing time
Teams that want more room can stretch the plan to seven weeks. On that path week 7 ends in early October for a mid-November peak, which puts week 1 in mid-August, and parallel testing runs for two full weeks.
Testing and refining your new platform setup
Track first response time, resolution time, backlog age, escalation rate, CSAT, CES and FCR after go-live, and compare each one with the baseline you captured before cutover.
KPI targets after go-live
Identifying agent workflow blockers
Watch for agents switching back to old habits or creating workarounds outside the new system. These behaviours point to training gaps or workflow design flaws that need immediate correction.
Reporting and integrations after go-live
Real-time dashboards come with every Growth plan, and Advanced Insights, which adds AI-powered contact-reason categorisation and sentiment detection, is included on Prime and available as an add-on on Growth and Ultimate. Dixa's native integrations pull order data from Shopify, Magento and WooCommerce, and customer data from Salesforce, HubSpot and Microsoft Dynamics 365.
Book a demo to see what migration would look like for your stack.
FAQs
How long does a Zendesk migration typically take?
Plan on two to four weeks, or seven if you want extra testing time. Dixa reports that most Zendesk customers went live in that window with hands-on onboarding, and data volume, automation complexity and integration count decide where you land in it.
Can we migrate during peak season?
Avoid it. A platform change during peak, or in the six weeks before it, competes with your busiest weeks and costs your team some speed for a few weeks. Fix data and rules in your current setup instead, and plan the migration for January.
What data can't be exported from Zendesk?
Tickets, users and organisations export through Zendesk's UI, CSV and API exports. Explore dashboards and reports export one at a time. Macros, triggers, automations and SLA policies are configuration rather than ticket data, so plan to rebuild them on the new platform.
Do we need IT resources for the migration?
Your IT team handles the initial export and API setup. After that, Dixa's no-code builder lets the CS team own routing and automation changes.
What happens to our historical reporting after migration?
Historical reporting stays in Zendesk. Export all the reports you need to a data warehouse or CSV files before cutover. Real-time analytics start fresh on the new platform, and historical trend analysis uses the exported archive.
Key terms glossary
Incremental Exports API: Zendesk's API endpoints for exporting ticket data in batches of up to 1,000 records, at up to 10 requests per minute, or 30 with the High Volume API add-on.
Delta import: A secondary data migration that captures any tickets or updates created between your main historical import and your final cutover date.
Read-only mode: A configuration state where agents can view historical tickets in the old system but can't create new tickets or updates, which prevents data fragmentation during the transition.
Parallel testing: Running both the old and new platforms at the same time for a limited period to verify data integrity and workflow functionality before full cutover.
Superuser: An agent selected to receive advanced training on the new platform, who then serves as a peer trainer and first-line support resource during the migration week.
Change freeze window: The period before peak season when system changes are halted to reduce operational risk. This checklist uses six weeks.
Migration cutover: The specific date and time when live customer conversations switch from the old platform to the new one, which requires coordination across all channels.
Author
Stay in the know
Get CX insights, proven strategies, & the latest news in your inbox every month!