Subscriber migration
Move subscribers to a new network without replacing a single card.
When an MVNO is acquired, changes host operator or gets a new PLMN, everything that
identifies the subscriber has to change on cards that are already in customers' phones. IMSI,
MSISDN, PLMN preference lists, service tables and applet parameters. Updated over the air, in
planned waves, with a retry strategy per error code.
Case study
National subscriber migration
OTA side of a national migration of about 2 million live SIMs, including the on-card
migration applet, at over 98% success. Measured against reachable subscribers, not total
cards in inventory.
- Scale
- ~2 million live SIMs
- Outcome
- >98% success, no mass card swap
- Scope
- OTA campaign + on-card applet
- Also
- ~300k subscribers on a separate migration
How it is done
OTA campaign
Mixed vendors, per-card state, retry keyed to PoR and network codes. On-premise SCP80 when
Ki, OPC and OTA keys must stay on site.
OTA server Custom applet
When the card must decide identity, timing or recovery, that logic belongs on the SIM.
Java Card / STK, loaded over RAM.
Applets What usually goes wrong
- Cards switched off, roaming, or unreachable in the send window
- Mixed vendors, profiles and applet versions in the same campaign
- Half-applied updates
- Counter drift that looks like a network fault
- No per-card response: cannot tell success from silence
- Cards from a vendor where nobody still holds the OTA keys
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 networks 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 campaign.
- 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 SIMs — it is not a one-size template.