Skip to main content

​
Migrate from Zendesk to Orbit

Zendesk is the third CRM-context provider Orbit connects — alongside HubSpot and Salesforce — but the migration shape is different: Zendesk is a helpdesk, so the move is about tickets, end-users, and knowledge, not a contact book. Pick the row that matches what you need: The connector is identical either way. What changes is whether the Zendesk instance is still ticking the archive clock or shut down. The sections below are ordered for a retirement; sections 1–3 apply to side-by-side too.

​
1. What’s exported from Zendesk — before you change anything

Export from Zendesk while the instance still has full data:
  • End-users — a CSV of Users (name, email, phone, tags). These map to Orbit contacts on import.
  • Groups and agents — the group structure informs queue setup in Orbit. A Zendesk Group maps to a queue, an agent maps to an inbox assignment rule.
  • Tickets — while closed tickets can bulk-export on Premium plans, most migrations archive them rather than import them. Live tickets are rebuilt natively (see step 3).
  • Help Center (Knowledge) — articles, categories, and sections. These move to Orbit’s knowledge base as connected content rather than an export — a Zendesk connector imports the Help Center tree into a KB you can search and publish.
  • Macros — Zendesk macros map to Orbit macros in the inbox. Export the JSON of your macros; each becomes a reusable snippet or an agent-flow pattern.
Keep the exported CSVs — the audit spine if a row doesn’t reconcile after the relink.

​
2. Connect Zendesk to Orbit (OAuth, admin-only)

The connection is one of the four OAuth-popup integrations, same connect flow as Calendly, DocuSign, or Jira. Owner/admin role required.
The drawer’s Data tab then controls which entities sync — enable the tickets and users models. End-users import onto Orbit contacts; tickets surface in the inbox CRM panel. Verify the connection landed:
For a retirement migration you can connect and immediately import end-users as contacts, then manage tickets natively (no Zendesk ticket sync needed). For a side-by-side setup the ticket linkage is the point — Orbit inbound conversations map into your Zendesk default group.

​
3. Recreate your knowledge base in Orbit

A Zendesk helpdesk usually pairs tickets with a public Help Center. Orbit’s knowledge base connects to Zendesk directly, imports the category → section → article tree, and keeps the import indexed as searchable content. On the agent-assisted side the imported KB is what the assistant and Orby, the operator assistant cite from. Choose the import shape: If you retire Zendesk entirely, the knowledge import completes once and the connector can be removed — the documents stay in Orbit.

​
4. Recreate your ticket workflow natively in Orbit

Zendesk tickets map to Orbit inbox tickets with first-class parity — type ∈ question|incident|problem|task, priority, tags, SLA timers, macros. The move is: The move is gradual — Zendesk can stay live as the archive while new tickets open natively in Orbit. The seven-step cutover runbook applies unchanged; the only Zendesk-specific detail is which sync model step 3 (end-users) and which archive finalization step 6 close out.

​
5. Reconcile, then cut over

The generic seven-step cutover in Migration playbook hub works as-is; these are the Zendesk-specific checkpoints to hang off it:
  1. Freeze new tickets in Zendesk — inbound conversations stop opening Zendesk tickets. Closed tickets can stay as read-only history.
  2. Redirect ticket/webhook flow — verify POST /api/v1/integrations/webhooks/zendesk if you wired one; otherwise verify an Orbit event against your receiver with X-Orbit-Signature.
  3. Swap API keys — cut your own integration (if any) onto an Orbit key; the OAuth connection to Zendesk itself stays until decommission.
  4. Flip sender identity — the production sender moves to Orbit’s numbers; the Help Center public URL moves to Orbit’s public docs endpoint.
  5. Watch the first-day parity window — ticket creation rate, SLA adherence, and knowledge search coverage parity before decommission.
  6. Hold Zendesk readable — keep the Zendesk instance accessible (ideally with sync running) for an agreed window so agents can search closed tickets if a customer calls back on an old thread.
  7. Decommission — verify no live triggers/automations, no live tokens, and that the exported end-user CSV reconciles with what Orbit reports imported. Then close the instance.

​
6. Operate after the migration

Once cut over, the ongoing surfaces that keep the migration honest:
  • Settings → Migrations — the job history for every import run lives here, with status and rollback. Monitor, cancel, and roll back platform migrations.
  • Audit ledger — every connect, sync, and knowledge import lands in the tenant audit log.
  • Suppression and consent state — Zendesk organization/user-level opt-outs must exist in Orbit’s per-channel suppression before decommission. Opt-out lists covers enforcement.
  • Sync health — if you left Zendesk connected as an archive, GET /api/v1/integrations/{id}/status reports per-sync last_sync, and Settings → Integrations → Zendesk → Status surfaces the same.
Retiring Zendesk entirely, or pairing it with Orbit for a season? The solutions team works Zendesk offloads regularly — migrate@devotel.io with your instance shape, lane, and Help Center size gets you the same plan the sections above assume.