Title: Why switching CPaaS providers is harder than it looks

URL: https://www.infobip.com/blog/why-switching-cpaas-providers-is-harder-than-it-looks

Most platform teams think their CPaaS relationship is an API integration. Swap the endpoints, point the webhooks somewhere else, done in two sprints. That's the version your vendor is comfortable with you believing.

The reality is different. Underneath the API, your CPaaS vendor likely controls things you don't realize they control: your 10DLC registrations, your WABA registration, your RCS agent definition, your email sending reputation, even the multi-tenant provisioning model your entire customer base runs on. None of this shows up in your API documentation. Most of it won't surface until you try to add a second provider or leave your first one.

This isn't about convincing you to switch. Plenty of platforms aren't switching, they're adding a second vendor for resilience, scale, or better regional and channel coverage. But whether you're replacing your CPaaS provider, adding one alongside it, or just renegotiating terms, the question is the same: what do you actually own, and what does your vendor own on your behalf?

Having helped platforms through both full migrations and multi-vendor buildouts, here's what we've learned.

## Before anything else: Understand your multi-tenant architecture

Your platform isn't one integration. It's a per-customer platform with potentially hundreds of tenants, each with their own configuration. Before you evaluate registration ownership or channel portability, you need to understand what you're working with at the platform layer.

Whether you're replacing a provider or adding one, you're dealing with your provisioning layer: sub-accounts, per-customer number assignments, sender ID mappings, API key hierarchies, webhook configurations, and how to interpret delivery and provisioning error codes. This is the infrastructure your business runs on, and most CPaaS providers model it differently.

One gives you sub-accounts per customer. Another expects you to build tenant isolation yourself on top of a flat API. A third offers a dedicated ISV multi-tenant framework with automated resource provisioning and a unified API across channels. If you're adding a second vendor, you need to understand whether your current architecture can route traffic across providers at the tenant level or whether you're locked into a single-vendor model by design. If you're replacing one, moving between multi-tenancy models means rearchitecting how your platform provisions, isolates, and manages customer resources.

The provisioning questions surface fast. Can a new provider's APIs support programmatic customer onboarding at the pace your sales team closes? If you're onboarding 10–20 new customers per month today, and your current provider handles sub-account creation, number assignment, and sender registration through APIs, any new provider needs to match or improve that workflow. In a multi-vendor setup, that means your orchestration layer needs to abstract provisioning across both.

There's a third option some platforms don't consider. Rather than building the orchestration layer yourself, you can use a provider whose platform is designed to sit between your application and multiple underlying carriers and channels, abstracting the multi-vendor complexity into a single provisioning and routing layer. That's a fundamentally different relationship than a traditional CPaaS integration.

Get this mapping done first. Document how your current provider models tenant isolation, how provisioning works (API-driven or ticket-based), and what per-customer resources exist. Everything that follows, the ownership audit, the channel-by-channel mechanics, sits on top of this foundation.

## Start with what you own, not what your dashboard says you own

The first thing that breaks when you try to move traffic, whether fully or partially, isn't technical. It's ownership. Platforms discover, mid-move, that their current provider registered critical assets on their behalf. And those assets don't travel to a new provider, even if you're only shifting a portion of your traffic.

These are the areas that trip people up consistently.

### 10DLC: CSP vs. Reseller is the whole ballgame

To understand why this matters, you need to understand how 10DLC registration works at the structural level. The Campaign Registry (TCR) has two registration models: Campaign Service Provider (CSP) and Reseller. If your CPaaS vendor registered your brands and campaigns as the CSP. Meaning they hold the direct TCR relationship, and you're listed as a reseller underneath them, then you're in a fundamentally different position than if you'd registered as a CSP yourself.

TCR's migration tool allows Connectivity Partners (CNPs) and Campaign Service Providers (CSPs) to move campaigns instantly between providers, no downtime or throughput reset. Re-vetting may not be required, depending on the gaining DCA provider. However, this tool is only available to CSPs migrating their own campaigns. Resellers can't use it.

If you're a reseller, you will likely re-register from scratch. And re-registration means your brands start on starter throughput: T-Mobile's Low tier caps at 2,000 messages per day; AT&T's class F marketing limit sits at 75 messages per minute. If your customers were doing 50,000 T-Mobile messages daily, that's a 96% throughput reduction while the new registration works through the system. That's 2–7 days at minimum, and brands registered for less than a year systematically receive lower vetting scores.

