What it is
The Number Porting Checklist is a step-by-step guide to moving phone numbers from a losing carrier to a new call-center platform — the single highest-risk step of almost any migration. Porting is unforgiving: a botched port means dropped calls, dead DIDs, and in the worst case 911 routing failures, and unlike a misconfigured IVR you can’t just fix it after the fact, because the number may be stuck in limbo between carriers. This checklist walks through everything from gathering a clean Customer Service Record (CSR) to the night-of cutover, with a realistic timeline and the rejection reasons that cause the vast majority of port delays.
The checklist is organized around the porting lifecycle. It starts with how porting actually works, then the before-you-submit gathering and verification — pulling a recent bill (under 30 days old) from the losing carrier so the Letter of Authorization (LOA) matches it exactly, requesting a CSR to confirm the authoritative list of numbers, identifying the billing telephone number (BTN) that often must port last or with the group, and listing every DID, toll-free, and fax line because partial ports trigger account-level rejections. Then it covers LOA and port-request submission, the porting timeline by port type, cutover and validation, and the common rejection reasons.
The throughline is precision. The LOA name and service address must match the losing carrier’s CSR character-for-character — “Suite” versus “Ste,” “Street” versus “St” — because a mismatch causes an instant rejection. The account number and PIN must be correct. The FOC (Firm Order Commitment) date and a cutover window, ideally off-hours, must be confirmed in writing. Get these details right and the port is routine; get one wrong and the whole migration slips, which is exactly the failure mode this checklist is built to prevent.
What it's used for
Number porting is the part of a contact-center migration with the most ways to fail and the highest cost of failure — which is precisely why it deserves a checklist rather than improvisation. Teams use it to:
- ✓ Gather a clean, authoritative starting point — a recent losing-carrier bill (under 30 days old) and a CSR — so the LOA and port request are built on verified data rather than memory.
- ✓ Identify every number that must port — each DID, toll-free, and fax line — and the BTN, because partial ports of an account commonly trigger account-level rejections that block the whole order.
- ✓ Verify the authorized name, service address, account number, and PIN character-for-character against the CSR, since the smallest mismatch (Suite vs Ste) causes an instant rejection.
- ✓ Complete and submit the LOA and port request correctly, signed by an authorized contact, with the losing-carrier bill attached and a requested FOC date.
- ✓ Plan the cutover for an off-hours window with a confirmed FOC date and a written port-order number for tracking, so the switch happens when call volume is lowest.
- ✓ Validate after cutover that inbound calls route, outbound caller ID is correct, and — critically — 911/emergency routing is intact for every ported number.
- ✓ Anticipate and avoid the common rejection reasons — name/address mismatch, wrong account number or PIN, partial-port conflicts, pending orders or contract freezes — that cause roughly 90% of port delays.
Who uses it
Porting numbers is a coordinated effort between the team running the migration and the carriers on both ends. The roles that depend on this checklist include:
Context & good to know
Number porting is governed by carrier processes and telecom regulation, and it’s deliberately bureaucratic because a phone number is a piece of critical infrastructure — the system errs on the side of not letting numbers move incorrectly. The Letter of Authorization, the Customer Service Record, the Firm Order Commitment date, and the billing telephone number are all artifacts of that process. Understanding what each is and why the carriers insist on exact matches is the difference between a port that completes on the requested date and one that bounces through rejection after rejection.
The reason this is the highest-risk step in any contact-center migration is that porting is largely irreversible mid-flight and intolerant of error. A typo in the service address, a missing account PIN, an attempt to port some numbers off a shared account while leaving the BTN behind — any of these triggers a rejection, and each rejection adds days to the timeline. The checklist front-loads the verification precisely because catching a name mismatch before submission costs minutes, while catching it after a rejection costs days and can blow the entire go-live date.
When implementing a new platform — Talkdesk, Nextiva, CloudTalk, Five9, Genesys — the gaining carrier (often the platform itself or its underlying carrier) manages much of the mechanics, but the responsibility for clean, matching data and a sane cutover plan sits with the migrating organization. The most overlooked validation is 911/emergency routing: a port can succeed for normal inbound and outbound calls while emergency routing is misconfigured, which is a genuine safety hazard. The checklist makes emergency-routing validation an explicit cutover step, alongside confirming inbound routing and outbound caller ID, so go-live isn’t declared on incomplete testing.