Mapping old ticket statuses to a new Zendesk system

Translate each source status by the action it requires, then choose the Zendesk destination status with the same meaning. Zendesk’s standard statuses provide named action anchors: New, Open, Pending, On-hold, Solved and Closed. Check the account configuration, especially whether On-hold or custom statuses are enabled.

Define what each source status means

For every old status, record who acts next, what event advances the case and whether the customer considers it settled. Include custom statuses and rules that change them automatically, and inspect real tickets because a label may no longer reflect the work remaining.

Zendesk’s standard destination statuses are New, Open, Pending, On-hold (if activated), Solved and Closed. When custom statuses are active, these standard statuses become status categories: each groups similar statuses, includes at least one default status and can contain multiple statuses.

Key Facts About Zendesk Ticket Statuses

Record the mapping and exceptions

Map by action when source labels differ: no action taken → New; assigned work awaiting the agent → Open; waiting for requester information → Pending; waiting for someone other than the requester → On-hold, if enabled; an agent-submitted solution → Solved; system-closed work → Closed.

For a source using Zendesk’s standard status names, the direct mappings are New → New, Open → Open, Pending → Pending, On-hold → On-hold (if enabled), Solved → Solved and Closed → Closed. A requester’s new comment on a Pending ticket automatically resets it to Open; On-hold is internal, and the requester sees Open.

Record the old status, its meaning, destination status, owner after import and any exception rule in a worksheet. When custom statuses are active, map to the matching category first, then choose a configured status within it only if it preserves the same next action.

If one source status covers both requester waits and waits for someone else, separate those cases by next actor: map requester waits to Pending and waits for someone else to On-hold, if enabled. If the distinction cannot be represented faithfully, preserve the next action in the destination state and give agents the missing context in another field or an exception record.

Treat Closed as an exception: a Zendesk requester cannot reopen a closed ticket, and tickets cannot be manually set to Closed. The Ticket Import API supports archive_immediately for a ticket created with Closed status; when true, it bypasses the normal lifecycle and sends the ticket directly to the archive.

Retain the original status as labelled source history. Do not mark an unresolved case as Solved or Closed merely to make an import pass; choose an actionable destination state that preserves the next action.

Mapping Old Ticket Statuses to Zendesk Standard Statuses

Test what happens next

Import examples for each source status into a safe test environment, then perform the next expected event, such as an agent reply, requester reply, internal handoff or resolution. For Pending, test that a requester’s new comment resets the ticket to Open; for On-hold, check that the status is internal and the requester sees Open.

Check the resulting status, queue, owner and notification against the intended workflow. Zendesk’s Ticket Import API does not run triggers when a non-closed ticket is imported, but triggers resume on later updates, so test the first update as well.

No notifications are sent to users cc’d on imported tickets; notifications are sent on subsequent updates. Check this behaviour during post-import testing.

Record the mapping version and recheck it if either system’s configuration changes before cutover.

Steps to Map and Test Ticket Statuses During Migration