Most teams do not choose the wrong IoT connectivity provider. They outgrow the one they started with, and then discover what leaving costs.
The bill arrives in one of three forms. A field visit to every device to swap a SIM. A profile that belongs to the provider rather than to you. Or a contract whose exit clause was written by someone who assumed you would never read it that closely. By the time any of these surface, the fleet is deployed and the leverage is gone.
Exit planning is the work you do before signing, so that the answer to "what happens if this provider stops being the right one" is already known.
Lock-in is rarely a clause. It is usually a design decision nobody flagged as one.
An MFF2 chip soldered to a board is a 10 year decision about hardware. It becomes a 10 year decision about a supplier only if the profile on it cannot be replaced remotely. eUICC changes that, because the profile is separable from the chip. Ask which eUICC specification the provider supports, who holds the subscription management keys, and whether a competitor's profile installs on that chip without the incumbent's cooperation.
GSMA SGP.32 matters here. It moves profile management towards the device owner rather than the operator. A provider whose eUICC story stops at SGP.02 is offering remote provisioning that still routes through them.
A provider with a single roaming agreement in a market gives you that market's coverage and that market's outages. Multi-IMSI gives a device more than one route onto a network. It also means the provider is not the single point of failure between your device and any network at all.
This is a resilience question that turns into an exit question. If the fleet works only because of one specific roaming agreement, changing provider means re-testing every deployment against a different one.
Two years of session logs, usage patterns, and diagnostics sit in the provider's platform. If the only route to that data is a dashboard, migrating means starting the record from zero. API access to your own connectivity data is what makes the history portable. The IXT CMP exposes SIM data through an API so it lands in your systems rather than only in ours.
Provisioning workflows, billing reconciliation, alerting, and device onboarding get built against one provider's API. That integration is an asset until it is a cost. Ask how many engineering weeks it represents, because that number is part of the exit price.
The answers matter less than the willingness to answer. A provider who treats question two as hostile has told you what you needed to know.
Portability is the ability to change supplier. It is not a reason to.
Teams sometimes optimise so hard for exit that they choose a provider they would rather leave than stay with. The point of exit planning is to remove the fear from the decision, so that provider choice runs on architecture, coverage, security, and support rather than on what the switching cost would be.
It also does not solve permanent roaming. If devices operate under a roaming model that a regulator or an operator ends,
portability lets you change provider quickly. It does not stop the disconnection. Local IMSI options in the markets that matter are a separate piece of work. IXT supports local IMSI options in key markets to reduce permanent roaming risk.
IXT runs a dedicated mobile core built for IoT from the ground up, rather than virtualised on shared infrastructure. That gives direct control over routing, policy, and security. It also shapes the exit conversation, because the things you would need on the way out are things IXT operates rather than resells.
One SIM covers 600+ mobile networks across 190+ countries, in physical SIM, eSIM, or iSIM form. Multi-IMSI removes the single carrier dependency. The CMP exposes fleet data through an API rather than only a dashboard. None of that prevents you from leaving, which is the intended design.
Other providers you may compare against handle this differently. Cloud-native platforms move quickly on features and integrate cleanly with developer tooling. Where their architecture creates constraints is in direct control of routing and policy at fleet size, because those sit with a partner platform rather than with them.
No. eUICC separates the profile from the chip, which is necessary but not sufficient. Who holds the subscription management keys decides whether that separation is useful to you or only to the incumbent.
With eUICC and no field access required, the work is profile management, re-testing coverage in each market, and rebuilding platform integrations. Without eUICC, add a field visit per device, which for most fleets makes migration a replacement programme instead.
Some fleets do, usually split by region or device type. It keeps a live alternative and a real price reference. The cost is two integrations, two support relationships, and two sets of operational habits.
Long enough to complete a migration you have already scoped. That number comes from the migration plan, not from the contract template. Scope the migration first, then negotiate the notice.
Under 100 devices, the switching cost is low and the questions are quick. The effort pays off from the point where a field visit per device stops being practical, which for most teams is well before the fleet reaches four figures.
Take the six questions to your current provider before your next renewal, not during it. The answers tell you what a migration would cost, and that number belongs in the decision either way.
Ask us how it works for your deployment. Book a demo at ixt.io