Plan requirement
| Subscription | Any plan |
| Access | Admin |
You can: the Ticket Import API exists for exactly this, with a bulk endpoint for historical loads or anything over 1000 tickets. The reason to decide against it is a documented limitation rather than a matter of effort.
What imported tickets cannot do
Metrics and SLAs are not supported on them. Zendesk is explicit that running metrics or SLAs over imported tickets produces incomplete and inaccurate data. So the usual reason for importing, having last year's figures in the new system, is the one thing the import cannot deliver.
Two more behaviours to expect. Triggers do not run on an imported ticket unless its status is closed, though they resume if the ticket is later updated. And no notifications go out to people CC'd on the imported tickets, which is what stops a migration emailing thousands of customers about tickets from two years ago.
Timestamps are preserved: you can set created_at, updated_at and solved_at, and comment timestamps too, so the history does not collapse onto the import date.
What people need
Ask why the history matters and the answer is almost always one of two things, and neither needs a full import.
Looking something up occasionally. Keeping the old system readable, or exporting to a searchable archive, covers this at a fraction of the effort.
Reporting on last year. Take those figures from the old system once and keep them as a document. Given that metrics are not supported on imported tickets, this is not a preference: it is the only way to get numbers you can defend.
If you do import, treat it as a project with its own budget and decide in advance which fields have to survive. Above roughly 750,000 tickets, archive_immediately keeps the load off your live queue.
Comments
0 comments
Article is closed for comments.