Nobody switches IoT connectivity providers casually, and the reason is physical. Unlike most B2B services, the incumbent’s product is sitting inside your devices, possibly soldered to the board, possibly on a pole in another country. The perceived weight of that fact keeps many estates on providers they have outgrown for years longer than the economics justify.
The weight is real but routinely overestimated. Estates migrate successfully all the time, and the ones that do it without drama follow a recognisable structure. This piece sets that structure out as a five-phase framework, along with the honest version of the question every migration starts with: how hard will this actually be for our estate?
First, classify your estate: the three migration profiles
Migration difficulty is determined almost entirely by what is physically in your devices, so start by classifying the estate into three profiles.
Profile A: physically accessible devices with removable SIMs. Trackers in a depot, terminals in stores you control, equipment that returns for servicing. Migration means SIM swaps, which is a logistics exercise: real work, fully solvable with planning.
Profile B: eUICC-capable SIMs. If your current SIMs support eUICC remote provisioning, and your contract permits it, profiles can potentially be switched over the air without touching devices. This is the scenario remote SIM provisioning was designed for, and where the SGP.32 standard is making increasingly routine. The caveats sit in the contract and the implementation as much as the technology, so this profile demands early technical discovery with both providers.
Profile C: physically inaccessible devices with non-eUICC SIMs. The hard category. Options narrow to migrating at natural touchpoints (servicing, battery replacement, hardware refresh), running the old provider down on those devices while new deployments go to the new provider, or accepting a long dual-provider tail. None of these is failure; planned coexistence is a legitimate end state, and pretending otherwise produces worse plans.
Most real estates are a mix, and the migration plan should be written per profile rather than per estate.
Phase 1: Audit before you negotiate
The estate audit comes before provider selection finishes, because its findings shape the deal you should sign. Establish per device class: SIM form factor and eUICC capability, physical accessibility, firmware dependencies on the current provider (hard-coded APNs are the classic one), any static IP or private APN arrangements that systems depend on, and the contractual position, including notice periods, termination terms and who owns what.
Two audit findings change everything and are worth hunting deliberately. Hard-coded connectivity parameters in firmware turn a SIM swap into a firmware update programme, which needs to enter the plan early. And IP-dependent integrations, systems that reach devices at known addresses, mean the new provider’s private networking design must exist before cutover, not after.
Phase 2: Prove the new network before committing the estate
Whatever evaluation led to the new provider (our decision framework covers that selection process), migration planning needs empirical proof in your hardware. Run a structured pilot: real devices, real firmware, in a sample of real locations weighted toward your hardest coverage environments. Measure attachment behaviour, signal performance, data consumption against expectations, and the operational workflow end to end, from provisioning through monitoring to a deliberately triggered support escalation.
This is also where multi-network behaviour earns scrutiny. SIMs with Multi-IMSI technology and non-steered network selection attach to the strongest available network rather than a fixed list, which matters doubly during migration because the new SIMs will be proving themselves across the same sites where you know the old provider’s coverage map by heart. A free SIM trial in your own devices is the cheapest insurance a migration can buy.
Phase 3: Parallel running
The defining decision of a low-risk migration is to run both providers simultaneously for a defined window rather than attempting a clean break. Parallel running means new deployments and swapped devices operate on the new provider while the remaining estate stays live on the incumbent, with both estates visible to your operations team throughout.
The operational requirement this creates: your monitoring and management tooling must span both providers for the duration. Where the new provider’s platform is API-first, this is an integration task rather than a manual one; OV ONE exposes every platform feature through documented APIs precisely so estate state can be pulled into whatever operational view a customer already runs. Build that integration before cutover begins, because flying blind on either side of a migration is how minor issues become incidents.
Parallel running costs money by definition, which is the subject of the contract overlap question below. It buys the ability to halt, slow or reverse at every stage, which for an estate of any size is worth what it costs.
Phase 4: Cutover in waves, sequenced by reversibility
Never migrate by geography alone or, worse, alphabetically. Sequence waves by how reversible and how observable each tranche is. A sensible default order: first, new deployments (zero migration risk, immediate validation of the new provider at scale); second, accessible low-criticality devices, the Profile A estate that tolerates a hiccup; third, accessible high-criticality devices, with the playbook now proven; and finally the Profile B over-the-air estate, in small waves with verification at each step, since remote profile switching should be treated with the same wave discipline as physical swaps.
Per wave, define before starting: the verification criteria that mark a device as successfully migrated, the monitoring window before the next wave proceeds, and the rollback path, including who decides and on what evidence. Waves without rollback criteria are not waves; they are hope with scheduling.
Phase 5: Decommission deliberately
The migration ends when the old estate is formally closed, not when the last device moves. That means confirming every SIM on the old contract is accounted for (migrated, retired or consciously retained in a Profile C tail), terminating services against the contract’s notice mechanics, recovering or securely disposing of swapped SIMs, and unwinding integrations and credentials tied to the old platform. Estates that skip this phase rediscover it as billing disputes.
The contract overlap question
Every migration has a period of paying twice, and the planning question is how long and on what terms. Three levers shorten or soften it. Time the migration against the incumbent’s renewal calendar, since notice periods are the hard constraint everything else schedules around. Negotiate the ramp with the new provider openly: providers experienced in migrations expect a commitment curve that climbs as waves complete rather than a full-volume start. And resist the temptation to compress waves purely to end the overlap, because the cost of overlap is linear and the cost of a botched compressed cutover is not.
Where OV fits
OV runs migrations onto its network regularly, and the structural features that matter for migration are the ones described above: coverage across 180+ countries and 600+ networks for proving the network wherever your estate lives, Multi-IMSI SIMs with non-steered selection for resilience at coverage edge cases, eSIM and eUICC support for the over-the-air pathway, and the in-house OV ONE platform with full API access so parallel-running visibility is an integration rather than an improvisation. If a migration is on your horizon, start with a free SIM trial against your hardest sites, and our team will work through the phased plan with you against your real estate profile.
Frequently asked questions
How long does an IoT connectivity migration take?
It depends on estate size, device accessibility and how much of the estate is eUICC-capable, with realistic timelines running from a few weeks for small accessible estates to a year or more where large deployed fleets migrate at natural touchpoints. The phased structure matters more than the calendar: waves with verification and rollback criteria keep long migrations safe.
Can SIMs be switched to a new provider without physically replacing them?
Sometimes. If the deployed SIMs are eUICC-capable and the contractual and technical conditions allow profile changes, migration can happen over the air, which is the scenario the SGP.32 standard addresses for IoT estates. Where SIMs lack eUICC capability, physical replacement or migration at natural touchpoints remains the path.
Should both providers run in parallel during a migration?
Yes, for any estate of meaningful size. Parallel running preserves the ability to pause or reverse at each wave and keeps the deployed estate observable throughout. The cost of the overlap period is the explicit price of that safety, and it is negotiable through ramped commitments with the incoming provider.
What is the biggest cause of failed connectivity migrations?
Skipped discovery, most often hard-coded connectivity parameters in firmware or IP-dependent integrations found during cutover instead of during the audit. Both are manageable when found early and disruptive when found late, which is why the audit phase precedes final contract negotiation in a well-sequenced plan.
