Quick answer: Migrating off a per-seat enterprise contact-center suite onto Orbit is a phased project, not a forklift: audit what you actually run, bring your carrier and numbers across, rebuild the queues and call flows on Orbit's cloud phone pillar, then cut over channel by channel with the old suite still live behind you. The work lists below are ordered so every phase produces evidence before the next one earns traffic — the same discipline that governs the narrower IVR-to-AI-agent migration, applied here to the whole platform.
This guide is for operations and platform teams on Genesys Cloud CX, Talkdesk, Five9, or NICE CXone who have decided the per-seat licence no longer matches how they work. The head-to-head comparisons — Orbit vs Genesys, Orbit vs Talkdesk, Orbit vs Five9, and Orbit vs NICE CXone — assert what changed; this tutorial is the next step: how to actually move.
Decide whether the migration is worth it
The commercial-model rows on those comparison pages are the categorical divide, and they decide whether a migration even belongs on your roadmap:
- Per-seat enterprise licence vs pay-as-you-go usage billing. Enterprise suites invoice per agent per month on annual contracts, whether those agents answer calls or not. Orbit bills usage — the contact center, the channels, and the AI agents all draw on one pay-as-you-go wallet with published rates, so a seasonal team stops paying for empty seats. The comparisons assert the incumbent side of that divide ("no" on pay-as-you-go usage billing for Genesys, Talkdesk, Five9, and NICE CXone).
- Sales cycle vs self-serve signup. The incumbent suites route every plan change through a sales process. On Orbit you open the account, top up the wallet, and build the migration sandbox the same afternoon — published pricing on the website, no sales call.
- Suite channel ceiling vs one platform. A CCaaS suite carries the channels inside the contact center; the programmable SMS/MMS API below it and the email and video surfaces beside it are bought elsewhere. On Orbit the contact center ships alongside the programmable voice, SMS, WhatsApp, RCS, email, embeddable video, and AI voice agent surfaces on one account — noted as gaps or partials on the comparison matrices.
Migrating is worth it when those three rows describe your procurement pain. If your contract runs two more years, use the time to run the pre-migration audit below — a clean inventory is the asset that makes the eventual move cheap.
Pre-migration audit: inventory what you actually run
The phase before touching any call flow is an honest map of the incumbent deployment — not what it was sold as, but what callers, queues, and reports actually do today. Weeks running a good audit; months unearthing surprises mid-cutover.
Queues and routing mappings. Export the full ACD queue list from the incumbent: queue name, skills or routing expressions, SLA targets, ring strategy, overflow and fallback destinations, and in-queue callback offers. In Orbit these map to ACD queues with skills-based routing rules, SLA targets, overflow destinations, and saved-position virtual-hold callbacks — one queue on the audit sheet becomes one queue to rebuild, so a queue nobody answers shows up in the audit rather than halfway through the rebuild.
IVR flows, prompts, and DTMF menus. Export every call flow: the menu tree, prompts and recordings, business-hours routing, holiday schedules, and each node's destination. Then map every menu node to an outcome — a queue, an announcement, a voicemail, a hang-up. That map is the routing contract the rebuilt IVR must reproduce first. Where the answer is "this branch exists to deflect simple intents," note it as an AI-agent candidate for Phase 3 rather than a menu node to clone.
Agent-state and skills configuration. Pull the agent roster with skills assignments, the state list (available/busy/wrap-up and any custom states), and the utilization or concurrency rules. Orbit's agent-state routing reproduces the same presence model — map it in the audit so the cutover does not strand agents mid-interaction in a state that has no equivalent.
Analytics, recordings, and retention. Export the report definitions you actually run on — queue performance, handle time, containment — plus the raw exports and call recordings your retention and compliance policies require. Historical reporting data does not migrate; take it out while the incumbent still lets you, and note any legal-retention obligation on the audit sheet before the export window closes.
Numbers, trunks, and SIP endpoints. List every number and trunk: local, toll-free, and per-country numbers with the regulatory registrations each one carries, the SIP trunks and their carriers, and the session-border or carrier interconnects. This inventory feeds the porting ladder in Phase 2 — capture the registrations now, because they transfer with the number and gate the port timeline.
Compliance posture. Record what the current setup enforces for regulated traffic — consent capture, recording disclosures, retention windows. On Orbit these controls are tenant-configurable: your organization sets its own quiet-hours, consent, and retention policy rather than inheriting a platform-wide policy, so the audit sheet must name the policy you intend to enforce, not the one the incumbent defaulted to.
Port the trunk and numbers in a ladder
The safest order is connectivity first, numbers last:
- Stand up SIP trunking first. If you keep your current carrier, connect its SIP trunk to Orbit with bring-your-own-carrier — the programmable voice layer accepts the existing trunk, and your numbers keep working on the incumbent while you rebuild. If you want Orbit to terminate the calls, the same ladder works: calls route on Devotel's own wholesale softswitch across its carrier network once the trunks land.
- Port the numbers last, in waves. Port a non-critical queue's numbers first — a regional line or an after-hours number — validate the full call path on Orbit, then port the customer-facing queues in batches. Number porting is a regulated, days-to-weeks process per country, and the regulatory registrations travel with each number; stage the port windows so no two customer-facing queues move at once.
- Rebuild the visual IVR on the ported numbers. Recreate each audited menu flow in Orbit's visual IVR builder — the cloud-phone pillar ships the builder alongside SIP trunking and ACD queues on one surface, so the menu tree, the trunk, and the queue live in one place. Reproduce the audited routing contract node for node before you change a single caller experience: same prompts, same business hours, same destinations.
- Rebuild ACD queues and agent-state routing. Recreate each audited queue with its skills filters, SLA targets, overflow destinations, and in-queue callback; then the agent roster with its skills and the state model. Run the rebuilt queues on shadow traffic — a ported non-critical number — before any production queue points at them.
Done in this order, every element gets exercised on real but low-stakes traffic before the customer-facing volume moves. If a wave fails validation, the unported numbers still terminate on the incumbent and nothing visibly changed for callers.
Cut over the AI agents
This phase is where the incumbent suites differ most from Orbit, and the comparison matrices pin the difference: Genesys, Talkdesk, Five9, and NICE CXone all ship enterprise agentic AI ("yes" on native AI voice agents), but Orbit ships a native AI-agent runtime with a built-in tool catalog — agents call the platform's tools directly instead of a developer hand-wiring an integration, a row the incumbents land at "no" on. An incumbent add-on assistant is a separately licensed layer beside your call flow; an Orbit AI voice agent is in the core platform, on the same call path and queue as your menus and human agents.
Run the cut-over as a second migration inside the first:
- Shadow the agent behind the rebuilt IVR. Keep the rebuilt menu live and add the AI voice agent as a new front option — the phased pattern from the IVR-to-AI-agent migration guide applies verbatim. The agent shadows on real traffic while the menu keeps its containment baseline.
- Move top intents first. When the shadow data shows the agent resolves the top audited intents at least as well as the menu path, promote it for those intents. Rank by what callers actually say (the transcript catalog from the IVR audit), not by the menu designer's tree.
- Rewire the escalation contract warm. The agent hands off into the same ACD queues your human agents already work in, with a call summary and the verified intent attached — your specialists start with context, and the fallback contract (which queue, which skills, what context) is pinned before the agent goes live.
- Retire the incumbent's AI add-on only after parity each gate. An incumbent's pilot licence or agentic add-on is a line item you cancel at the end, not a system you depend on during the cut-over.
Validate the cutover and keep a rollback path
Grade the migration on evidence, per wave:
- Containment parity. Contained-call share per intent, Orbit vs incumbent, on the same traffic class — the number the migration must beat.
- Queue metrics on the new path. Answer time, SLA attainment, and callback behaviour on the rebuilt queues, against the incumbent's last full week.
- Handoff context. Agents receive a call summary and verified intent, not a bare transfer — spot-check escalations in the first week of each wave.
- Channel parity after contact. The contact center agent experience reproduces the states, skills, and wrap-ups your floor actually uses; confirm agent-state transitions and queue reporting line up before decommission.
Rollback stays live the whole time: keep the incumbent suite idle-but-alive until the last ported number validates — because trunks came across first and numbers moved in waves, rolling a wave back means repointing the affected SIP route or delaying the next port batch, not rebuilding anything.
HIPAA and BAA posture (healthcare). Treat the agreement as its own workstream, not an assumed entitlement: a Business Associate Agreement is available on request for qualifying healthcare customers and proceeds as a case-by-case review through Orbit's compliance status — never an automatic grant. One reviewed agreement can cover the LLM, speech-to-text, text-to-speech, and telephony legs because Orbit runs those legs itself; in the incumbent's add-on model the corresponding subprocessors are yours to vet and contract separately. Document your tenant-side controls — PHI handling, recording consent, retention — as part of the audit, and sequence the agreement before healthcare traffic moves.
Frequently asked questions
Do we have to rip out the enterprise suite to start the migration?
No. SIP trunking stands up alongside the incumbent deployment, the rebuilt queues run on shadow traffic through a ported non-critical number, and the AI agent shadows behind the rebuilt menu. The incumbent keeps serving production traffic until each wave validates — the migration is additive until the last port batch.
Can we keep our carrier and numbers during the migration?
Yes. Bring-your-own-carrier SIP keeps the carrier relationship while Orbit layers the new call flow on top; the numbers themselves port to Orbit in waves once the rebuilt queues validate. If you later move termination onto Orbit, calls route on Devotel's wholesale softswitch — the same carrier-of-record path the voice product already uses.
How does per-seat licensing change scope of the migration?
It changes the sequencing, not the destination. Per-seat annual contracts typically mean the incumbent fees continue during the migration window, which is an argument for running the audit early and cutting waves as they validate — every wave that clears containment parity shrinks the per-seat bill you still owe.
What happens to our historical analytics and recordings?
They stay with the incumbent. Export the report definitions, raw data, and recordings your retention policy requires during the audit phase, and let Orbit's queue analytics start fresh — containment and queue metrics are graded side by side from the first shadow wave, so you never need the incumbent's history to prove the new path.
Do the enterprise suites' advertised AI agents map one-to-one to Orbit's?
Functionally, yes for the call-handling job — the comparison pages assert native AI agents on both sides. The structural difference is that Orbit's agents run on a native runtime with a built-in tool catalog in the core platform, while the incumbent's agentic products are separately licensed add-ons beside the suite. Migration scope per intent is identical: catalog the intents, shadow, then move top intents first.
Can we run the migration in a HIPAA-regulated environment?
Yes, with the agreement and the tenant controls handled as their own workstream. A Business Associate Agreement is available on request for qualifying healthcare customers and is reviewed case by case through the compliance channel before regulated traffic moves; your organization defines its own PHI, consent, and retention controls on the tenant side. Sequence both before the healthcare queues port.
Where to go next
The audit → ladder → cut-over arc above moves an enterprise contact center onto Orbit without a big-bang. The sibling guides and comparisons fill in the per-suite detail:
- Read the head-to-heads for the commercial contrast: Orbit vs Genesys, Orbit vs Talkdesk, Orbit vs Five9, and Orbit vs NICE CXone.
- Apply the phased intent migration inside the cut-over with Migrate a classic IVR to AI voice agents.
- See the destination surface on the contact center comparison and the contact-center feature overview.
- Check pricing — one pay-as-you-go bill across the queues, the agents, the channels, and the trunk. For the all-in cost model a migration business case is graded on — the four per-minute components and the cost-per-resolved-conversation ROI framework — see AI voice agent pricing in 2026.
Published 25 August 2026.