Zendesk Ticket Migration Sheet template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

This sheet is the staging file for a ticket migration into Zendesk. Unlike users and organizations, Zendesk does not bulk-import tickets from a CSV in the admin UI — historical tickets come in through the Zendesk API or a migration tool, and every one of those routes wants the same core field set. This worksheet puts that field set in one place so you can clean, map, and sign off on the data before anything touches the API.

Use it when you are leaving another help desk (Freshdesk, Intercom, Jira Service Management, a shared inbox) and want ticket history to survive the move. Stage your legacy tickets here, reconcile statuses and requesters, and hand the finished sheet to whoever runs the migration — your team, a migration tool, or ours.

How to use it, step by step

1. Export tickets from the old system. Pull every ticket with its requester email, timestamps, status, and conversation body. Export more fields than you think you need — re-exporting halfway through a migration is how requester mappings drift.
2. Map old statuses to Zendesk statuses. Zendesk uses new, open, pending, on-hold, and solved. Decide the mapping once, write it down, and apply it in the status column — the most common migration mess is five legacy statuses collapsing into “open”.
3. Reconcile requesters first. Every requester_email here should exist in Zendesk before tickets load (use our Zendesk Bulk User Import template for that). Tickets that arrive before their requester create stub users with no name, org, or tags.
4. Tag the batch. Keep a migration tag (like migrated_2026) on every row. It makes the imported cohort filterable in views and Explore, and makes a rollback possible if something maps wrong.
5. Preserve timestamps. created_at and solved_at keep reporting honest — without them, five years of history lands as one giant week. ISO 8601 format, UTC.
6. Load a 20-ticket pilot. Run a small batch through your API script or migration tool, check how statuses, requesters, and timestamps landed, then run the rest.

What each column means

Common mistakes to avoid

• Loading tickets before requesters exist — Zendesk creates nameless stub users and your org/CSAT history never connects.
• Collapsing legacy statuses into “open” — thousands of old tickets flood agent views on day one. Solved history should arrive solved.
• Dropping timestamps, which makes every migrated ticket look like it was created the day of the migration and wrecks trend reporting.
• Skipping the migration tag, leaving no way to isolate (or undo) the imported cohort.
• Migrating everything — most teams only need 12–24 months of history live; archive the rest as an export.

Questions, answered

Can I import tickets into Zendesk from a CSV directly?

Not through the admin UI — Zendesk’s native CSV imports cover users and organizations only. Ticket history comes in through the Zendesk API (ticket import endpoint) or a migration tool. This sheet is the staging format for either route, with columns that mirror the API’s ticket fields as of October 2026.

Will migrated tickets send notifications to customers?

Done properly, no — the API’s ticket import path is designed to suppress notifications and triggers. This is exactly the kind of detail a 20-ticket pilot batch confirms before the full run.

How much history should we migrate?

Our default advice: migrate 12–24 months as live tickets and keep an archive export of the rest. Old tickets mostly serve reporting, and a smaller migration is faster, cheaper, and easier to verify.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.