Migrate an Avaya PBX estate to Orbit — the runbook

Quick answer: An Avaya PBX estate — Avaya Aura, Communication Manager, IP Office — migrates to Devotel Orbit on the same per-family swap pattern as the enterprise CCaaS runbook, with one on-prem variation: normalize the dial plan first, because an estate where a four-digit extension and a public DID ring the same phone has a routing contract, not a routing table. Sequence it as audit → numbers in staged waves → SIP trunk re-home → WEM/WFM export → peripherals. The Orbit vs Avaya matrix covers the comparison; this is the execution.

The audience is the voice or telecom lead who owns the estate — the person with admin access to Communication Manager or IP Office and a spreadsheet of DIDs — and who has already accepted the comparison verdict: a maintenance-heavy premise platform against published per-minute pricing, self-serve signup, and an AI-first communication platform that keeps your carrier relationship if you want it.

Step 1: the audit converts extensions and DIDs into a routing contract

On-prem Avaya estates encode years of bespoke dial-plan work. Exported tickets from Communication Manager and IP Office describe routing behavior at three layers: stations and extensions, public numbers (DID), and the unlisted ports that keep analog endpoints alive. Export all three before touching a trunk.

• Every station and extension with its class-of-restriction and forwarding chain. A station row maps to one Orbit extension; a station nobody answers — a ghost extension on a departed employee — shows up in the export, not during cutover. COR determines who may dial external, international, and premium destinations, so preserve it as a routing rule on the re-authored side, not as an afterthought.
• Extension-to-DID normalization. Avaya estates routinely map a four-digit extension to a public DID through an ARS route table or a location table, one-to-one, one-to-many, or many-to-one. Write the mapping down row by row: on Orbit, each mapping becomes either a dedicated number on a user or a ring group on a shared queue, and the audit forces the decision per row rather than per guess. This is the same audit-before-change discipline the troubleshooting conventions in the docs enforce for every trunk change: capture the current behavior before altering it, so a regression after cutover is diagnosable against a baseline.
• ARS/LCR route tables, feature access codes, restrictions, and time-of-day routing. The dial plan's real logic lives here: which prefixes route to which trunk, which users cross toll boundaries, which hours reroute the main number. Each entry becomes a business-hours rule, a caller-ID rule, or a routing fallback on the new side.
• PBX-dependent peripherals. Fax machines, door phones, elevator phones, alarm lines, codec walls in conference rooms — every on-prem estate hides analog endpoints behind ATA pairs or FXS ports. Enumerate them now with a replacement route per device: fax over HTTP API, a SIP ATA on a registered extension, or retirement.

Step 2: port the numbers in waves, LOA and bulk CSV

Connectivity crosses before call flows, and DIDs cross in staged batches rather than one event.

1. Screen the whole estate first. A number can refuse to move — an unsupported rate center, a country without a portability regime, a wireless-only cluster. Run the bulk portability check — up to 1000 DIDs per call — before anyone drafts paperwork, so the rejections land in the audit phase rather than the port window.
2. Extract the CSR data the losing carrier will verify. The account number, authorized end-user name, and exact service address must match the carrier's billing record character-for-character; a mismatched address line is a rejection. The combined readiness gate validates the data internally before the request is dispatched.
3. Sign the LOA in-platform, then stage the port in waves. The phone number porting guide is the canonical reference: upload and in-platform LOA signing, submit to open the carrier review clock, FOC timelines, and porting webhooks — including the bulk CSV flow that moves hundreds of DIDs at once. Start each wave with a non-critical number (a regional line or an after-hours main), validate the full call path on Orbit, then port customer-facing queues in batches, so no two queues move at once.
4. Keep the incumbent alive until the last wave. A failed wave validates back against the still-live Avaya estate with no caller-visible change, because trunks crossed before numbers did.

Step 3: re-home the SIP trunks, beside or onto the estate

