A complete Zendesk migration comes down to six phases: audit what you have, map your data, decide what moves, run both systems in parallel, cut over deliberately, and verify nothing was lost. Skip any one of them and you'll find out which one mattered — usually at 4:55 p.m. on cutover day.
Whether you're leaving Freshdesk, Intercom, or a shared Gmail inbox held together with labels and hope, the process is the same. The fear is the same, too: what if we lose our history? You won't — if you follow the checklist. We've run this playbook as a Zendesk Premier Partner enough times to know exactly where migrations go sideways, and every failure point below is preventable.
What should you audit before migrating to Zendesk?
Before anything moves, inventory four things: your data, your workflows, your integrations, and your people. Most migration horror stories start with an audit that never happened.
- Data: How many tickets, contacts, and organizations exist? How many are active versus ancient? A ten-year archive of closed tickets may not need to migrate at all — it may just need an export.
- Workflows: List every automation rule, canned response, and routing rule in your current tool. Half will be obsolete. Migrating them blindly means importing your old mess into a clean system.
- Integrations: Every tool that touches your help desk — CRM, billing, e-commerce, Slack — needs a Zendesk equivalent identified before cutover, not after.
- People: Who are your agents, what are their roles, and who owns the migration decision when something ambiguous comes up? Name that person now.
What migrates cleanly — and what doesn't?
Tickets, contacts, organizations, attachments, and tags generally migrate cleanly. Automations, reports, and anything platform-specific do not — plan to rebuild those by hand.
Moves cleanly
- Ticket subjects, descriptions, and full conversation threads
- Contact and organization records
- Attachments (with size limits worth checking)
- Tags, statuses, and priorities — with a mapping table
Needs rebuilding
- Triggers, automations, and macros — the logic concepts differ between platforms, and rebuilding forces a healthy cleanup anyway
- Reports and dashboards — start fresh in Zendesk Explore
- Knowledge base articles — these often move, but formatting and internal links usually need a manual pass
- CSAT history — some tools export it, some hold it hostage; know which yours is
The honest trade-off: a migration is never a perfect photocopy. Decide up front what's essential (conversation history, customer records) and what's acceptable to leave behind (2019's dashboard nobody opened).
How do you map data between help desks?
Data mapping means building a field-by-field translation table between your old system and Zendesk — every status, priority, custom field, and agent account matched to its destination before a single record moves.
The gotchas that bite most teams:
- Statuses don't match one-to-one. Your old tool's "Waiting on Customer" needs a deliberate home in Zendesk — likely Pending — and everyone should agree on it in writing.
- Custom fields need to exist first. Create them in Zendesk before the import, or that data arrives with nowhere to land.
- Agent mapping matters. Tickets need to arrive assigned to real Zendesk agent accounts, not to a generic import user — otherwise your historical reporting starts at zero.
- Requester email is the join key. Duplicate or malformed emails in the old system become duplicate customers in the new one. Clean them before, not after.
Should you run both systems in parallel?
Yes — briefly. A short parallel run is the single best insurance policy in any migration, and it costs you almost nothing.
Here's the pattern that works:
- Migrate your historical data into Zendesk while the old system stays live.
- Point new inbound conversations at Zendesk first — new email address routing, new widget, new forms.
- Let agents work open tickets to closure in the old system rather than migrating in-flight conversations mid-thread.
- Run a delta migration at the end to sweep up anything created during the overlap.
Two weeks of parallel running is usually plenty. Longer than a month and you're not running parallel — you're maintaining two help desks, and agents will quietly pick a favorite.
What happens on cutover day?
Cutover day is deliberately boring if you've done everything above. The checklist: repoint your support email addresses to Zendesk, flip the website widget and help center links, disable ticket creation in the old system, and announce the change internally before customers notice anything.
Pick a low-volume window — midweek, not Monday morning. Keep the old system in read-only mode for a quarter or so; someone will need to check an old thread, and "we deleted it" is not a great answer. And assign one person to watch the new-ticket queue for the first 48 hours like it owes them money.
How do you verify zero data loss?
Verify with counts, then with spot checks. Compare ticket totals, contact totals, and attachment counts between systems — they should reconcile exactly, with any variance explained (deliberately excluded records, spam, duplicates you merged).
Then sample: pull twenty random tickets across different years, statuses, and agents, and read them side by side. Check that threads are complete, attachments open, and requesters are correctly linked. Counts catch missing records; spot checks catch mangled ones. You need both.
If you'd rather have someone run this entire checklist for you — audit through verification — that's precisely what our Zendesk setup process covers. Talk to us before you move a single ticket.
Frequently Asked Questions
How long does a Zendesk migration take?
Most small-to-mid-size migrations take two to six weeks end to end: about a week for auditing and mapping, one to two weeks for test migrations and workflow rebuilds, a short parallel run, then cutover. Data volume matters less than workflow complexity — rebuilding automations is usually the long pole.
Will I lose my ticket history when switching to Zendesk?
No — ticket history, conversation threads, contacts, and attachments migrate reliably when the migration is mapped and verified properly. What doesn't transfer automatically are automations, macros, and reports, which need to be rebuilt in Zendesk. Losses happen from skipped verification, not from the platform.
Can I migrate to Zendesk from a shared email inbox?
Yes, and it's often the easiest migration type. Historical emails can be imported as tickets or archived, and new mail simply forwards to Zendesk. Since a shared inbox has no automations or custom fields to map, most inbox-to-Zendesk moves complete in days rather than weeks.