Migrate from Salesforce, HubSpot Service Hub, or Zendesk to Devotel Orbit: the runbook

Quick answer: Migrating from Salesforce Service Cloud, HubSpot Service Hub, or Zendesk to Devotel Orbit splits into two surfaces, and the split is what makes the move cheap. Orbit is the communications layer — the conversations, campaigns, calls, and flows — so the second messaging layer your CRM charges per seat to carry is the part that moves. The customer record often does not have to: the Salesforce, HubSpot, and Zendesk integrations connect Orbit to your existing CRM as the system of record, so deciding which seats ride both consoles is a license decision, not a migration blocker. This runbook covers the three-way inventory, the import staging with dry-run preview and job-scoped rollback, and the wave-by-wave cutover that keeps the source platform live until the last segment validates.

This post assumes the direction is decided — the head-to-heads for each suite are the Salesforce, HubSpot Service Hub, and Zendesk comparisons, and the CRM and Commerce integrations announcement covers the connect-and-stay path in detail. What follows is the operator sequence: split the inventory, stage the import, cut the conversations over, point the write-back home.

1. Why a CRM migration is only half a migration

Voice and CCaaS runbooks move everything, because the source platform owns the conversations end to end — the generic enterprise CCaaS runbook sequences numbers, queues, and agents as one body. A CRM suite owns something different: the record. Salesforce owns accounts and cases, HubSpot owns contacts and tickets, Zendesk owns end-users and tickets — and each then charges per seat for the agents, inboxes, SLAs, and routing that carry conversations against that record. The buyer query this runbook answers is "how do I self-migrate off my CRM," and the honest first answer is that replacing the messaging layer is the migration; replacing the record is a separate, optional project.

So the audit sheet splits every artifact into two columns before anything moves:

• The record side. Objects, pipelines, and history. Salesforce Accounts, Contacts, Cases, and Activities; HubSpot Contacts, Companies, Deals, Tickets, and timeline engagements; Zendesk End-Users, Tickets, and Comments. The default target is "stays, connected" — the Salesforce, HubSpot, and Zendesk integration pages define exactly which objects each connection syncs, and retention-only exports cover the rest.
• The conversation side. Seats spent talking. Omni-channel queues and Live Agent routing on Salesforce; shared inboxes, ticket pipelines, and SLAs on HubSpot Service Hub; groups, views, business hours, macros, and triggers on Zendesk. This is the layer that moves — onto Orbit's agents, ACD queues, flows, the unified interactions timeline, and programmable channels — and it is the layer the per-seat bill actually prices.

A useful audit question per row: does this artifact earn its seat if the CRM stops being the inbox? Queues, SLAs, macros, and inbound call handling usually do not — they earn a flow or a queue in Orbit instead, and that is the budget line the migration retires.

2. The three-way inventory

One audit sheet, and everything the migration touches lands on it. Score each artifact: move, connect, rebuild, or retire.

Salesforce Service Cloud

• Accounts, Contacts, Leads → connect. The Salesforce integration is bi-directional: records sync into Orbit for agent context, and every message event posts back as an Activity on the record timeline. The Salesforce contact–activity junction post walks the write-back record by record. Bulk contact lists for campaigns are the exception — those become Orbit contacts.
• Cases, Omni-channel queues, Skills-based routing → move. Each Omni queue and skill grouping becomes an Orbit ACD queue with the same filters and overflow destinations; agents answering channels stop carrying a Service Cloud seat for that work.
• Live Agent chat and telephony → move. Web chat rebuilds on the Orbit widget, voice on the Orbit contact center. Every new inbound thread lands in the unified interactions timeline from cutover day.

HubSpot Service Hub

• Contacts, Companies, Deals → connect. The HubSpot integration syncs contacts, deals, and companies on a 15-minute schedule and logs every outbound touch back to the contact timeline as an engagement event. Campaign audiences import as Orbit contacts from the same export.
• Tickets, pipelines, and SLA policy → move. Ticket pipelines map to queues; SLA policy is re-expressed on the queue in Orbit. Pipeline-specific automation that only existed to route conversations becomes flow logic.
• Shared inboxes (chat, email, channel connectors) → move + rebuild. The inbox's channels port onto Orbit channels natively; the conversation-routing rules rebuild in the flow builder — a branch that deflected a simple intent is an AI-agent candidate, not a cloned routing rule.

Zendesk

• End-users → move + connect. End-users import as Orbit contacts with the same dry-run controls as every other import; where Zendesk remains the system of record, the Zendesk integration keeps the escalation write-back to tickets live.
• Groups, views, macros, triggers, business hours → rebuild. These are routing and response logic, not data. Each group becomes an ACD queue; each macro becomes a response template; business hours move onto the Orbit compliance schedule. Triggers that routed conversations become flow nodes — enumerated on the audit sheet, not discovered mid-cutover.
• Tickets and Comments → export for retention. Ticket history stays put; the Zendesk connection imports end-users as contacts and escalates the conversations that still need ticket follow-up. Export archives before the Zendesk subscription goes dark — history does not port.