This matters even in a multi-vendor scenario. If you want to route some US SMS traffic through a second provider, those campaigns need to be registered there too. Without CSP ownership, you can't move or duplicate them. You'd need to re-register, which means maintaining parallel registrations or accepting a throughput gap during the transition.

The fix: Register as a CSP yourself. It costs $200 one-time plus $46 per brand identity check and vetting, trivial compared to the penalty. But you need to do it while your current provider is still cooperative, not after you've signaled intent to diversify.

### WhatsApp: Ownership is cleaner than it used to be

Built to support its evolving business messaging ecosystem, Meta retired the On-Behalf-Of (OBO) model on October 30, 2025, and automatically migrated all remaining accounts the following day. Under OBO, your BSP managed your WABAs without you directly owning them, which made provider relationships highly sticky.

The sunset means most WABAs are now properly owned by the businesses themselves. If yours are clean, a CPaaS migration on WhatsApp is surprisingly painless: quality ratings, messaging limits, and display names migrate with each number, and the actual per-number migration takes minutes.

But that depends on how well your provider handled the transition. Some providers dragged their feet on the OBO transition and didn't begin until August 2025, cutting it close to the deadline. That led to complications after the automatic migration.

For multi-vendor setups, note that a WhatsApp phone number can only be connected to one BSP at a time. You can't split WhatsApp traffic across providers the way you can with SMS, it's one or the other per number, which makes the ownership question even more important, because whichever provider you choose needs clean WABA access.

### Email: Reputation stays behind

This one is more mechanical but less obvious. Your customers' email has been flowing through shared or dedicated IP pools on your current provider. When you move traffic, the IP reputation stays with those IPs. It doesn't follow you.

New IPs mean 4–8 weeks of warming: starting at a few hundred emails per day, gradually scaling up. During that time, your customers' emails don't bounce, that would be visible. They land in spam. Gmail's throttling is silent. No error codes. Delivery rates look fine, mid- to high-90s, but open rates crater because messages are sitting in junk folders.

Domain reputation helps compress the warming timeline, from eight weeks down to one or two, but it can't eliminate warming entirely. Gmail evaluates a tuple of IP, DKIM selector, and domain. Change two of those three, and you've reset most of your reputation signal.

There's an exception worth knowing about: if your platform owns dedicated IPs, not your provider's shared pool, but IPs allocated to you, some providers can let you bring those IPs with you. Same concept as BYOC for voice, applied to email. Your reputation travels because the IPs travel. It's not common, and it requires a minimum /24 block (256 IPs) to be practical, but for platforms with that scale it eliminates the warming problem entirely.

Email is actually the channel where a multi-vendor approach makes the most strategic sense. A relay layer that routes across providers lets you warm new IPs gradually while maintaining deliverability through your existing provider. You're not choosing one or the other, you're running both, shifting traffic based on real-time deliverability data. Once that layer is in place, you're never fully locked to a single ESP again.

### Voice: The one that people underestimate

Voice portability is often described as a number-porting exercise, but the number is only part of what moves. The port also depends on the numbering asset itself, the relationship with the current carrier, the regulatory and ownership documentation required in each market, and the inbound and outbound routing that has to be re-established once the number moves. The technical port is only one step. The real complexity sits in the telecom infrastructure behind it.

That is where provider depth becomes visible. If voice services are tightly coupled to a single vendor's numbering estate, carrier relationships, and routing model, portability becomes slower, more manual, and more operationally fragile than the API layer suggests. A provider with direct operator relationships, established numbering capabilities, and experience handling market-specific portability requirements is in a stronger position to make the process workable in practice.

Where the same number supports both voice and SMS, that shared numbering asset can also simplify coordination later, because related services stay aligned inside the same operational framework.

#### The lesson: Audit what you actually own

Audit what you actually own, not what your dashboard says, what TCR says, or what your IP allocations look like. If your vendor registered on your behalf, adding or switching providers just got harder. And if you're not making a move yet, take ownership now. The time to fix this is while your current provider still has reason to cooperate.

## Every channel has its own portability rules

