The question SGP.32 explainers leave open is the one operations teams actually hold: we have an estate already in the field, on some mixture of conventional SIMs, SGP.02-era eUICC and assorted contracts, so what, concretely, is our path to the new architecture? The honest answer has more texture than the standard’s marketing, because SGP.32 adoption is not a switch an estate flips; it is a capability that arrives with new hardware and a transition the existing estate makes selectively, where it can and where it pays.
This piece assumes the background (our SGP.32 explainer and the SGP.02 comparison cover what the standard is and why it exists) and deals only with the migration mechanics. The short version of the architecture, for orientation: SGP.32 moves IoT profile management to an eIM, an eSIM IoT Remote Manager that orchestrates profile operations across fleets of devices, with a lightweight agent (IPA) on the device side, designed for estates of headless devices at scale.
First truth: what migrates is the capability, not necessarily the SIMs
Sort the existing estate into three populations, because their paths differ completely.
Conventional (non-eUICC) SIMs. No over-the-air path exists; these devices reach SGP.32 only through SIM or device replacement, which means at natural touchpoints or hardware refresh. For this population, SGP.32 is a forward specification, not a migration task: the decision is to stop deploying non-eUICC hardware, and the estate transitions at its replacement rate.
SGP.02-era eUICC SIMs. The nuanced middle. These SIMs are remotely manageable under the legacy architecture, and whether they can be brought under SGP.32-style management depends on implementation specifics: eUICC OS capability, the device’s ability to host the SGP.32 device agent (typically a firmware question), and what the SIM vendor and current provider support. Some of this population can transition over the air; some will live out its life under SGP.02 management. The work here is discovery, per SIM and device variant, with your providers, before any plan is written.
New deployments. Where SGP.32 actually happens first. Hardware selected now can ship SGP.32-ready, eUICC with appropriate OS, IPA-capable firmware, and every device deployed ready is one less in the eventual legacy tail.
The realistic estate plan, then, is the same shape as any technology transition: specify forward immediately, transition the middle population where discovery says it is possible and worthwhile, and let the conventional tail age out, managed as a coexistence problem in the meantime.
The readiness questions, in dependency order
Provider and eIM readiness. The eIM is the new operational centre, so the first questions go to your connectivity provider: what is your SGP.32 support, what does the eIM look like operationally, how do profile operations surface in the platform and the API, and how does it coexist with the SGP.02 infrastructure my middle population still needs? Watch for the difference between roadmap answers and operational ones; ask to see a profile operation executed. OV’s eUICC and SGP.32 alignment, with operations surfaced through OV ONE and its APIs, is exactly the kind of claim a customer should test live in a demo, and we encourage that test.
Device readiness. For each hardware variant: can the firmware host the device agent, what is the upgrade path for fielded units (an over-the-air firmware update enabling over-the-air profile management is a pleasing recursion, but it is still a firmware programme with all the usual discipline), and for new designs, is SGP.32 readiness in the specification now?
Profile strategy. SGP.32 changes how profiles move, not what they are; the estate still needs a deliberate answer to which profiles, from which providers, under which commercial terms, live on the eUICC. This is where the architecture connects to resilience strategy: a sensible pattern is an operational profile that is itself Multi-IMSI (multi-network resilience minute to minute, per our Multi-IMSI and eUICC explainer) with SGP.32 as the lifecycle mechanism above it.
Operational integration. Profile operations become part of the estate’s state machine: onboarding flows, support runbooks and monitoring all grow a profile dimension. Plan for the operational failure modes too, profile download failures, fallback behaviour, stuck states, which are real enough to deserve their own treatment in our companion piece on eSIM profile management in production.
A phased sequence that respects reality
Phase 0, discovery. Census the estate into the three populations; run the readiness questions; identify the device variants where the middle population can genuinely transition. Output: a scoped plan with honest boundaries.
Phase 1, forward specification. All new hardware SGP.32-ready; new deployments onboard under eIM management from day one. This phase costs little and compounds: it caps the legacy tail at today’s size.
Phase 2, pilot the transition population. A small wave of the transitionable middle: agent firmware deployed, devices brought under eIM management, profile operations exercised deliberately (download, enable, fallback) with exit criteria written before the pilot starts, the same wave discipline as any estate migration.
Phase 3, scaled transition and coexistence management. The transitionable population moves in waves; the operational model runs SGP.32 and legacy management side by side with clear ownership of each; the conventional tail is tracked against replacement schedules rather than wished away.
The sequencing principle throughout: SGP.32’s value compounds with estate coverage, but partial adoption is the normal state for years, and an operating model that handles coexistence gracefully beats a plan that pretends the tail does not exist.
Why move at all: the strategic restatement
Worth restating at the end of an operational piece, because it justifies the work: an estate under SGP.32-style management can change profiles, and therefore providers and commercial arrangements, over the air, at fleet scale, for devices nobody can economically visit. It is the architecture answer to the lock-in question, the regulatory-shift question (local profiles where devices settle, as our roaming restrictions guide describes), and the decade-long-estate question. The migration cost is real and the discovery findings are sometimes deflating; the option value, for estates measured in years and borders, is the reason the industry is moving.
OV supports customers through exactly this sequence, from discovery against the real estate census to pilot design and the coexistence operating model. The autumn webinar on SGP.32 in practice will work through migration lessons in detail; in the meantime, book a demo and bring your estate’s three populations with you.
Frequently asked questions
Can existing eSIMs be migrated to SGP.32?
Sometimes; it depends on the eUICC’s capabilities and whether the device can host the SGP.32 device agent, which is typically a firmware question, plus what the SIM vendor and provider support. Estates on SGP.02-era eUICC need per-variant discovery to sort what can transition over the air from what will live out its life under legacy management.
Do conventional SIMs have any path to SGP.32?
No over-the-air path; non-eUICC SIMs reach the new architecture only through SIM or device replacement. For that population the practical decision is forward-looking: specify SGP.32-ready hardware for everything new, and let the conventional tail age out at its replacement rate.
What is an eIM in SGP.32?
The eSIM IoT Remote Manager, the orchestration entity that manages profile operations (download, enable, disable, delete) across fleets of IoT devices, paired with a lightweight agent on each device. Operationally it is the new centre of profile management, which is why provider eIM readiness is the first migration question.
How long does SGP.32 adoption take for an existing estate?
Realistically it is a multi-year posture rather than a project with an end date: new deployments adopt immediately, the transitionable middle moves in waves after discovery and piloting, and the conventional tail converts at hardware replacement rate. The operating model that matters is graceful coexistence between architectures for as long as the tail lasts.
