Key takeaways
- The exit costs more than the switch. Most Zendesk migrations stall not on price, but on the work of rebuilding triggers, macros, and SLAs by hand.
- Seat-based and resolution-based pricing are different bets. A 20-seat team on Zendesk Suite Professional, plus its AI Copilot add-on, runs close to $40,000 a year in fees alone.
- delight.ai's AI doesn't launch blank. Delight.ai actionbooks are synthesized directly from your own resolved ticket history, so the AI already knows your playbooks before day one.
CX leaders don't usually doubt where they're headed when they consider leaving Zendesk. What holds them back is more practical: the 2 weeks of rebuilding triggers, a pile of automations nobody remembers writing, and a knowledge base that has to move without breaking a single support link. Solve that, and swapping platforms stops looking like a quarter of lost productivity and starts looking like a resolution with a clear end date.
What happens when you migrate off Zendesk?
A Zendesk migration moves 3 things: ticket history, the knowledge base, and the automation logic that runs both. The first two are largely mechanical. Tickets export with their comments, statuses, and attachments intact, and knowledge base articles move with their categories and structure preserved.
The third is where most projects actually live. Triggers, macros, SLA policies, and routing rules are specific to Zendesk's own configuration model, so they don't carry over automatically to any destination platform. That gap, not the ticket count, is what actually decides how long a migration takes.
What moves with reasonable fidelity:
- Tickets: subject, body, comments, status, priority, and timestamps.
- Knowledge base articles: categories, sections, and article structure.
- Users and organizations: contact records, groups, and org hierarchy.
Zendesk's own export documentation confirms the same split: exports cover tickets, users, and organizations, but the business rules that route and resolve those tickets stay behind. Any team evaluating a switch needs to plan around that rebuild gap from the outset, not discover it mid-project. Delight Desk's Zendesk migration path is built specifically to close this rebuild gap.
What does it cost to leave, and what does it cost to stay?
Run the math on a 20-seat support team. Zendesk Suite Professional lists at $115 per seat per month, and its AI Copilot add-on, added after Zendesk's acquisition of Forethought, runs another $50 per seat per month on top of that. 20 seats on that plan cost roughly $40,000 a year in fees alone, before a single AI resolution is counted.
Delight Desk flips that model. The seat fee is $0, and the AI is priced per successful resolution instead of per seat. The two companies are betting on different things: Zendesk's revenue grows as teams scale, and Delight's grows only when the AI actually resolves a ticket.
Why do most Zendesk migrations stall before they start?
Gartner found that 91% of customer service leaders felt under pressure to implement AI in 2026. Most of that pressure lands on whatever platform a team already runs, not a platform it's about to choose. That's the quiet reason so many Zendesk evaluations start and then go nowhere.
The team isn't weighing Zendesk against a competitor's feature list. It's weighing the AI project it needs against the years of triggers, macros, and SLA rules already built around the ticketing system it has.
Forrester's 2026 customer service predictions point at the same problem from another angle. Forrester expects 2026 to bring "gritty, foundational work" rather than dazzling transformation, warning that service quality will dip short-term as teams wrestle with deployment complexity and change management, the same kind of complexity a migration adds on top of. When a project already means rebuilding an entire operation by hand, it's easy for a team stretched thin on AI deployment to let a contract quietly auto-renew instead of taking on more change at once.
Rebuilding routing logic, SLA policies, and years of macros is slow, error-prone work that nobody wants to own. That work is why so many migration decisions stall at the evaluation stage.
What doesn't survive a Zendesk migration?
What doesn't move automatically in almost any Zendesk migration:
- Triggers and automations: the rules that route, tag, and escalate tickets.
- SLA policies: response and resolution targets tied to priority and plan.
- Macros and canned responses: reusable replies tied to specific workflows.
- Connected integrations: every tool wired into the old ticketing system.
Triggers, macros, and routing rules
Zendesk's automation logic is specific to Zendesk. None of it exports in a form another platform can read directly, so a receiving team recreates every trigger, every macro, and every routing rule by hand, one at a time, inside whatever workflow builder the new platform provides.
SLA policies and escalation logic
SLA models don't map cleanly between platforms either. A team can't import an SLA policy the way it imports a ticket. It has to reconstruct the policy's logic from scratch, then test it against real cases before trusting it in production.
Every connected integration
Every tool wired into the old ticketing system, including the CRM, the ecommerce platform, and Slack, needs to be reconnected and tested in the new one. None of that work is technically hard. All of it is time, and time is what keeps teams on a platform they've already outgrown.
What if the AI didn't need you to rebuild anything?
Most migrations hand a support team a blank AI. It answers from whatever knowledge base articles it's given and nothing else, so a team spends the first few months teaching it, in real time, the lessons the old platform's tickets already contained.
How to skip the ramp-up
There's a way to skip that ramp-up. Instead of starting blank, an AI can read a team's own resolved ticket conversations from the old platform directly: which requests came up most often, which resolutions actually worked, and which tickets closed clean without a reopen or an escalation. It groups those conversations by intent, refunds, address changes, troubleshooting steps, and drafts a playbook for each one.
Delight.ai actionbooks
delight.ai calls these drafts Actionbooks: a documented sequence of what to say, what to ask, and when to call a system or hand a case to a person, built from what a support team's own history proved effective. None of that publishes on its own. Every draft goes to a person for review before it goes live, and each one is checked against current company policy first, so an outdated or off-policy resolution pattern doesn't quietly become the AI's default answer.
Ticket histories show what a support team actually did, not what it should have done. Learning only from tickets with a good outcome, and checking the result against policy, is what keeps this shortcut honest rather than turning a blank AI into a mistrained one. Coupang Eats already ran a migration like this at scale: more than 14 million users moved off Zendesk in June 2026, with the new AI carrying forward the resolution patterns from its old ticket history instead of starting over.
McKinsey's 2026 AI trust research found that security and risk concerns, not technical limits, are now the top barrier organizations cite when scaling agentic AI. It also found that organizations with clear ownership over how an AI's actions get reviewed reach higher trust maturity than those without it. A reviewed-before-publish step for every AI-drafted playbook is what that ownership looks like in practice, the same discipline a dedicated governance layer, like Trust OS, exists to make auditable.
Questions worth asking before you commit to a migration
Before signing off on a destination platform, get specific answers to these:
- What actually migrates, and what doesn't? Get a list, not a reassurance.
- Does the AI start from your data, or from a template? The difference decides your first quarter.
- What happens to every public help center link? A broken redirect is a broken customer trust signal.
- What does compliance actually require you to verify? A certification name isn't the same as its scope.
What actually migrates, and what doesn't?
Ask for a specific list, not a general reassurance. Tickets, knowledge base articles, and user records should have clear answers. Triggers, macros, and SLA policies almost never do, on any platform, so the honest answer describes what happens to those instead of a promise that they simply appear on the other side.
Does the AI start from your own data, or from a template?
A generic AI, trained on nobody's specific history, starts every migration from zero. One trained on a team's own resolved tickets starts already knowing the requests that come up most and the answers that work, which changes what the first quarter after go-live actually looks like.
What happens to every public help center link?
A support team's knowledge base is indexed by search engines and bookmarked by customers. Migrating it without mapping a redirect from every old article URL to its new equivalent breaks both. That redirect map is not optional detail; it's the difference between a quiet migration and a support inbox full of broken-link complaints.
What does compliance require you to verify?
Compliance-led buyers can't stop at a vendor's marketing page. Ask for the actual certifications, SOC 2 Type II, ISO 27001, GDPR, and a HIPAA report, and confirm which type of report it is.
A Type I HIPAA report attests that controls are designed correctly at a single point in time. A Type II report attests they held up over a period. Those are different claims, and a compliance review that treats them as interchangeable finds out the difference at the worst possible time.
In closing
None of this makes the decision to leave any easier, and none of it makes a rebuild optional if the destination platform needs one. What changes is which parts of that rebuild a team has to do by hand, and which parts an AI can do first, from the team's own history, before a single seat goes live on the new platform. See how Delight Desk's guided path off Zendesk maps out, end to end.
