Zendesk Migration
In a Zendesk migration, moving the data is the easy half and everybody plans for it. The half that overruns is rebuilding the configuration, and nobody budgets for that.
What actually moves in a Zendesk migration
Records move. Behaviour does not. Every surprise below is a consequence of that one sentence.
Reliably transferable, whether you're coming in or going out:
Zendesk has a dedicated ticket import endpoint for this job. It accepts historical timestamps, takes a full comment thread, and does not fire triggers or send notifications. Import a year of tickets with the ordinary create endpoint instead and you will email several thousand people about problems they had last spring. It happens more often than you would believe.
What has to be rebuilt by hand
None of this transfers. Not partially, not with a tool. It's rebuilt, by a person, in the new system.
Ticket IDs change too. The new system assigns its own, so every reference in an email, a runbook or a knowledge base article points to nothing. Store the old ID in external_id during import. It costs nothing at the time and it is the only way to answer "what happened to ticket 44219" afterwards.
A realistic timeline
For a small team on a simple setup, three to four weeks. For a mid-sized team with several channels, integrations and a help centre, eight to twelve. Anyone quoting a weekend is describing the data copy and calling it the project.
Weeks one and two: audit
Inventory everything. Every trigger, macro, field, integration and automation. Then mark what you are keeping. Most teams find between a third and a half of it is dead, and deciding that now is far cheaper than rebuilding it and deciding later.
Weeks two and three: map and build
Field-by-field mapping, written down, including what happens to values with no equivalent. Then build the new configuration and get it reviewed by someone who works the queue, not only by the admin.
Week three or four: pilot migration
Migrate a sample: a few hundred tickets across ages, statuses, channels and attachment types. Then genuinely check it. Open tickets and read them, confirm timestamps, confirm attachments open, confirm the requester is the right person. This step gets skipped and it's the one that catches everything.
The cutover
Full historical load, which can run for days on a large account, then a freeze window, then a delta run for anything that changed while the main load was going. Point inbound email at the new address, and keep the old system available for months.
The duplicate problem a cutover creates
Two mechanisms, both predictable, both mostly unaddressed in migration plans.
The first is the delta run. You migrate everything up to Friday, then re-run for the weekend changes. If your delta isn't keyed on something stable, tickets already imported get imported again. This is exactly what external_id prevents: check for the old ID before creating, and make the whole import idempotent so you can run it twice without consequence.
The second is the parallel period. For a couple of weeks, mail flows to both systems, or customers reply to an old thread while raising a new ticket in the new one. One customer, one problem, two tickets in two products. Those pairs come with you when you consolidate, and they are hard to spot because the wording differs and the requester records may not even match.
Plan for it: forward the old address rather than leaving it live, close the old system to new tickets on a fixed date, and sweep the new account for duplicates after the parallel period instead of assuming it was clean. If you're moving between those two platforms specifically, the Freshdesk to Zendesk migration guide covers that pairing.
Migrating out of Zendesk
The same shape in reverse, with two Zendesk-specific notes.
Archived tickets. Anything closed long enough gets archived and stops behaving like a live ticket in views, search and some export routes. Pull history with the incremental export API, which reads from the database and includes them, then count what you got against a total from the API before you believe it.
Attachments. They come out as authenticated URLs rather than files, and the links stop working once your account lapses. Do it early, verify a sample opens, and keep the files somewhere that is not one person laptop.
Then keep read access to the old account for longer than feels necessary. Twelve months isn't paranoid. The first dispute that needs a ticket from before the cutover will arrive about three weeks after somebody cancelled the subscription to save money.
Frequently asked questions
Is there a Zendesk migration tool that does all of it?
Importers and third-party services move tickets, users and articles well. No Zendesk migration tool rebuilds triggers, macros, views or SLA policies, and that rebuild is where the time goes.
How long does a Zendesk migration take?
Three to four weeks for a simple setup, eight to twelve for a mid-sized team with multiple channels and integrations. The data copy is days. The configuration rebuild is the rest.
Do triggers and macros transfer between help desks?
No. Business rules are rebuilt by hand, because the logic models differ. Treat it as an opportunity to delete the third of them nobody uses.
Will ticket IDs stay the same?
No. The new system assigns its own. Store the old ID in external_id during import so historical references can still be resolved.
How do I import historical tickets without emailing customers?
Use the ticket import endpoint rather than the standard create endpoint. It preserves original timestamps, accepts a full comment history and doesn't fire triggers or notifications.
What gets missed most often?
Attachments and archived tickets. Both look fine in a row count and both are absent when someone opens an old ticket six months later.
Start the new account clean
Migrations import every duplicate the old queue accumulated, then the parallel period adds more. Ticket Merger clears the pairs and keeps the new queue honest.
Start free trial14-day free trial. No credit card required.