How number porting works: LOAs, FOC dates, and timelines

Number porting moves an existing phone number from one service provider to another without changing the number. The gaining provider submits an authorized request, the losing provider validates it against the customer record, both sides agree on a Firm Order Commitment (FOC) date, and the network routing for the number is changed during a coordinated cutover. The number itself does not travel anywhere: what changes is the set of records that tells telephone networks where calls for it should go.

That distinction explains both the process and most porting problems. A number can appear correctly in an account before the public telephone network routes to its new destination. It can also receive calls through the new provider while outbound caller identity or ancillary services still use stale data. A port is therefore not a file transfer. It is a controlled change across ordering, authorization, routing, and service-configuration systems.

What is actually being moved?

A public phone number is an address in a national numbering plan, commonly represented in E.164 format. The digits identify the destination callers dial, but they do not permanently encode the carrier currently serving that destination. Number portability adds an indirection layer: routing systems can look up the number and learn which network now owns responsibility for completing the call.

In ordinary business usage, the number may also be a DID assigned to an inbound route, queue, PBX, or SIP endpoint. Porting changes the carrier-level destination. The gaining provider must separately map the newly active number to the correct application-level destination. If that second mapping is missing, the carrier can own the number while calls still fail or reach a default route.

Four parties or systems commonly participate:

• The customer or authorized account holder approves the move.
• The gaining provider creates and manages the port request.
• The losing provider checks the request against its service records and releases the number.
• A portability administrator or routing database publishes the new serving-network association to participating networks.

The exact names, forms, and regulatory intervals vary by country and number type. Local, mobile, and toll-free numbers may use different administrators and workflows. The core sequence remains authorization, validation, commitment, activation, and verification.

The LOA: permission plus a data-matching document

A Letter of Authorization, or LOA, authorizes the gaining provider to request the port on the customer's behalf. Its second purpose is less obvious but equally important: it supplies identity and account data that can be compared with the losing provider's customer service record.

An LOA commonly identifies the account holder, service address, account number, billing telephone number, numbers being ported, and the person authorized to sign. Some services also require a transfer PIN or other account credential. The important engineering property is exact matching. Ordering systems often compare normalized fields, and a value that is commercially equivalent to a person may not be equivalent to the validation system. A business nickname, old address, missing suite, stale account name, or wrong billing number can cause a rejection.

The safest source for those fields is a recent bill plus the losing provider's customer service record, sometimes called a CSR. The bill proves what the customer sees; the CSR reflects what the port-validation system is likely to use. They are not always identical.

The LOA also defines scope. A request that ports every number associated with an account may disconnect services that share that account. A partial port may leave remaining numbers behind but still affect features attached to the billing number. Before submission, the gaining provider needs an explicit inventory of numbers, lines, hunt groups, alarm or fax dependencies, and any broadband service coupled to the voice account.

From submitted order to FOC

The gaining provider converts the customer request into the industry order used by the losing provider. In North American wireline workflows, that is often a Local Service Request, but terminology differs across networks. The order carries the requested numbers, account data, desired date, and indicators describing whether the port is simple or has dependencies.

The losing provider then validates two things:

1. Authority and identity: Does the submitted account information match the service record closely enough to release the number?
2. Order feasibility: Can the requested number set be separated cleanly, and is the requested activation window valid for the service involved?

If validation fails, the losing provider returns a rejection or clarification rather than an FOC. The gaining side must correct the data and resubmit. This is why repeated guesses at an account name or address can lengthen a timeline: every correction starts another validation cycle.

If validation succeeds, the order receives a Firm Order Commitment. Some provider interfaces label the same milestone Firm Order Confirmation. The FOC communicates that the losing side has accepted the order and committed to a cutover date or window. It is a scheduling agreement, not proof that the number has already moved.

An FOC should be treated as a change-control checkpoint. By that point, the new inbound route should exist, any SIP trunk or PBX destination should be reachable, emergency-calling configuration should be reviewed, and the team responsible for the old service should know not to cancel it prematurely. Canceling the old account before activation can turn a port into a restoration problem.

What happens on the port date

At activation, the gaining provider signals that it is ready to serve the number and the portability record is updated. In networks that use location routing numbers, a switch receiving a call performs or obtains a portability lookup. The result identifies the network responsible for the called number; the original dialed number remains available so the destination network can route it to the right subscriber.

This lookup is one step in the larger call path described in how a phone call works. A simplified inbound sequence is:

