A customer ports their number away to another operator. What has to happen on your side, and what usually goes wrong?

The port date is not yours

The first thing to establish is that this is an inter-operator process governed by the market's regulator and coordinated through an agreed mechanism — in most markets a central clearing function or reference database that all operators query and update, with defined message exchanges and defined timers. The gaining operator initiates, the losing operator validates, and a porting date and time is agreed between them. Your systems participate in that process; they do not own it.

That has a consequence that shapes the whole design. The moment of cutover is a scheduled external event you must align to precisely, not a step in your own workflow that can run when the queue gets to it. Almost every serious failure in porting is a timing failure between your cease and the industry's cutover, and the two directions of error are not equivalent.

If you cease before the port completes, the customer has no service at all: their number is not yet routed to the new operator and yours has stopped serving it. That is an outage you caused, on a day the customer is already unhappy enough to be leaving, and it may take them out of contact including for emergency calls if they have no other line.

If you cease late, the customer is fine, because routing has moved and calls follow the number to its new home. You are the one damaged: you continue to bill a subscription for a service you are no longer providing, which produces a complaint, a refund and often a regulatory one; you keep network resources allocated; and any usage the subscriber generates on your systems in the meantime is unbillable.

Given the asymmetry, the safe posture is to cease on positive confirmation of the port rather than on the scheduled time arriving, and to build the process so that late is the direction it fails in.

sequenceDiagram
  participant C as Customer
  participant G as Gaining operator
  participant P as Porting hub
  participant L as Losing operator
  participant N as Routing data
  C->>G: Asks to port the number
  G->>P: Port request with validation details
  P->>L: Request to release the number
  L-->>P: Accept or reject with a reason
  P->>N: Routing updated at the agreed time
  L->>L: Cease service and close billing on confirmation

The step to look at is the last one, because it is the only one inside your own estate and the only one that is not driven by an external timer.

Validation is narrow, and refusing is dangerous

When the request arrives you validate it, and the scope of legitimate validation is much narrower than commercial instinct suggests. You are checking that the number exists on your network, that it belongs to the subscription the requester has identified, and that the identifying details the customer gave the gaining operator match what you hold. Regulators generally allow rejection only for defined reasons of that kind, and they take a dim view of using the process to retain a customer. A wrong or slow rejection is therefore not a delay, it is a compliance problem, and the reason codes you return matter because they go back to the customer through the other operator.

The frequent, avoidable rejections come from your own data. The number is on the account but the account reference the customer quoted is a different one after a migration. The identifying detail is held in an old format. The number is in the middle of another change order and your system will not accept a concurrent transaction against it. That last case is the one to design for explicitly: an in-flight order against the same subscription needs a rule, and the workable rule is that the port takes precedence and the other order is cancelled or completed first, decided deliberately rather than by whichever process locks the row.

Cease the subscription without ceasing the customer

The number and the customer relationship are separate things, and conflating them causes a recognisable set of incidents.

A customer with several lines on one account who ports one line must keep the others working, keep any shared allowance intact with its remaining members, and keep their account, billing arrangement and login. If the ported number was also the account's login identity, the credential to notify, or the anchor for a family plan, then removing it breaks things that have nothing to do with the port. Any authentication or notification path that uses the number needs to move to something else before cutover, or the customer loses access to the account they still hold.

On the network side, cease means the subscription's entry is removed from the subscriber data store so the network no longer serves it, the associated resources are released, voicemail and any value-added services are stopped, and the SIM is no longer usable. On the commercial side, cease means the recurring charges stop, prorated to the correct date, and the final bill is prepared.

The final bill is where the money actually leaks. Recurring charges must be prorated to the port date and not to the end of the cycle, and if they were billed in advance the unused portion is a credit the customer is entitled to. Usage records will keep arriving after the cease, dated before it, because mediation is never instantaneous and roaming records are days behind. So the subscription must remain rateable after it is no longer serviceable — a state a great many systems handle badly — and the final bill has to wait a defined interval for late usage, or issue and be followed by a supplementary. Anything outstanding for equipment, early termination or an instalment plan is a separate debt with its own terms and does not disappear because the number left, and neither does a debt the customer owes, which you may pursue but generally may not use to block the port.

The number goes back to inventory, not straight back to the shelf

The number itself has an afterlife that people forget. Once ported, it is not yours to reissue: it is being served by another operator, and the routing data says so. Your inventory has to record that the number has gone, which is a different state from being free.

Numbers that are ceased rather than ported do come back to you, and reissuing them immediately is a well-known way to generate unhappiness. The previous holder's contacts, two-factor codes, bank notifications and delivery messages keep arriving at the number for months, and the new holder receives them. So the number goes into a quarantine period before reuse, and if a number was originally allocated from another operator's range and later ceased, it typically has to be returned to that range holder rather than kept. A number-inventory model that has only free and in-use cannot express any of this, which is why porting programmes so often begin with fixing it.

The failures worth naming out loud

Three patterns produce most porting incidents, and an interviewer will be listening for at least two of them.

The desynchronised cease, in both directions, described above. The remedy is confirmation-driven ceasing, a reconciliation between numbers marked ported in the industry data and subscriptions still active in your systems, run daily rather than monthly, and an alert on any number that appears in both.

The partial cease, where the commercial side stops and the network side does not, or the reverse. A subscription removed from billing but left in the subscriber data store is the classic silent case, since nothing complains and the resource stays allocated. The reconciliation that catches it compares active network subscriptions against billed subscriptions in both directions, and porting is one of the events most likely to produce a mismatch.

And the customer whose port succeeded but whose account was collaterally damaged: other lines suspended, direct debit cancelled leaving a final bill unpaid and heading for collections, or a credit sitting on a closed account that nobody refunds. The last of those is worth calling out because it is invisible to you and infuriating to them, and a closed account with money on it should be a queue somebody works.

Cease on confirmation, never on the calendar, and keep the subscription rateable after it stops being serviceable. Then reconcile ported numbers against active subscriptions daily, because both halves of that mismatch cost you and only one of them complains.