The ownership audit tells you what you control. The next question is: what can you actually move, split, or run in parallel and what constrains you?

SMS is the most flexible. You can port numbers (slow but preserves identity), buy new ones (fast but changes sender), or, with a bring-your-own-carrier architecture, dual-route across providers during a transition. Dual-routing means messages flow through whichever provider serves each carrier best: new platform for migrated carriers, existing provider for pending ones.

Your customers never experience a gap. In a multi-vendor setup, this same architecture lets you route by geography, cost, or performance permanently, not just during a cutover. A platform layer that manages carrier connections independently of any single CPaaS vendor means you own the routing decisions, not your provider.

That flexibility looks different depending on where your numbers live. In the US, porting isn't a technical configuration, it's a set of separate registries and carrier approval chains, and which one applies depends on your sender type.

10DLC (Local Numbers): In the US, and across more than 10 markets, Infobip owns local numbering resources and works directly with regulatory bodies, as well as carriers, on number portability. But porting the number is only half the battle. You must also re-associate the existing Brand and Campaign registrations at the TCR layer with your new upstream carrier. If the mapping isn't exact, carriers can silently drop traffic after the port.

Toll-free numbers run through Somos, the registry that manages Responsible Organizations (RespOrgs). Moving one means filing a formal RespOrg change request with verified Letters of Authorization, a manual process that stalls on the smallest clerical mismatch.

Short codes are the slowest of the three. They're leased through the U.S. Short Code Registry, and migrating one means re-binding the network across Verizon, AT&T, and T-Mobile individually. Carrier approval routinely takes weeks, which is exactly why parallel routing during the transition isn't optional.

Outside the US, the bureaucracy just changes owners. Instead of dealing with a single portability framework, you're maintaining local sender IDs and navigating whatever telecom ministry rules apply in each country.

Voice is portable, but the service behind it is not as simple to move. The number can port, but carrier relationships, regulatory records, numbering ownership, and routing all have to line up on the other side. That makes voice more operationally sensitive than it first appears, and it is where provider depth matters.

WhatsApp is fast per-number but structurally single-vendor. Migration takes minutes per number, and quality ratings carry over. But each phone number can only be connected to one BSP at a time, so you can't split traffic. At scale (200+ numbers), coordination overhead dominates: individual OTP verification per number (no batch API from Meta), display names must be in "Approved" status, and migrated templates restart as "Quality Pending."

Email is where multi-vendor architectures shine. A multi-provider relay layer lets you run old and new ESPs simultaneously, shift traffic gradually, and maintain deliverability throughout.

In practice: One documented implementation migrated 1,000+ accounts in four months using percentage-based traffic splitting with real-time health scoring. The three-layer architecture, inbound routing, rule engine, outbound delivery, works across major ESPs.

For platforms adding a second provider rather than replacing one, this relay architecture isn't a migration tool, it's the permanent operating model. Route by deliverability performance, cost, or geography. The warming problem disappears because you're always running both.

RCS is the honest answer nobody wants to hear. There's no self-service path to transfer an RCS agent between providers. There exists a manual process involving attestation letters and email approvals from the brand and the “Brand Partner” (CSP), then approval from each carrier, and a manual switch by Google than needs to be coordinated with all parties.

The process will certainly evolve and mature and much of the inconsistency between markets can be expected to reduce (that fluidity presents a challenge in itself), but at present it's remains a process with operational overhead and is certainly not scalable. The alternative path, registration of new agent with the provide and retiring the original does not present a generally feasible option. Whilst a more mature process, it still requires carrier-by-carrier approval and 4-6 weeks minimum in the US market. And this also means a new message thread on the user’s device, so would provide poor UX also.

This is the strongest lock-in point in the current channel landscape. A provider with direct carrier relationships (DCA) compresses the timeline but can't eliminate it. We tell platforms this upfront, because pretending otherwise would undermine everything else in this briefing. If you're evaluating a multi-vendor strategy, RCS is the channel you'll likely keep single-vendor longest. Apple Messages for Business, by contrast, is notably more portable, the brand controls the account, and the messaging service provider is a pluggable configuration.

## The multiplication problem

Everything above is per customer. Now multiply by your customer base.

