Migrating from Infobip to Orbit: the enterprise CPaaS de-migration runbook

Quick answer: Migrating from Infobip to Orbit is a six-step de-migration: export the inventory, quiesce inbound traffic, port the numbers, remap the API endpoints, move the Moments flows and Conversations inbox onto Orbit flows and the Orbit inbox, then validate on a smoke window and decommission the Infobip account. Infobip is often the carrier of record on the numbers it issued, so the porting step follows the carrier-hosted Letter of Authorization flow rather than the aggregator swap the Plivo runbook describes. The carrier-of-record explainer covers why that sequencing differs. The Orbit vs Infobip head-to-head and the long-form Orbit vs Infobip post carry the evaluation; this post is the execution.

Who should read this

This runbook is for enterprise Infobip senders hitting one of three frictions, each a buyer experience rather than a denigration of the incumbent.

Suite assembly across separately-onboarded products. Infobip ships a broad, genuinely shipped catalog: SMS, voice, WhatsApp, email, RCS, the chat apps, Moments for journey automation, Conversations for the agent inbox, and People as the customer data layer. Teams whose center of gravity is developer-first programmable communications, and who want the contact center and the customer data inside the same account rather than onboarded one product at a time under an annual plan, find the fit loosens as the surrounding suite grows.

Sales-led procurement against self-serve economics. Infobip routes pricing and onboarding largely through sales-assisted plans with annual commitments. Teams that want a published price page, self-serve signup, and one pay-as-you-go bill across every channel re-check the market periodically, and when that re-check ends in a move decision, this runbook is the ordered execution of it.

AI agents as platform core rather than a conversational layer. Infobip publishes a conversational-AI layer among its catalog. Orbit ships AI voice agents with a published latency methodology on the platform core, plus a native customer data platform with identity resolution behind every conversation. For teams whose next program budget is agent-led rather than campaign-led, the migration question becomes operational, and this post is the operational answer.

What Orbit ships that overlaps

Infobip genuinely spans the omnichannel surface, so the mapping lands on shipped Orbit surfaces, cited so the move is checkable rather than aspirational. The row values below mirror the public Orbit vs Infobip comparison page.

