Subscriber migration

Move subscribers without replacing every SIM.

Estate, campaign, on-card state, cutover, retry. A systems programme — not a large SMS blast.

Case study

Golan Telecom → Cellcom

National subscriber migration in Israel. We ran the OTA side and built the on-card migration applet.

Operators

Golan Telecom → Cellcom

Scale

~2 million SIMs

Outcome

>95% success, no mass card swap

Scope

OTA campaign + on-card applet

How a programme like this is done

What usually goes wrong

• Cards off, roaming, or unreachable in the window
• Mixed vendors, profiles and applet versions
• Half-applied updates
• Counter / replay drift that looks like a network fault
• No per-card response — cannot tell success from silence

PoR 09 (TAR unknown) is often segmentation, not a retry. Guide · Packet decoder

FAQ

Migration questions

How do you migrate SIMs without replacing the card?

With an OTA campaign that updates identity files on the live card — usually the IMSI (International Mobile Subscriber Identity), often the ICCID, and network files such as PLMN lists. That is RFM (remote file management). When the card must decide timing, identity or rollback itself, a custom applet is added (RAM). The handset is typically told to re-read the card with a REFRESH after IMSI change (see 3GPP USAT rules for EFIMSI).

How do authentication keys work when the IMSI changes?

Each IMSI in the HLR/HSS (or AuC) is tied to authentication material (Ki / K and related operator values). The old and new IMSI must both be able to authenticate, or the subscriber drops. Common approaches: a custom solution on the SIM that manages the key transition, or unifying keys in the core so both IMSIs share the same secret (a pattern also described in 3GPP SIM/USIM interworking notes for shared-key cases). Card OTA and core provisioning have to stay in step.

What if the old IMSI to new IMSI map is not a simple range?

If one continuous old IMSI range maps cleanly to one new range, a single OTA campaign may be enough. In most live estates the map is scattered: many old IMSIs map to many new ones with no simple formula. Then you need per-card targeting — custom logic inside the OTA engine (a MoreOTA strength) or a custom applet that holds the map. An applet also makes rollback easier when a card must revert.

Do you need to change the ICCID in a SIM migration?

IMSI and authentication keys are mandatory. Changing the ICCID is good practice, not always strictly required for attach. Some smartphones use the ICCID to customise the mobile OS for that operator. The mobile network code appears in both the IMSI and the ICCID, so leaving an old ICCID can confuse device or support tooling even when the network accepts the new IMSI.

Does SIM migration change the APN?

Sometimes yes — as a side effect of changing the IMSI, not because you wrote an APN file for the handset. Many mobile OSes pick a default APN from the MNO code in the IMSI. After migration the OS may switch to the new operator’s APN. Separately: an APN (or similar) on the SIM is usually for SIM/STK connectivity (for example an applet opening a channel). That is not the same as the device’s everyday internet APN, which normally comes from the OS or from the network (APN proxy / provisioning).

Can a failed OTA migration leave the SIM half updated?

Yes. Order of file updates, when identity is committed, and which REFRESH mode you use after EFIMSI all matter — the wrong refresh path after an IMSI change is undefined behaviour in 3GPP USAT. Sometimes a dedicated applet is required so the card can finish, roll back, or wait safely. Design for intermediate state before you send a large estate.

What are transition SIMs in a migration?

Cards manufactured with the old IMSI that are not yet live in the field. They need a different path than active subscribers. One approach is a core-network trigger when the new IMSI first registers. Contact us for the approach that fits your estate — it is not a one-size template.

Contact

Discuss a migration