Bring-your-own-carrier holds the existing carrier relationship while Orbit layers the call flow on top, so the SIP trunk move is independent of the port move. The SIP trunking BYO-carrier guide covers that surface: re-point the trunks' registration or peering at Orbit, keep the old trunks registered for inbound during the wave window, and test the new path on a ported non-critical number before any production queue points at it. If termination consolidates onto Devotel instead, calls route over Devotel's own wholesale softswitch once trunks land; the choice is per-tenant and does not change the cutover order.

Step 4: export WEM and WFM data before access lapses

Avaya's workforce engagement layer — WFO, WFM, Verint in front of it — holds recordings, quality-management scores, and forecast history with retention obligations that outlive the migration window. Export what retention and compliance policy requires while the estate still grants access, and name the legal-retention obligation on the audit sheet before the export window closes. Recreate the queue structures and agent state model on Orbit's contact center as part of Step 3's shadow-traffic phase rather than as a post-cutover scramble; the WEM 2026 state maps where WEM tooling sits on a cloud contact center, so the QM gap is named in the plan rather than discovered during the recording audit.

How to sequence an Avaya-to-Orbit cutover

1. Export the audit. Pull station/extension lists, ARS tables, DID ownership records, and the peripheral inventory from Communication Manager or IP Office before touching a trunk.
2. Normalize extension and DID behavior row by row. Each row of the extension-to-DID mapping becomes a dedicated number on a user or a ring group on a queue — the decision is recorded in the audit, not improvised at cutover.
3. Screen the DID estate for portability. Run the bulk check, extract CSR match data per record, and sign per-record LOAs in-platform.
4. Stand up SIP trunking beside the incumbent. BYO-carrier keeps the current relationship live; test the new path on shadow traffic.
5. Port numbers in waves, LOA to FOC to webhook. Start with a non-critical queue, validate the full call path, then move the customer-facing estate in batches.
6. Export WEM recordings and forecasts before access lapses. Recreate queue structures and agent state on the Orbit ACD during the shadow phase.

Frequently asked questions

Is Orbit a good Avaya alternative?

Yes, as a platform replacement rather than a like-for-like PBX swap. Avaya's estate is premise-managed: hardware lifecycle, per-seat license true-ups, a certified-integrator maintenance chain, and a bolted-on WEM/Verint layer. Orbit is AI-first and self-serve with published usage-based pricing, and the Orbit vs Avaya matrix treats the two as parity on the cloud-contact-center core (queues, IVR, recording, SIP trunking) and divergent on commercial model and AI-first posture. "Good alternative" here means the migration scope is port and re-author, not a capability downgrade.

Can I migrate Avaya PBX extensions to Orbit?

Yes, by re-authoring in the visual IVR builder and queue model rather than importing any proprietary state. Avaya's station and ARS definitions do not export into any other platform; the audit's routing contract does. Each extension-to-DID mapping decides per row whether it becomes a dedicated number on a user or a ring group on a queue; each ARS route becomes a business-hours or caller-ID rule; COR becomes external-dialing restrictions. The rebuilt path validates on shadow traffic — a ported non-critical number — before any caller touches it.

What moves first, and what moves last?

Phone numbers move first, in staged waves, after SIP trunking stands up beside the incumbent. Call flows and queue re-authoring follow once a non-critical number validates on the new path. WEM/WFM recording and forecast exports run in parallel before access lapses, because the estate's retention obligations outlive the migration window. PBX-dependent peripherals — fax, door phones, codec walls — get per-device replacement routes during the same window, and the incumbent retires only after the last wave validates.

Do we have to rip out Avaya to start?

No. Trunks stand up beside the incumbent, rebuilt queues run on shadow traffic, and each wave validates before the next port batch. The Avaya estate keeps serving production traffic until the last wave validates; rollback stays available because trunks crossed first and numbers moved in waves.

Where to go next

• The commercial comparison this runbook executes: Orbit vs Avaya and the best CCaaS platforms 2026 round-up.
• The generic version of the same arc for cloud incumbents: migrate from Genesys and the enterprise CCaaS runbook.
• The per-channel mechanics: phone number porting, the SIP trunking BYO-carrier guide, and the WEM state of the market.
• The destination surfaces: programmable voice, contact center, and pricing for the per-minute bill the migration business case is graded on.

Published 03 September 2026.