• Programmable SMS, RCS, and the SMS 2/3 endpoints map to [sms-api](/sms-api). Sender registrations, destination routing, and delivery-report webhook consumers move onto the SMS API surface. RCS Business Messaging moves onto the same surface on the same account.
• Programmable voice maps to [programmable-voice](/programmable-voice). Call flows, SIP 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 templates map to [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 maps to [email-api](/email-api). Transactional and campaign email move onto the email API surface on the same bill as the messaging lanes.
• Moments flows map to Orbit flows. Journey steps re-author against the flows surface; the routing contract of each journey transfers, and the proprietary flow definition does not import.
• Conversations maps to the Orbit inbox. Agent routing, assignment rules, and channel unification re-author on the inbox surface; conversation history exports as data, not as a live sync.
• People maps to the customer data platform. Segments, custom attributes, and consent state re-derive on the native CDP behind the same account rather than as an add-on above the messaging APIs.
• Verify stays a mapped lane where it exists. OTP endpoints on the Infobip account move onto verify-api, with throttling, fallback channel order, and the idempotency contract that keeps a retry from re-sending a code.

Side-by-side capability matrix

Work the table down. Connectivity crosses first because numbers gate everything behind them, the 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 the Moments/Conversations/People trio moves on the back half because each depends on a validated inbound path before its exports are meaningful.

The migration walk, in order

1. Export inventory: numbers, lanes, Moments, Conversations, People

The audit is the registration gate each wave re-checks before it moves. Export to one sheet:

• Every live number and its carrier-of-record status. Infobip is often the carrier of record on numbers it issued, so mark each number as Infobip-hosted or third-party-hosted; the porting flow differs per class.
• Every SMS, RCS, WhatsApp, and email lane with its sender identity, destination routing, and delivery-report endpoint.
• Every Moments flow with its entry trigger, step sequence, and channel fallbacks.
• The Conversations inbox definition: queues, routing rules, agent assignment logic.
• Every People segment, custom attribute schema, and consent state export.

2. Quiesce inbound traffic

Before numbers move, drain the inbound paths that resolve on Infobip-hosted equipment. Pause campaign sends that expect a reply into the Infobip inbox, point new inbound webhooks at a staging receiver you control, and freeze template edits so the export you took in step 1 stays current through the move window. Quiescing is the step that prevents a ported number from stranding an in-flight conversation on the wrong side of the cut.

3. Port the numbers

This is where the Infobip move differs from an aggregator incumbent. When the carrier of record is the platform itself, the Letter of Authorization runs against its numbering organization rather than against an upstream aggregator, and the losing-carrier response window is the thing to plan around rather than the inventory audit. The carrier-of-record explainer covers the LSR (Local Service Request) sequencing in detail. 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. Port in waves: a non-critical or after-hours line first, then customer-facing lines in batches once the first wave validates. 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.

4. Map API endpoints

Re-point the send-side integration surface by lane:

• Infobip SMS 2 and SMS 3 send requests map onto the SMS API send endpoints, with the delivery-report callback re-pointed at the Orbit webhook shape the SMS channel docs carry.
• WhatsApp template sends map onto the WhatsApp Business API send surface; WABA registration and template approval re-run per provider, so queue the template approval requests before the first cut.
• RCS agent traffic moves onto the same SMS surface once the RCS agent is registered on the Orbit account.
• Email sends re-authenticate the sending domain and warm the lane on a staging share before the full list moves.

The capability matrix above is the checklist each endpoint remaps against, and the Orbit vs Infobip comparison page carries the same rows in buyer-evaluation form.

5. Map Moments, Conversations, and People

Moments flows re-author on Orbit flows: each journey step, entry trigger, and channel fallback reproduces against the flows surface and validates on shadow traffic before any production entry points at it. A Moments flow definition is proprietary, so a flow does not import; its routing contract does. Conversations re-auths agent routing and assignment rules on the Orbit inbox, and the exported conversation history lands as an import against the inbox rather than as a live sync. People segments and custom attributes re-derive on the native customer data platform behind the same account; consent state exported in step 1 carries forward as the tenant-owned baseline the new CDP respects from the first send.

6. Smoke window, then decommission

Hold the Infobip account live through one full retry window after the last lane cuts: OTP retries on the old path, campaign replies resolving on the old inbox, and any unported number still terminating there. The idempotency explainer is the sequencing rule for the retry-sensitive lanes. Close the account only after the smoke window passes clean on every lane, because rollback stays available while the old senders stay live.

Pricing posture

Both platforms make their commercial shape computable, though by different routes. Infobip routes pricing largely through sales-assisted plans with annual commitments; 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:

1. Audit the Infobip inventory. Numbers by carrier-of-record class, every lane, every Moments flow, the Conversations routing definition, and the People segments, exported to one sheet.
2. Quiesce inbound so a ported number never strands an in-flight conversation.
3. Port numbers in waves, non-critical first, per the porting mechanics and country capabilities pages, with the carrier-of-record LSR flow from the carrier-of-record explainer for Infobip-hosted numbers.
4. Stand up the delivery-report webhook consumer before the first sender moves, per the SMS channel docs.
5. Re-author Moments flows and call flows on shadow traffic via the voice channel docs; the routing contract imports, the proprietary flow definition does not.
6. Re-derive People segments on the customer data platform with the exported consent state as the starting baseline.
7. Move OTP traffic onto the verify surface with the idempotency gate from the verify docs and the idempotency explainer as the sequencing rule.
8. Close the Infobip account only after the last retry window passes, because rollback stays available through step 7 while the old senders stay live.

Frequently asked questions

Is Orbit a good Infobip alternative?

Yes. Orbit is the AI-first alternative to Infobip when the messaging suite, the AI agents, and the customer data layer should be one platform rather than a broad catalog of separately-onboarded products. The Orbit vs Infobip head-to-head and the long-form Orbit vs Infobip post carry that answer with honest cell values: Infobip's channel coverage, fraud protection, and verification tooling are credited as parity, and the differentiation is what sits behind the channels.

Can I keep one account across SMS, WhatsApp, email, and voice after the move?

Yes. That is the shape Infobip sells as a suite, and 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 native customer data platform, and the AI-voice lanes are inside the account rather than separately-onboarded products around it.

Can I migrate Infobip Moments flows to Orbit?

Yes, by re-authoring rather than exporting. A Moments flow definition is proprietary, so a flow does not import; its routing contract does. The audit exports every entry trigger, step, and channel fallback, the flows surface reproduces the contract step for step, and the rebuilt journey validates on shadow traffic before any production entry points at it.

How do Infobip-hosted numbers port?

Through the carrier-of-record LSR flow rather than an aggregator swap. When Infobip is the carrier of record on the numbers it issued, the Letter of Authorization runs against its numbering organization, and the losing-carrier response window is the planning constraint. The carrier-of-record explainer walks the sequencing, and the phone number porting guide carries the mechanics per wave.

What moves first, and what moves last?

The inventory export moves first, because every later wave re-checks against it. Numbers move second, in staged waves, with the messaging lanes and the delivery-report consumer beside them once the first wave validates. Voice call flows re-author on shadow traffic mid-sequence. Moments, Conversations, and People move on the back half, because their exports are only meaningful once the inbound path 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 Infobip on the de-migration arc, not a platform leap: export the inventory, quiesce inbound, port the numbers through the carrier-of-record flow where it applies, remap the endpoints per lane, re-author Moments and Conversations on flows and the inbox, re-derive People on the native CDP, and let the smoke window close the account. The comparison that decided the move lives on Orbit vs Infobip and the long-form versus post; this runbook is the ordered execution of that decision.

Published 6 October 2026.