Quick answer: Migrating off Twilio Flex to Devotel Orbit is a scoped version of the generic enterprise contact-center move, because Flex is scoped differently than the suites it competes with: Flex is the contact center Twilio ships, but on Twilio's catalog it is one product among several — a separate console, with the programmable voice and messaging channels it runs on invoiced separately. On Orbit the contact center is embedded in the platform — agents, queues, flows, and interactions draw on one account, one contact record, and one pay-as-you-go wallet. The move below is the phase shape you already know from the generic enterprise CCaaS runbook, applied to Flex's specific artifacts: agent seats, Studio flows, and the TaskRouter queues behind them.
This post assumes you already decided to move — the Devotel Orbit vs Twilio head-to-head covers the build-or-assemble trade, and the generic enterprise CCaaS runbook covers the seat-licensed suites this post only gestures at. What follows is the operator sequence: what Flex actually is in your bill, what the migration inventory touches, and how the tenant-owned import controls keep every phase reversible.
1. Flex on the Twilio catalog: a separate product, a separate bill
The audit starts with billing reality, because it decides the migration window. On Twilio, the communications product families each invoice independently: Programmable Voice, Messaging, SendGrid for email, Segment for the customer record — and Flex for the contact center. Flex bills per agent seat per month on top of the voice minutes and message segments the agents actually burn, and its console, variables, and plug-in surface live outside the API surface your SMS code uses. Flex is a good product — the point is structural: the contact center is a bolt-on you assemble onto channels, not something the channel platform carries.
On the Orbit side, the reverse posture: the contact center ships inside the communications platform, so there is no second product to buy, connect, or invoice. Agent presence, queues, the unified interactions timeline, and the programmable channels sit behind one API and one wallet. The UCaaS / CCaaS / CPaaS concept page names why this matters to a Flex team: a CCaaS that rides a CPaaS gets the programmable channels natively, where a Flex deployment has to traverse two product surfaces for the same traffic. Frame the migration around that fold — you are not swapping one vendor for another; you are collapsing a two-product assembly into one.
2. Migration scope: what actually moves
Flex's surface area is smaller than a Genesys or a Five9, and the inventory should reflect that. Four buckets carry the migration:
Agent seats → Orbit agents. Export the Flex agent roster from the Twilio Console — agents, skills, activity states, capacity or concurrency rules. On Orbit these map to the agent surface (dashboard → Agents): the roster, skills-based routing filters, and the presence model. The generic enterprise runbook covers queue and state mapping; the Flex-specific part is that Twilio's seat inventory is already a flat list, so the roster audit is an export, not a discovery project.
Studio flows → Orbit flows. Flex inbound logic usually lives in Twilio Studio — the visual canvas that greets a caller, collects digits, calls a function, and routes to a queue. Each Studio widget maps to an Orbit flow node in the flow builder: a menu, a gather, an HTTP call, a queue handoff. Rebuild the flow node for node first — same prompts, same business-hours routing, same destinations — before you change any caller experience. A branch that exists only to deflect a simple intent is an AI-agent candidate for the second phase, not a menu to clone.
TaskRouter queues → ACD queues. Behind Studio, Flex routes work through TaskRouter: queue names, routing expressions, SLA posture, overflow targets. Export the task queues with their matching workers and skill filters, then recreate each one as an Orbit ACD queue with the same filters and overflow destinations. One queue on the audit sheet becomes one queue to rebuild — a queue nobody answers shows up in the audit sheet here rather than halfway through the cutover.
Conversations and call logs → the unified interactions timeline. Flex's task history is Twilio-side and does not port. Export the reference data your retention policy needs (chat transcripts, quality-review exports, audit logs) while the Flex console still lets you. What replaces the Flex task list operationally is Orbit's Interactions surface — a unified, recency-ordered read model that projects conversations and call logs onto one row shape with a channel discriminator and a back-link to the native surface. The interactions unified model is the concept to read before your first shadow queue answers; after the cutover, every new conversation and call lands there natively.
3. The import pattern: same controls as the platform-migration wizard
A Flex migration uses the same machinery every platform migration on Orbit uses — the pattern documented in the halted-migration recovery runbook: a durable import job, a dry-run preview, a duplicate policy, and a rollback scoped to the job. For Flex specifically, stage the namespaces this way:
- Contacts and the customer record. Flex's customer profile lives behind Twilio Segment for many deployments — an acquired, separately billed CDP the Twilio head-to-head covers. The import wizard treats contact-facing data as the tenant's own: dry-run previews every entity kind before a write, and the duplicate policy you set at preview (skip, overwrite, or merge) decides each collision with what already exists in Orbit's native customer platform.
- Numbers and trunks. Keep the SID-level identity separate from the numbering plan — the audit sheet pairs each Twilio number with its regulatory registrations before any port window opens. Port in waves (a regional or after-hours line first, customer-facing queues last), exactly as the enterprise runbook sequences it. On Orbit, outbound voice and SMS termination ride Devotel's own wholesale softswitch — nothing in the migration leaves the platform to find a carrier.
- Flows and queues. Rebuild in the flow builder on shadow traffic — a ported non-critical number — before production queues point at it. The cutover is additive until the last wave validates: the Flex account stays live behind you, and a failed wave means repointing the SIP route or the next port batch, not rebuilding anything.
4. Tenant-owned controls: preview, idempotent import, rollback
These three controls are yours to exercise on every wave, and they are what makes a multi-week migration safe to run without a maintenance window:
- Preview before write. Every import run opens with a dry run — the wizard reads the source account, counts every entity kind it would touch, and reports the conflict count per kind before anything writes. A failed preview changes nothing on either side; re-run it as many times as the upstream account drifts. The counts it returns are the numbers your duplicate policy is about to decide on.
- Idempotent re-runs. Each confirmed run persists as one durable job, so a failure is recoverable, never ambiguous. A halted job's already-written rows are the known collisions the next run's duplicate policy handles — re-run the wizard over the same connector, and the fresh pre-flight shows the fixed scope before a write repeats. The recovery runbook names the three paths off a halted job: retry, roll back, or escalate with the job id.
- Rollback scoped to the job. When the wrong rows came in, rollback deletes precisely what one job created — reversible by job id, never a tenant rewind — within 24 hours of the job reaching a terminal state. Pre-existing contacts, unrelated configuration, and anything the job merely updated stay untouched. One rollback per job; the removed count confirms it landed.
Compliance posture stays tenant-owned as well: your organization sets its own quiet-hours, consent, and retention policy in Orbit rather than inheriting Flex defaults. Document those on the audit sheet during inventory, not during cutover. For HIPAA-shaped traffic (a common Flex profile in healthcare), treat a Business Associate Agreement as its own workstream — available on request for qualifying healthcare customers, reviewed case by case — and sequence it before the healthcare queues port, per the compliance status posture.
5. Frequently asked questions
Is Flex really a separate bill from my Twilio voice and SMS usage?
Yes. Flex bills per agent seat per month, while the Programmable Voice minutes and Messaging segments it runs on invoice separately. On Orbit the contact center is embedded in the one platform, so the seats, the channels, and the customer record draw on one pay-as-you-go wallet.
Do my Twilio Studio flows port automatically?
No — Studio widgets are Twilio-side canvas nodes, so each flow is rebuilt in the Orbit flow builder. The rebuild is node for node: menu prompts, business-hours routing, queue destinations, and HTTP steps all have an equivalent in the flow builder documented under flows/builder. Where a branch was deflecting a simple intent, treat it as an AI-agent candidate instead of a cloned menu node.
What happens to my Flex chat history and task logs?
Twilio-side history does not port — export what your retention policy needs before the Flex account goes dark. From cutover day forward, every conversation and call lands in Orbit's unified Interactions timeline, per the interactions unified model.
Can the migration run without a maintenance window?
Yes. The import is additive: dry-run previews write nothing, re-runs are idempotent under your duplicate policy, and rollback is scoped to the job id. Flex stays live behind you until the last ported wave validates.
Which runbook applies if my Flex rollout was customized with plug-ins?
Plug-in-era UI customizations have no automatic equivalent — the audit sheet turns each plug-in into a scoped decision: native Orbit surface, or a flow-builder reimplementation? Start from the generic enterprise CCaaS runbook for the platform-wide order of operations, and use this post for the Flex-specific inventory.