1. A caller's network receives the dialed number.
2. Routing logic checks whether portability data is needed.
3. The lookup returns the current serving network or a routing identifier for it.
4. Signaling is sent toward that network.
5. The gaining provider maps the called number to the customer's trunk, PBX, queue, or application.
6. The destination answers and the networks establish the media path.

Updates do not become visible to every cache and downstream system at exactly the same instant. During the transition, calls from one originating network may follow the new route while another still follows the old one. That is why testing from a single phone is weak evidence. A cutover test should originate calls from multiple networks and should verify both directions.

Outbound service has a separate path. The new provider must allow the number as an authorized calling identity, and originating networks may consult caller-name, attestation, or reputation systems distinct from inbound portability. A successful inbound port therefore does not prove that caller ID presentation is complete.

Why porting timelines vary

There is no useful universal number of days for a port. The elapsed time is a dependency graph, not just a carrier queue. The critical path usually includes:

• Record collection. The customer must obtain accurate account data and any required authorization credential.
• Validation cycles. A clean match can proceed; a mismatch creates a reject-correct-resubmit loop.
• Number-set complexity. A single standalone number is easier to separate than a range tied to hunt groups, shared billing arrangements, or other services.
• Provider and number type. Local, mobile, and toll-free ports can follow different systems and operating windows.
• Requested scheduling. The customer may choose a later date for staffing, a maintenance window, or contract reasons even when the order could move sooner.
• Freeze or account state. A port freeze, pending service order, disconnected account, or unpaid-account policy can require separate resolution.
• Regional holidays and operating hours. Manual work and repair escalation depend on the business calendars of every participating party.

The FOC date is consequently more reliable than an early estimate, but it still needs operational safeguards. It confirms the accepted schedule; it cannot guarantee that every dependent customer configuration or downstream cache is correct.

A low-risk cutover plan

Treat a port like a production migration. Separate preparation from activation and define evidence for success.

Before submission, inventory every number and attached service. Get the exact service record, decide whether the request is full or partial, and ensure the signer is authorized. Do not change account details or place unrelated orders while the port is being validated unless the providers coordinate them.

Before FOC, build the destination. Configure the number on the new platform, route it to a testable target, and validate the trunk or endpoint using a temporary number where possible. Document the expected call routing, including after-hours behavior, transfers, voicemail, and failure destinations.

After FOC, freeze risky configuration changes and publish a cutover runbook. Name contacts at the gaining provider, losing provider, and customer. Define the test matrix, the acceptable interruption, the rollback or forward-fix path, and who can approve escalation.

During activation, monitor the old and new destinations at the same time. Place inbound calls from several unrelated networks. Test outbound calling, caller identity, DTMF-driven menus, transfers, voicemail, and emergency-calling configuration as applicable. Record exact timestamps, originating numbers, and observed routes for failed tests; those details let carrier operations trace signaling.

After activation, keep the old service intact until the gaining provider confirms completion and the test matrix passes. Then verify billing and remove obsolete forwarding or temporary routes. Monitoring should continue long enough to catch stale routing sources that were not represented in the first tests.

Common failure patterns

The order is rejected immediately. This is usually a service-record mismatch, missing credential, unauthorized signer, or wrong number scope. Correct from authoritative records rather than repeatedly changing individual fields.

Only some numbers move. The submitted range may differ from the intended inventory, or the numbers may belong to different accounts or carriers. Reconcile each number individually.

Inbound calls work, but the application does not answer. Portability routing reached the gaining provider, but the number-to-destination mapping, trunk authentication, firewall, or application route is wrong.

Some callers reach the old destination. An originating network may have stale portability or routing data. Capture the caller's carrier, timestamp, and full dialed number so the providers can isolate the route.

Outbound calls show the wrong identity. Inbound ownership and outbound presentation are separate configurations. Confirm the number is approved on the originating service and that caller-name or attestation records have been updated where applicable.

FAQ

Does an LOA mean the port is approved?

No. The LOA authorizes the request and supplies customer data. Approval occurs only after the losing provider validates the submitted order and returns an accepted commitment such as an FOC.

Is the FOC date the moment every call switches?

It is the agreed activation date or window. The authoritative routing change happens around activation, but caches, downstream routing sources, and customer configurations may converge at different times. Verify from multiple networks.

Should the old service be canceled before porting?

No. Keep the number active with the losing provider until the port completes and testing passes. Early cancellation can remove the active service the port request depends on.

Can a number be ported without changing the phone system?

Yes. Carrier ownership and the customer's endpoint are separate layers. The gaining provider can route the ported number to an existing PBX, trunk, or application if the service and configuration support it.