Size the wave plan from the sheet: a HubSpot Service Hub move is usually inbox count plus pipeline list; a Zendesk move is groups, views, and macro volume; a Salesforce move is Omni queues and skills. One queue, one group, or one pipeline per wave keeps each cutover reversible.

3. The import half: stage contacts and tickets through the wizard

Everything that moves into Orbit as data rides the platform's import machinery — the same controls used in the halted-migration recovery runbook: a durable import job per run, a dry-run preview with per-entity counts, a duplicate policy (skip, overwrite, merge), and rollback scoped to the job. Stage the namespaces in this order:

1. Contacts first. Export the record-side contact list (all three suites produce one) and import through the platform's import pattern. The dry run reports per-kind counts and conflicts before anything writes; the duplicate policy you pick at preview decides every collision. Zendesk end-users, HubSpot contacts, Salesforce contacts — the same controls, whatever the source.
2. Conversation seed where you need it. A migrate-and-connect deployment exports the attachment an agent actually needs — open ticket context, recent case comments — as reference archives rather than live rows. New conversations start clean on Orbit; the unified interactions model projects every channel onto one recency-ordered read from day one, so nothing pre-cutover needs to fake being native.
3. Routing last. Queues, groups-as-queues, SLA postures, and response templates rebuild against shadow traffic before a real segment moves. The cutover is additive: the source console stays live while each wave validates, and a failed wave means a re-run under your duplicate policy or a job-scoped rollback — never a tenant rewind.

4. The connect half: keep the CRM as system of record

The connect half is what makes a CRM migration cheaper than a CCaaS migration, and it is a shipped, documented path — the integrations announcement covers all six marketplace connections.

• Write-back, not mirroring. The junction model is activity sync: Salesforce receives message events as Activities on the record; HubSpot receives them as engagement events on the contact timeline; Zendesk escalates the conversations that need ticket follow-up. The touches land where your team's reports and automation already read, instead of in a custom table only Orbit can see. The Salesforce junction explainer is the model to read before scoping what syncs.
• From the same seat. Agents work in Orbit's inbox and queues; the CRM record stays the source for pipeline and history. The per-seat bill shrinks to the seats that genuinely administer the CRM, because answering messages no longer requires sitting in it.
• Tenant-owned credentials. Every OAuth connection runs through the marketplace connect flow, with provider tokens held in the hosted OAuth service rather than in Orbit application code. The scopes you grant are the scopes the sync uses; revoke at the provider or disconnect the card and the write-back stops — the compliance posture stays yours.

5. Cutover plan

Five waves, reversible until the last one closes:

1. Audit. Fill the inventory sheet from §2; score every artifact move / connect / rebuild / retire. Document consent, quiet-hours, and retention policy here — the tenant sets them in Orbit rather than inheriting CRM defaults, and they belong on the sheet now, not mid-cutover.
2. Connect. Turn on the Salesforce, HubSpot, or Zendesk integration and validate the write-back on a test record before any import. A connection that posts Activities or engagement events correctly is the difference between "migrate-and-connect" and "migrate-and-hope."
3. Import. Contacts through the import wizard: dry-run preview, duplicate policy, confirmed run. A halted job goes through the recovery runbook — retry, roll back, or escalate with the job id.
4. Rebuild and shadow. Flows, queues, macros-as-templates, SLAs-as-queue-policy. Run each rebuilt segment on a non-critical channel first; the source console stays live the whole time.
5. Wave cutover + rollback window. Move conversations inbox by inbox, group by group, or queue by queue. Job-scoped rollback stays available per import run; when the last segment validates, downgrade the source suite to record-only seats.

6. Frequently asked questions

Do I have to leave my CRM to move conversations to Orbit?

No. The default pattern is migrate-and-connect: Salesforce, HubSpot, and Zendesk stay the system of record while Orbit takes the conversations, campaigns, and inbound traffic. Full-replacement of the record is a separate project the import tooling also supports — dry run, duplicate policy, job rollback.

Does my Salesforce or HubSpot history move too?

Record history stays in the CRM, and it stays useful: message events Orbit generates post back to it as Activities (Salesforce) or engagement events (HubSpot). Conversation history in the source console does not port — export what retention needs before the seats go dark, as the Zendesk integration page states for ticket history.

Can the migration run without a maintenance window?

Yes. Imports are additive — previews write nothing, re-runs are idempotent under your duplicate policy, and rollback deletes only what one job created. Routing rebuilds validate on shadow traffic, and the source suite stays live until the last wave closes.

What happens to Zendesk macros, triggers, and business hours?

They rebuild, not migrate-in-place: macros become response templates, routing triggers become flow nodes in the flow builder, business hours become the Orbit compliance schedule. Enumerate them on the audit sheet in §2 so nothing surfaces mid-cutover.

Which runbook covers invoice channels like telephony or inbound email?

The record-side artifacts above, then the channel itself: inbound email rides Orbit's email channel, telephony rides the contact center, and the generic enterprise CCaaS runbook covers the number-side cutover order if your CRM suite was also carrying inbound calls.