Migrating from Zendesk without the re-platform pain

You can move off Zendesk without a re-platform project. Export your tickets, contacts, tags and macros as a re-importable snapshot; connect live mail to the new tool by forwarding or IMAP; sort out DKIM so replies sign as your own domain; and run both systems in parallel for a day or two before you flip routing. The two things that actually bite are conversation threading and email deliverability, so verify both on real samples before cutover.

Take a complete snapshot

Export tickets, contacts, tags and macros as one re-importable snapshot, and keep Zendesk live and read-only. You want to be able to re-import as many times as you need while you test — migrations are iterative, and the first import is almost never the one you keep.

How to export from Zendesk

Zendesk gives you a few export routes, and the right one depends on what you need:

• CSV / XML exports — account admins on eligible plans can export tickets, users and organizations. Good for contacts and ticket metadata; weak on full conversation bodies.
• The REST API — for complete conversation history (every public reply and internal note, with authors and timestamps), page through the Tickets and Ticket Comments endpoints. This is the dependable way to get threads, not just headers.
• Macros and triggers — export or list these so you can rebuild them deliberately rather than guessing.

Pull attachments explicitly; they're referenced by URL and those links can stop resolving once the Zendesk account is closed.

Import via email, not magic

There's no one-click importer that perfectly clones Zendesk into another tool, and you shouldn't trust one that claims to be. In practice you use two paths together:

• Live mail via IMAP / forwarding — route new inbound mail to Cherryrise so fresh conversations land in the shared inbox right away. This carries your real traffic during cutover.
• Historical tickets via import — load exported tickets and contacts as a searchable snapshot so agents keep context. Treat it as reference history, not live threads.

Get live mail flowing first; backfill history second. Don't hold go-live hostage to a perfect history import.

Preserve threading

The thing migrations break most is conversation threading on forwarded and CC'd chains. When mail is forwarded or history is imported, a single thread can shatter into orphaned tickets. Verify a few old threads read as one conversation, not ten orphans, before you trust the import — and check that follow-ups from the same customer thread onto the existing ticket rather than opening a new one.

Handle deliverability on day one

Publish DKIM and a custom return-path ahead of the flip — see the deliverability guide. This prevents the "why is this in spam" wave on the first morning.

Cherryrise uses BYODKIM: you bring your own DKIM key and send through your own AWS SES, so outbound replies are signed as your domain instead of a shared vendor sender. A migration is exactly when this matters, because your sending path changes at the same time as your tool. If the terms are fuzzy, the DKIM explainer and reply-to vs from are worth reading first.

DNS and DKIM cutover

The DNS changes are few but unforgiving. Stage them before go-live:

• DKIM — publish the signing-key records so the new sender validates against your domain.
• SPF — authorize the new sending path (SES) in your single SPF record; don't create a second one.
• Return-Path — set a custom return-path on your own subdomain so bounces and alignment work for you.
• DMARC — if you publish DMARC, confirm DKIM or SPF aligns with the visible From domain before tightening the policy. The SPF/DKIM/DMARC post covers how they interact.

Lower your DNS TTLs a day ahead so changes propagate quickly, and run a test send through the new tool before any customer mail touches it.

Mapping Zendesk concepts

Most of your setup translates, with some renaming:

• Macros and triggers → canned replies and automation you can test before shipping.
• Views → saved views with custom filters.
• Roles and light agents → RBAC, including assigned-only agents who see only their own tickets.
• SLA policies → re-create your SLA tiers against real business hours rather than importing them blindly; see how to set SLAs.

On pricing, Cherryrise is per-agent with no per-resolution or deflection fees, so you're not penalized for volume or for adding viewers.

Guide and redirects

If you run Zendesk Guide, plan the help-center move so you don't lose links or ranking:

• Export your Guide articles and re-publish them in the Cherryrise white-label help center.
• Add 301 redirects from old Guide URLs to the new ones wherever you control the domain; prioritize the articles with real traffic and inbound links.
• The Cherryrise portal is passwordless via magic link, so customers don't migrate accounts — they click a link to see their tickets.

Run in parallel, then flip

Forward a copy of new mail to Cherryrise while Zendesk still receives it. Agents work in the new tool; Zendesk stays read-only as a safety net. After 48 clean hours — threading holding, replies authenticating, SLAs counting right — flip forwarding (or MX) fully and set the old account read-only. Parallel running for a couple of days is cheap insurance against a one-way cutover that fails at 9am. The same sequence works for Freshdesk, and the vs Zendesk page covers the broader trade-offs.

Frequently asked questions

Can I export my full Zendesk ticket history?

Yes. CSV and XML exports cover users, organizations and ticket metadata, but for complete conversation history with every reply and internal note you should page through the Zendesk REST API. Import that as searchable reference data rather than blocking go-live on it.

Is there a one-click Zendesk-to-Cherryrise importer?

No, and be skeptical of any tool promising a perfect clone. You use two paths together: forwarding or IMAP carries live mail into the shared inbox from cutover onward, and a historical import loads your exported tickets as searchable reference.

How do I keep replies out of spam after switching?

Authenticate before you cut over. Publish DKIM, authorize the new sending path in SPF, set a custom return-path, and confirm DMARC alignment. With BYODKIM you sign as your own domain through your own SES, which is the most reliable setup during a sender change.

What about my Zendesk Guide help-center URLs?

Re-publish the Guide articles in the Cherryrise help center and add 301 redirects from the old URLs wherever you control the domain. Prioritize the articles that get real traffic and external links so you keep your search ranking.