Short answer
In many cases you can. Devices that support remote profile management move to a multi-profile SGP.32 eSIM through a firmware update, and their carrier then changes over the air instead of through a SIM swap. Some devices need firmware work first, and a few need replacing, which can usually wait for their normal refresh cycle. A device-by-device audit tells you which is which before you commit to a timeline.
Can I keep my existing hardware?
In many cases, yes, though the answer varies by device family rather than across the fleet as a whole. Sorting devices into categories early stops a schedule being built around the devices that migrate easily and then failing on the ones that do not.
| Category | What it means | What it costs |
|---|---|---|
| Upgradeable | Moves to SGP.32 through a firmware update. The hardware stays in the field. | Lowest |
| Refactor-required | Needs OS or firmware re-engineering before it can support remote profile management. | A development project, not a configuration change |
| Replace | Must be swapped for SGP.32-capable hardware. | Highest, but it can usually follow the existing refresh cycle |
How a fleet splits across these categories varies widely between deployments, and there is no reliable industry average to work from. That is why the audit comes before the schedule: a timeline proposed before anyone has reviewed the device inventory carries little weight.
What does a migration audit cover?
The audit covers six areas:
- Device inventory and firmware maturity. Every device in production, and the firmware version it is running.
- Existing profile management flows. How provisioning, activation and retirement are handled today.
- Infrastructure compatibility. Whether the existing SM-DP+ and lifecycle management tooling can work with an eIM (the SGP.32 eSIM IoT remote manager).
- Legacy dependencies. SGP.22-specific optimizations and SMS-based activation paths that will not carry across.
- Orchestration readiness. Whether the back end supports the SGP.32 model, where the eIM, the IPA (IoT Profile Assistant) on the device and the SM-DP+ work together.
- Fallback and failover behavior. What keeps a device connected if a migration step does not complete. See what happens if a profile switch fails.
Devices and flows that have not been inventoried cannot be planned around, and in practice they are where migration schedules slip. For the full six-step playbook, see Migration Strategies: Moving to SGP.32 with Confidence.
What happens to devices that cannot be upgraded?
Mixed fleets are the normal outcome of a migration, not an exception. During the transition the back end has to run legacy and SGP.32 devices in parallel, so the management platform needs to handle both from one place. With that in place, replace-category devices can move on their existing hardware refresh cycle instead of being brought forward at extra cost.
Device-level testing is a better guide here than vendor roadmaps, because devices with similar specifications often behave differently under remote provisioning.
“Every device has its own quirks. We've spent months with pin pads, sensors, blades, and routers. Each behaves differently. Our work shows that legacy devices can indeed be brought forward into the next era of IoT.”
Maurizio Tersigni, CEO, NuvoLinQ, announcing SGP.32 enablement for legacy devices, December 2025
How does the carrier change without a site visit?
A multi-profile eSIM holds more than one carrier profile and can download more over the air. Changing carrier becomes a profile operation instead of a physical one, which removes the SIM swap and the site visit that would otherwise come with it.
On a conventional SIM the carrier is fixed at manufacture, so changing it means someone has to reach the device. On an SGP.32 eUICC the same change is sent remotely. That is what makes migration without hardware replacement possible in the first place.
The device also needs the right network settings for its new carrier. NuvoAutoLinQ sets the correct APN automatically whenever the SIM changes carrier profile, so nobody has to reconfigure devices by hand after a switch.
Should we cut over at once or phase it?
A phased migration, validated against a pilot, is the lower-risk approach in most deployments.
A controlled pilot runs SGP.32-ready devices across representative use cases and regions, and tests profile management flows, back-end integration, monitoring and connectivity failover. Its results are what the wider rollout is built on.
Devices do not behave uniformly under SGP.32, and the differences tend to show up in the field rather than on the specification sheet. Aligning the phases with existing hardware lifecycles, SLAs and operational priorities spreads that exposure out instead of concentrating it on a single cutover date.
What happens if a profile switch fails?
A carrier change on an SGP.32 eUICC is several operations, and each can fail in a different way. Most failures recover on their own, on the eUICC itself, without anyone visiting the site. One edge case can still need a visit, and it is better to plan for it than to assume it away.
Two components do the work. The eIM (eSIM IoT remote manager) is the platform that sends profile operations to the fleet. The IPAe (the IoT Profile Assistant built into the eUICC) receives them on the device, downloads profiles and reports results back to the eIM.
| Where it fails | What happens | How it recovers |
|---|---|---|
| Profile download stops partway | The IPAe downloads the new profile over the currently active connection. Enabling it is a separate PSMO (Profile State Management Operation) that only follows a successful download, so the active profile is never replaced by an incomplete one. | Nothing to recover. The existing profile stays active, connectivity is not interrupted, and the download can be retried. |
| New profile enabled, but network attach fails | The device is on a profile that cannot attach to the network. | eUICC-side fallback, with no eIM involvement: SGP.32 fallback switches to the designated fallback profile when configured and its conditions are met, or the Kigen fallback applet switches back to the previous working profile or the bootstrap profile based on its timers. |
| Profile switch completes, but no data connection | The device does not handle the SIM Refresh correctly, or its APN settings do not match the new profile. | NuvoAutoLinQ corrects the APN. The newer NuvoLinQ fallback applet checks IP data connectivity, not just network registration, and returns the device to its bootstrap profile if data fails. |
| Fallback not configured, or recovery fails | The device stays offline and cannot be reached by the eIM. | Automatic rollback cannot be guaranteed, and a site visit may be needed. See below. |
Is there a bootstrap profile that can always bring a device back online?
Most NuvoLinQ eUICCs include a BICS bootstrap profile with wide network coverage, separate from the operational carrier profiles. When fallback is properly configured and its conditions are met, the eUICC switches to the bootstrap profile on its own to restore connectivity. Fallback has to be configured for this to work, so confirm the configuration for your devices during evaluation.
Does rollback happen on the eUICC or on the eIM?
Normally on the eUICC. A device that has lost its connection cannot be reached by any platform, so the fallback applet switches back to a working profile based on its configured timers and conditions, without needing to contact the eIM.
For devices that are still reachable, profile switching can also be managed remotely through the Kigen eIM platform, including campaigns that switch a group of devices to a specific profile in one operation, rather than device by device. Devices must be able to communicate with the eIM to receive and execute those operations.
When would a site visit still be needed?
A successful profile switch requires the device to handle the SIM Refresh correctly and, depending on the device OS, to have APN settings compatible with the new profile. If either fails, the device can lose connectivity. To reduce that risk, newer NuvoLinQ eUICCs support NuvoAutoLinQ, as an eUICC applet and as an Android application, to handle APN configuration, and the newer fallback applet checks IP data connectivity and triggers a return to the bootstrap profile when it fails.
These mechanisms significantly reduce the risk of a site visit, but they do not remove it. If automatic recovery fails and the device remains unreachable, physical intervention may still be required. Validating SIM Refresh handling and fallback behavior for each device family is one of the things the pilot phase is for.
What does the eUICC Readiness Program include?
NuvoLinQ's eUICC Readiness Program, introduced in December 2025, is designed to settle the compatibility question before a fleet commits to a migration path. It includes three services:
- Device compatibility testing, confirming SGP.32 readiness for network operation.
- Root cause identification, diagnosing firmware or SIM-profile issues that affect performance.
- Validation support, including complimentary 30-day test eSIMs for in-field evaluation before deployment.
To test your own devices, start an SGP.32 trial or talk to the NuvoLinQ team.