Help Desk Migration Checklist: Preserve Context and Control Cutover
Plan a help desk migration with field mapping, sample imports, history validation, mail cutover and a documented rollback boundary.
A help desk migration is ready when the new system preserves the history your team needs and handles new requests correctly. A successful import job is only one checkpoint. Test identities, private notes, attachments, timestamps, routing and notifications before switching customer channels.
Choose the migration scope and map identities
Decide whether to move open tickets, recent closed history or the full archive. Keep an explicit retention and access plan for anything left behind. Inventory customers, organizations, users, statuses, custom fields, tags, attachments, knowledge articles and business rules. Assign an owner to each mapping decision.
| Data | Acceptance check |
|---|---|
| Customer and organization | Correct identity without accidental account merges |
| Comments and notes | Correct order, author and public or private visibility |
| Attachments | Files open with the expected access restrictions |
| Status and ownership | Open work has a valid owner and next action |
| Historical timestamps | Dates remain useful and imported data is labeled |
Use the documented import route. Help Scout documents an Import2-based path for supported ticket and email sources, while knowledge-base transfers have separate options. The presence of a ticket import does not prove that articles, rules or every custom field move with it.
Run a representative sample and reconcile it
Select cases for complexity, including a reopened ticket, a departed agent, an attachment, a private note, a merged conversation and a customer with several identities. Preserve the old identifier in an external reference field or lookup file so agents can trace discrepancies.
Zendesk's Ticket Import API supports historical timestamps and comments, with attachments uploaded through its attachment process. It also warns that Zendesk metrics and SLAs are unsupported for imported tickets and recommends excluding them from reports. Preserved history therefore does not imply preserved performance reporting.
- Reconcile source and destination counts by data type and migration batch.
- Read complete sample threads, including private visibility and attachments.
- Resolve rejected records and duplicates before the next batch.
- Test a subsequent update for notifications, triggers and routing.
- Obtain the support owner's acceptance of the migrated open queue.
Control channel cutover and the rollback boundary
Rebuild forwarding, authenticated senders, widgets, forms, routing rules, macros and integration credentials in the destination. Disable customer-facing notifications during import where supported, then test real new messages with controlled accounts. Check reply threading and sender identity from the customer's view.
Record a final-sync time, channel switch time and owner. Define which system is authoritative after cutover and how late changes in the old one will be collected. Keep the old service accessible under the agreed retention plan until reconciliation is complete. Zendesk's account migration guidance treats workflow objects and reporting as separate migration considerations.
A rollback after agents begin replying in the new system requires preserving those new messages; changing email forwarding back does not merge the histories. Include that decision in the runbook. Use the help desk comparison to select a destination, then require this sample-import evidence before signing off.
Frequently asked questions
Must we move every old ticket?
No. Move what supports operations and required retention, with a searchable access plan for the remaining archive.
Are matching ticket counts enough?
No. Counts can match while notes become public, attachments break or identities merge incorrectly. Combine reconciliation with full-thread inspection.