Moving off Zendesk comes down to three jobs: getting tickets and files out in a form you can read later, rebuilding the rules that routed work, and switching channels without a window where one message lands in two queues or in none.
Export in a format you can still read
Zendesk’s export article says account data such as tickets, users and organizations can be exported “to a JSON, CSV, or XML file”. The tools “are not available on Team plans”. JSON and CSV exports are not available in sandbox instances, so rehearse on production with a narrow date range.
The format decides what survives:
- CSV drops the conversation. The CSV export does not include deleted tickets, ticket comments or ticket descriptions. Export JSON or XML if what the customer said matters later.
- Size decides the method. The article recommends JSON for accounts with more than 200,000 tickets. Full JSON export for accounts with more than one million tickets downloads in 31-day increments. XML exports can reach a maximum file size of 500MB.
Decision rule: try the whole history once. If it fails, split by year, then by quarter, and keep each slice as its own file so a failed slice reruns alone. For a 480,000-ticket account, that is one attempt, then yearly slices if it errors.
Attachments need their own test. The export article doesn’t say whether file contents come with the export, so download a few files from a test range before you plan around them. Two limits decide what exists at all. For inbound email and web form tickets, a single file is limited to 50 MB. Zendesk’s attachment docs say that when a file exceeds that, the ticket is created without the attachment, so there is likely nothing to export for that file. For outbound email, a single file is limited to 7 MB and the total to 10 MB. Larger outbound files go out as a linked attachment. The docs don’t say how long those links last, so save copies of any linked files you need before you cancel.
Map users, groups and fields before any import
Zendesk’s Users API describes external_id as “A unique identifier from another system.” Create-or-update finds an existing user by email address or external ID, and the external ID search is not case sensitive. The failure mode: if two people share ops@acme.com, an import keyed on email updates one record and folds two people’s histories together.
Rules to apply:
- If the email belongs to one person, key on your own person ID and store the email as a contact field.
- If the address is a shared inbox such as billing@ or support@, never use it as a key.
- If a Slack Connect person has no email in Zendesk, create them with their Slack user ID as external_id, and merge when the email appears. Do the merge in the new system and leave the Zendesk records untouched, so reconciliation has something to compare against.
Map organizations one to one with customer accounts, and carry each Zendesk ticket ID onto the migrated thread as an external reference. You need that ID to reconcile after cutover.
Keep the rest of the mapping in one spreadsheet. Custom ticket fields map to a field with the same key. Groups map to queues, except a group that exists only as a routing target for a trigger, which becomes a label. Agents map to seats: list everyone who replied in the last 90 days, then decide who needs a full seat.
Rebuild macros, triggers and automations
Zendesk’s Macros API says macros “are applied to tickets manually by agents”, and that a macro “consists of one or more actions that modify the values of a ticket’s fields.” A macro is a bundle of field changes and text, not a rule. Port each one as a reply template with its field changes written beside it.
The API’s preview function “returns the changes the macro would make to a ticket” without changing it. It works only on Zendesk macros, so record the expected output there: run each macro’s preview on 20 sampled tickets and write down the changes. Then run your new version on copies of the same tickets and compare field by field.
Triggers and automations break differently, so rebuild them separately:
- Triggers run on events. Zendesk’s triggers article says ticket triggers run “any time a ticket is created or updated”, immediately after the event. The article describes no hourly run and no 1,000-ticket cap. Its limits are a maximum of 7000 active ticket triggers, and a trigger must be smaller than 65 KB. Triggers run in the order listed on the Triggers page, and one trigger’s actions can change whether a later one fires, so rebuild them in that order. Triggers don’t run on closed tickets, and they don’t fire when the system auto-closes a ticket after 28 days.
- Automations run on a clock. Zendesk’s automations article says they “run once every hour on all non-closed tickets”, and that each automation “can act on a maximum of 1,000 tickets each hour”. The overflow waits for the next hour. Tickets that are not closed but have had more than 100 automation audits during their life are excluded from the hourly run.
The failure mode is the “Hours since” condition. Zendesk’s article says that with an “is” condition the automation “cannot fire again on those extra tickets. They will be missed completely.” With “greater than”, the extra tickets “can be handled in the next hour’s run”. Worked example: a rule “Hours since last public reply is greater than 24, notify the owner” keeps picking up overflow each hour. Written as “is 24”, it silently drops any ticket beyond the 1,000 cap in the hour it crosses 24.
Test each rebuilt rule on 20 tickets copied from the export, and write down what it would have done. Don’t turn a rule on until the written result matches.
Cut over without answering a message twice
A shared channel should have one owner at any moment. If Zendesk and the new tool both receive the same channel or support address, each customer message lands in two queues and two people reply.
The sequence:
- Take the full export and note the time. Record the time as T. The full export is a snapshot, and the one-minute rule below applies to the delta request, not to this step.
- Run the delta from T. Zendesk’s incremental export reference says start_time “must be more than one minute in the past”, and that the ticket export “will not return data for the most recent minute”. Wait until T is more than a minute old, then request incremental exports from T and keep fetching until end_of_stream is true.
- Switch in one short window. In each shared channel, run “/remove @Zendesk”. Zendesk’s Slack integration docs say that once the app is removed, Zendesk “can no longer post notifications, provide side conversations, or support Answer Bot in that channel”. Point the support address forwarding at the new inbox in the same window, and write the time down.
- Run a final delta and count stragglers. Run one more incremental pass, then count tickets created in Zendesk after the switch time, grouped by source. A count above zero is a lead, not proof. Tickets also come from API integrations, web forms and other connectors, so open each one and check its source before you blame a stale connection.
Throughput: Zendesk’s rate limits page says Incremental Exports allow 10 requests per minute on the standard limit, and the High Volume API add-on raises that to 30. The default page size is 1,000 records. Worked example: 150,000 tickets changed during the delta window means 150 requests. At 10 per minute that takes 15 minutes; at 30 per minute, five. Honor the Retry-After header on any 429 response.
Customer message for the channel, to adapt:
“Starting [date], replies in this channel will come from [name] on our new support system. Nothing changes on your side, so keep posting here as you do now. Requests you sent before [date] stay with the person who picked them up until they are closed.”
Check what will not come across
- Closed-ticket history after archiving. Zendesk archives tickets “120 days after the ticket status changes to Closed”. Archived tickets stay “accessible and actionable” through direct links, search, user profiles, the API and incremental export, but views and rules don’t work with them. Export them while the subscription still runs.
- Early archiving and exceptions. Zendesk “may automatically archive tickets sooner than 120 days”. Tickets with more than 10,000 events, or whose associated records exceed 2MB, are “not automatically archived”, which leaves manual archiving open. Ask Zendesk in writing whether those can be archived or exported by hand before you cancel.
- Timelines need JSON. CSV has no comments, so before you trust an export, find one known closed ticket and confirm its comments appear.
- SLA history. Zendesk’s pages used for this guide don’t say whether SLA attainment or breach history exports with ticket data. Plan for SLA numbers to start on cutover day, and label earlier numbers as Zendesk-only in reports.
- Shared Slack files. Disconnecting from a Slack Connect organization affects “all channels they’re a part of”, “can’t be undone”, archives DMs for all participants, and makes “Files shared in channels and DMs by people from other organizations” no longer accessible. By default only Workspace Owners and Admins can disconnect. If the goal is to end one channel, remove the other organization from that channel instead.
Transfer ownership, cancel, and keep a rollback
Only the current account owner can change ownership. In Admin Center, go to Account, then Billing, then Contacts. Find the billing admin, open the options menu next to their name, choose “Make account owner”, and confirm with “Change owner”. The new owner needs “a verified email address” and must be a billing admin. The article says “You can’t change ownership to a non-billing admin.”
Plan for the side effects. The former owner “loses access to all subscription-related pages such as Invoices and Payment”, and “integrations that were set up by the previous account owner may break.” List every integration the owner set up, and have the new owner reauthorize each one before the old owner leaves.
The order is transfer, then export, then cancel. If the owner is leaving the company, transfer while they can still sign in, then run the export under the new owner’s login. Zendesk’s pages don’t describe an owner who can no longer sign in, so ask Zendesk support in writing before you rely on any path.
Cancellation has three constraints from Zendesk’s cancellation article. “You must be the account owner to cancel the account.” Notice must be given “at least 30 days prior to the end of your subscription term”. After a mid-cycle cancellation, “you can continue to use the account until your billing cycle ends.” Once cancelled, “you can no longer sign in”, and “your account data will be deleted in accordance with the Service Data Deletion Policy.” The article links that policy without giving a timeframe, so get the deletion date in writing. Treat your final export as the only copy you control.
Rollback needs the notice date worked out first. Decide how long you need Zendesk reachable after cutover, then send notice early enough that the end of the billing cycle falls after that date. If you need to roll back, reverse the forwarding change, then add the Zendesk app back to each channel. Don’t reinstall the workspace integration. Zendesk’s setup article warns that reconnecting “would cause you to lose all other configurations for the integration.”
Reconcile counts before you move forwarding
Count tickets per year in the export, then count tickets per year in the new system. Decision rule: if the counts differ and you can’t explain every gap, don’t move the forwarding address yet. Expected gaps are archived tickets you haven’t exported, deleted tickets missing from CSV, and any tickets the export couldn’t attach files to. Anything else is a reason to stop.