Migrating from Zendesk: what to bring, what to leave, and how to cut over

Zendesk migrations fail in two opposite ways: teams that try to recreate their entire Zendesk configuration in the new tool and drown in the attempt, and teams that bring nothing and lose years of answered questions. The successful version is selective — bring the history that grounds future triage, bring the intent of your automations, and leave the configuration debt behind.

This guide assumes the common split: an internal queue (IT, engineering support, employee requests) moving to a purpose-built internal tool, while external customer support may well stay on Zendesk, which remains good at that job. Migrating half your Zendesk is normal and often correct.

The export checklist

Zendesk’s UI export gives you ticket fields; it does not give you the conversations, and the conversations are where the resolutions live. Use the API (or a migration service) to pull the full record.

• •Tickets with fields, tags, custom fields, timestamps, and requester/assignee — the skeleton.
• •The comment thread per ticket, public and internal notes both — the actual knowledge.
• •Macros — as text, because they are your canned-answer corpus even if the macro mechanism does not migrate.
• •Trigger and automation definitions — as documentation of intent, not as a rebuild spec.
• •Help-center articles for the categories that are moving, if the new tool grounds AI answers in docs.
• •Attachments policy decision: migrating binaries inflates every step — most teams keep attachments in the archive.

Decide what the new tool should even have

A mature Zendesk instance carries years of sediment: hundreds of macros nobody has audited, triggers that fire on conditions nobody remembers creating, fields added for a project that ended in 2023. The migration is your one natural opportunity to not carry that forward.

The test for each automation: what was this for? Routing triggers and priority rules are replaced wholesale by AI triage — that is a category deletion, not a porting task. Macros split into two piles: answers (which become knowledge the AI grounds on) and process steps (which become allow-listed actions or die). SLA policies port as policy, not as configuration — re-express them in the new tool against the same targets.

History: import the useful window, archive the rest

Full-history imports feel safe and are mostly weight. The pragmatic split: import open and recent tickets (commonly 6–12 months — enough for AI triage to learn your queue’s patterns and for "have we seen this before" to work), and keep the old Zendesk instance in read-only mode, or a searchable export, as the deep archive.

Verify the import the boring way: counts by status and month against the export, spot-check twenty tickets end to end including threads, and confirm requester identities mapped — orphaned tickets assigned to "imported user" help nobody.

Cutover: two weeks in parallel

Same pattern as any queue migration: new tickets to the new tool from day one; open Zendesk tickets drain where they are; two weeks of parallel running while the team works real volume in the new system. Redirect intake at the sources — the support email forwards, the Slack workflows repoint, the portal links swap — rather than asking requesters to change behaviour.

For an internal queue moving to FlowTux specifically, the sequence that works: import the recent window, connect the repo and error tracker, run triage in suggest mode during the parallel weeks (it learns while the team validates), then promote categories per the 30-day rollout plan. The migration and the AI ramp-up become the same two weeks instead of two projects.