200 customers across 3 geographies using 4 channels isn't a migration project or even a multi-vendor integration project. It's a program. Each customer has their own combination of channels, geographies, sender registrations, and number types. A single rejection, a 10DLC campaign that needs re-vetting, a WhatsApp template auto-reclassified creates a cascading delay for that specific customer while everyone else moves forward.

This is where the ownership audit from earlier compounds. One customer with tangled registrations is a support ticket. Two hundred customers with tangled registrations is a program failure. And in a multi-vendor setup, you're managing this complexity across providers permanently, not just during a one-time migration.

This is why the multi-tenant architecture assessment matters so much as the first step. If your provisioning layer can't orchestrate across providers, routing by channel, geography, or customer segment, then multi-vendor becomes an ops burden rather than a strategic advantage. The platforms that handle this well either build that orchestration themselves or choose a provider whose platform already functions as the management layer across carriers and channels, one integration that abstracts the complexity of multiple vendor relationships underneath.

## The platform independence checklist

Whether you're planning to switch, add a second vendor, or just want to know where you stand, here's the audit that matters:

1. **Understand your architecture.** How does your current provider model multi-tenancy? Is provisioning API-driven or ticket-based? Could your orchestration layer route traffic across two providers, or are you structurally locked to one?

1. **Verify registration ownership.** Are you the CSP on your 10DLC campaigns, or is your vendor? Across markets, do you own the underlying messaging assets, campaigns, local numbers, short codes, sender IDs, DIDs, toll-free inventory, and regional registrations? Can you port, reassign, or recreate them independently without unnecessary friction or vendor dependency? Do you control your email IP allocations? Ownership determines your leverage, flexibility, and long-term optionality, whether you're negotiating, adding, or replacing providers.

1. **Map your portability by channel.** SMS is flexible (especially with [BYOC](https://www.infobip.com/blog/bring-your-own-carrier-explained)). WhatsApp is fast but single-vendor per number. Email benefits most from multi-vendor architecture. RCS doesn't move without effort. Knowing this shapes which providers you can realistically add or replace, and on what timeline.

1. **Assess your scale math.** How many customers × channels × geographies are you managing? At what point does manual coordination break? If the answer is "already," then the architecture for managing multiple providers is the same architecture that fixes your operational bottleneck.

1. **Decide your strategy.** Replace, augment, or just take control. Full migration is one path. Adding a second provider for resilience, cost optimization, or regional strength is another. And simply taking ownership of your registrations, CSP status, and dedicated IPs improves your position regardless of what comes next.

This audit takes a week, costs nothing, and changes how you think about your vendor relationship.

## Why this matters even if you're staying

This isn't only relevant if you're planning to leave. Understanding what your vendor controls is good platform governance regardless.

If you run the audit and discover you own everything cleanly, your own CSP registration, dedicated IPs, API-driven provisioning, then you're in a strong position. You have optionality. You can renegotiate from strength, add a second provider where it makes sense, or move entirely if the relationship stops working. We've written about the signs that indicate it's time to evaluate.

If you run the audit and discover your vendor controls more than you thought, registrations under their CSP, shared IPs with no portability, ticket-based provisioning, then you've found something worth fixing regardless of your plans. Taking ownership of your registrations and moving to dedicated IPs, these aren't migration prep. They're platform maturity. They remove compliance friction, give you leverage in vendor conversations, and ensure your customers' messaging infrastructure isn't dependent on a single relationship.

The platforms that run well, not just the ones that migrate well, are the ones that understand what sits below the API. The registrations, the reputations, the provisioning layer, the per-customer infrastructure. Some solve this by building their own orchestration. Others choose a partner whose platform was designed from the start to manage that complexity, 800+ carrier connections, unified API, multi-tenant provisioning, so the platform team can focus on their product instead of their vendor relationships.

Whether you're staying, adding a second provider, switching entirely, or just want to know where you stand, start with the audit.

Find out what you actually own before you need to move.

 [ Talk to our team ](/contact) 









 ![](https://cdn-web.infobip.com/uploads/2025/12/cta-thumbnail-image-8-scaled.jpg)

## Get the latest insights and tips to elevate your business

By subscribing, you consent to receive email marketing communications from INFOBIP. You have the right to withdraw your consent at any time using the unsubscribe link provided in all INFOBIP's email communications. For more information please read our Privacy Notice