Preserving unresolved cases during a platform switch

An unresolved case needs a clear owner, the latest customer context and a next action in the new platform. Establish these before changing where replies arrive.

Register the work still in progress

Snapshot every case that is not genuinely finished. Include those awaiting an agent, customer, supplier or internal specialist, plus recently solved cases that may receive a follow-up. Record the old ID, customer, owner, latest public message, relevant internal note, next action, promised date and reply channel. Flag cases needing urgent handling.

Do not rely on source status alone. A label such as Pending may represent different waiting parties in different workflows. Have the receiving team identify a destination owner for every active case. If an old owner or queue no longer exists, assign a fallback before import.

Choose where new activity belongs

Set a cutover time and specify the reply route. If the old address or channel remains active, decide how it will be monitored or forwarded. Capture messages arriving after the last export and attach them to the correct case. Give agents a way to recognise duplicate replies across both routes.

Preserve public replies and internal notes with their intended visibility. Zendesk’s Ticket Import API accepts historical comments. For non-closed tickets, triggers do not run on import but resume on later updates.

Its documentation also says users copied on imported tickets receive no notification at import and can receive notifications on subsequent updates. If Zendesk is the destination, check the first update and its configured notifications as carefully as the imported record.

Rehearse the next action

Choose cases with different next steps and have their assigned agents continue them in a test setting. Can they find the last promise and relevant files, send from the intended address and see the correct owner and status afterwards? Does a customer reply reach the same case? Confirm that internal notes remain hidden from customers.

Zendesk says a closed ticket is closed by the system and the requester can no longer reopen it; tickets also cannot be manually set to Closed. If a source case still needs action, use an actionable destination state or a clearly linked new case rather than relying on its old label.

Reconcile after the switch

During the initial operating period, compare the active-case register with the destination queue. Investigate missing and unassigned cases, replies still arriving in the old system and status changes without the expected action. Keep the old ID available for tracing. Close each exception when the receiving team can identify the next responder and the customer has a working reply path.

Key Metrics for Post-Switch Reconciliation