Quick answer: A MessageBird-to-Orbit migration follows the same per-family swap pattern the Twilio deprecation runbook and the Plivo migration runbook set down: inventory first, then numbers → messaging lanes → voice → verify in that order, because each family carries a different registration gate. On Devotel Orbit the mapping is still short — Bird's SMS traffic maps to sms-api, its programmable calling maps to programmable-voice, its WhatsApp scope maps to whatsapp-business-api, and its email scope maps to email-api. Verify is a side lane: Bird does not publish a public Verify product, so OTP traffic lands on Orbit's verify-api and comes off the SMS lane rather than re-mapping one-lane-for-one. The Orbit vs Bird and legacy-name Orbit vs MessageBird comparison pages carry the evaluation; this post is the execution. When we say "Bird" below, we mean the omnichannel platform formerly known as MessageBird under either name.
Who should read this
This runbook is for Bird (formerly MessageBird) senders hitting one of three frictions, and each is a buyer experience, not a denigration of the incumbent.
Suite drift behind the same wallet. Bird leans into marketing automation and CRM around its omnichannel core. Teams whose center of gravity is developer-first programmable communications — and who want the contact center and customer data inside the account rather than a marketing object — find the fit loosens as the surrounding suite grows.
Per-family registration gates on one audit. 10DLC in the US, alphanumeric sender IDs elsewhere, WABA templates, and email domain authentication each gate a different family, and on a suite they sit under one billing umbrella with one audit obligation. On Orbit sender-level configuration is tenant-owned across every channel on the same account, so one audit sheet closes the move.
The rebrand re-check. MessageBird rebranded as Bird in 2024, and teams that onboarded under the original name periodically re-check the market. If that re-check ends in a move decision, this runbook is the ordered execution of it.
What Orbit ships that overlaps
Bird genuinely spans SMS, voice, WhatsApp, and email on one platform — the mapping here is to shipped Orbit surfaces, cited so the move is checkable, not aspirational:
- Programmable SMS → [sms-api](/sms-api). Sender registrations, campaign metadata, and delivery-report webhook consumers move onto the SMS API surface.
- Programmable calling → [programmable-voice](/programmable-voice). Call flows, trunk routing, and recording move onto the programmable voice surface. Outbound calls terminate on Devotel's own wholesale softswitch, so once the trunks land the routing contract is platform-owned rather than reseller-mediated.
- WhatsApp → [whatsapp-business-api](/whatsapp-business-api). WABA registration, template approval, and unified inbox routing move onto the WhatsApp surface on the same account as the SMS lane.
- Email → [email-api](/email-api). Transactional and campaign email move onto the email API surface on the same bill as the messaging lanes.
- Verify (the side lane) → [verify-api](/verify-api). Bird does not publish a public Verify product, so OTP endpoints on the Bird account move onto Orbit's verify surface — templates, throttling, fallback channel order, and the idempotency contract that keeps a retry from re-sending a code.
- The /compare mapping, in one place. The Orbit vs Bird and Orbit vs MessageBird head-to-heads carry the same channels-by-rows mapping, and the top SMS APIs 2026 cross-route round-up is linked from those pages for the alternatives ranking.
Side-by-side capability matrix
Work the table down — SMS moves first because it carries the lightest verification cycle, the other messaging lanes move beside it because each carries its own registration gate on the same audit, voice moves mid-sequence as the heaviest infrastructure change, and verify moves last because it carries the hard idempotency constraint.
| Bird family | Orbit surface | What moves |
|---|---|---|
| Programmable SMS | sms-api | Sender registrations (10DLC / alphanumeric sender ID), campaign metadata, delivery-report webhook consumer |
| whatsapp-business-api | WABA registration, template approval, unified inbox routing | |
| email-api | Domain authentication, templates, suppression-safe sends | |
| Programmable voice | programmable-voice | Number ownership, SIP trunk routing, call-flow logic, recording |
| OTP on the SMS lane (no public Verify product) | verify-api | Verify templates, throttling, fallback channel order, idempotency contract |
The migration walk, in order
1. Numbers first, in staged waves
Connectivity crosses before anything else. Port the numbers in waves: a non-critical or after-hours line first, then the customer-facing lines in batches once the first wave validates. The phone number porting guide is the canonical mechanics reference — the bulk portability check, the readiness gate, in-platform LOA signing, port timelines, and porting webhooks — and the docs' number porting and country capabilities pages carry the per-number operational detail. If you keep a bring-your-own-carrier leg, the SIP trunking BYO-carrier guide covers standing up the trunk beside the existing carrier relationship while the new call flow layers on top.
2. Messaging lanes: senders re-register, the delivery-report consumer stands up first
A migration fails on the far side, not the send side. Stand up the Orbit account's delivery-report webhook consumer before any sender identity moves, and cut sender traffic only after the consumer accepts staging deliveries clean. Sender-level configuration is tenant-owned, so the 10DLC or sender-ID registration you audited travels with the move. The SMS channel docs carry the webhook event shape. For the WhatsApp lane, WABA registration and template approval re-run per provider — plan the template queue before the first cut. For email, re-authenticate the sending domain and warm the lane on a staging share before the full list moves.
3. Voice: re-author the call flow against the ported number
With a validated ported number in hand, recreate the call-flow logic — IVR menus, routing destinations, recording — on the programmable-voice surface and run it on shadow traffic before any production call path points at it. Bird flow definitions are proprietary, so a flow does not import; its routing contract does. The voice channel docs carry the call-flow and SIP trunk surfaces this step re-authors against.
4. Verify last, because Bird OTP traffic is the side lane
Because Bird never published a Verify product, OTP endpoints on a Bird account usually live on the SMS lane. That is also why the constraint is the same one the generic sequence gives it: move verify templates, throttling, and fallback channel order onto verify-api after the messaging and voice paths above validate, with idempotency on retries as the sequencing rule, and keep the Bird OTP path live until the Orbit verify surface accepts the full production retry window. The verify docs carry the template and approval surface this step lands on.
This is the same arc the Twilio migration runbook lays out per product family and the Plivo migration runbook applies to a two-family incumbent: connectivity first, per-family registration gates in coverage order, and OTP traffic last because its retry window is the unforgiving one.
Pricing posture
Both platforms publish their rates, so the comparison stays computable — the question is how the per-channel bill composes. Bird's channels bill inside a suite that layers per-product charges; Orbit's rates are published, usage-based on one pay-as-you-go bill across sms-api, programmable-voice, whatsapp-business-api, email-api, and verify-api. No invented numbers here — the business case is graded against the pricing page as published, and the migration spreadsheet uses those numbers or none.
Checklist and docs deep links
The ordered execution checklist, each row closing on a docs surface rather than a guess:
- Audit the Bird inventory. Every sender identity, live number, call-flow definition, WhatsApp template, email domain, and OTP endpoint exported to one sheet — this is the registration gate each wave re-checks before it moves.
- Port numbers in waves — non-critical first, customer-facing in batches — against the porting mechanics and country capabilities pages.
- Stand up the delivery-report webhook consumer before the first sender moves, per the SMS channel docs.
- Re-author call flows on shadow traffic via the voice channel docs — the routing contract imports, the proprietary flow definition does not.
- Move OTP traffic onto verify last with the idempotency gate from the verify docs and the idempotency explainer as the sequencing rule.
- Close the Bird account only after the last retry window passes — rollback stays available through step 5 because numbers moved in waves and the old senders stay live until each wave validates.
Frequently asked questions
Is Orbit a good MessageBird (Bird) alternative?
The Orbit vs Bird matrix treats the two platforms as parity on the SMS, voice, WhatsApp, RCS, email, and Meta social-DM core and divergent on what surrounds it: Bird concentrates the omnichannel suite around marketing and CRM; Orbit keeps the transparent, pay-as-you-go shape and adds native AI voice agents, the Telegram/LINE/Viber chat apps, Apple Messages for Business, embeddable video, and a built-in human-and-AI contact center on one bill. The head-to-head Orbit vs MessageBird and rebrand decode post carry that answer under both names.
Can I keep one account across SMS, WhatsApp, and email after the move?
Yes — that is the one thing Bird publishes parity on, so the move does not trade omnichannel breadth for lane-by-lane integration. On Orbit the same channels sit behind one API and one usage wallet, and what changes is what ships beside them: the contact center, the customer data platform, and the AI-voice lanes are inside the account rather than outside it.
Can I migrate Bird flows to Orbit?
Yes, by re-authoring rather than exporting. Bird flow definitions are proprietary, so a flow does not import; its routing contract does. The audit exports every IVR node and routing destination, the programmable voice surface reproduces the contract node for node, and the rebuilt flow validates on shadow traffic through a ported non-critical number before any caller touches it.
What moves first, and what moves last?
Phone numbers move first, in staged waves. SMS sender registrations and the delivery-report webhook consumer follow, with the WhatsApp and email lanes beside them, because the consumer must accept staging deliveries before a sender cuts. Voice call flows re-author on shadow traffic once a wave validates. OTP traffic moves onto the verify surface last, because a retry that re-sends a code is a customer-facing incident, so it closes the sequence rather than opens it.
The takeaway
Move off Bird on the per-family arc, not a platform leap: numbers port in waves, the delivery-report consumer stands up before senders cut, the messaging lanes re-register on one tenant-owned audit, call flows re-author on shadow traffic, and verify closes the sequence because OTP retries corrupt if you move them first. The comparison that decided the move lives on Orbit vs Bird and Orbit vs MessageBird; this runbook is the ordered execution of that decision.
Published 25 September 2026.