You can provision ten thousand cloud seats in an afternoon. You can map out complex IVR call flows, test the SIP trunks, and distribute headsets across twelve offices. None of it matters if the legacy carrier refuses to release your main support number because the service address on the port request says “Street” instead of “St.”
A telephony cutover is usually scheduled for a weekend. The engineers test the routing, the project managers watch the clock, and everyone waits for a database update they cannot see or control. The cutover plan is a list of things the project team controls. The port is not on that list. It is a manual paperwork exchange between a winning carrier and a losing carrier that has no financial incentive to make your departure easy.
A port request is a legal assertion that you control the number. The losing carrier is the judge. They run a literal string-matching exercise against their master record. If the corporate suffix is missing, or the address formatting is off by one character, the port rejects automatically.
Your internal IT asset database is irrelevant for a port. The monthly telecom invoice your accounts payable department receives does not contain the required formatting. The only record of truth is the Customer Service Record, or its regional equivalent, which you must request directly from the losing carrier. Getting this record often takes weeks because the losing carrier deprioritizes requests from departing customers. When it arrives, you will likely find that the authorized contact on the account is a telecom director who left the company six years ago, and the service address is a building that was demolished in 2011.
You must match the legacy carrier’s records exactly, character for character, even if their record contains a typo. If you submit a request with the company’s current legal name, and the losing carrier’s account still uses the name of a business acquired in a merger a decade earlier, the numbers will not move. The numbers work perfectly. The request does not pass validation.
This is where the 2:40 a.m. war room comes into existence. A five-thousand-number batch rejects at midnight. The port window is assigned by the losing carrier’s scheduling system, which might give you a four-hour slot on a Sunday morning. When the batch fails, the old PBX is still scheduled for decommission at 6 a.m. Someone has to decide whether to delay the decommission or let the rejected numbers go dark. Both options are bad. A rejected port on cutover night is not a technical problem. It is a customer-facing outage with a ticket number.
The inventory spreadsheet tells you what the business believes it owns. A port request tests what the current provider has on record. The gap between the two is where migrations fail. A single analog line for an elevator emergency phone might sit on a separate account and be entirely missing from the inventory. A number forwarded to a call center for years might fail to port because the underlying line was disconnected long ago, even though the forwarding kept working. It exists in routing tables but not in the carrier’s billing system.
Attempting to port part of a circuit introduces its own risks. The plan might be to port fifty DIDs off a PRI to SIP. The first fifty port cleanly. The fifty-first port causes the losing carrier’s provisioning system to tear down the entire circuit, killing the remaining unported numbers. The contract allowed partial ports, but the losing carrier’s system disagreed.
Toll-free numbers and short codes operate on entirely different workstreams. Local numbers map to physical geography and move between carrier databases. Toll-free numbers route through national or regional registries and follow distinct regulatory paths. They require separate letters of authorization and operate on different timelines. Organizations frequently discover their most critical inbound sales number is technically controlled by a third-party marketing agency that registered it on their behalf years ago. During a cutover, the local numbers might port successfully while the regional toll-free numbers drop to a fast busy signal because the centralized registry still points to the legacy carrier’s routing tables, which have already been torn down.
Emergency services databases and caller ID name databases update on their own schedules after the port completes. There is a window, sometimes lasting hours or days, where calls to emergency services from a ported number route to the wrong location, and outbound calls show the wrong name.
The only way to manage this risk is to decouple the port from the platform migration. Do not port numbers and migrate platforms on the same night.
Start data collection months in advance. Request the raw account data from the losing carrier and fix mismatches on their side before submitting a port request. Port in waves. Start with numbers that do not matter—fax lines, conference bridge DIDs, test numbers—to learn the losing carrier’s rejection patterns. A single field mismatch can account for hundreds of rejections. Track the rejection codes.
Keep the legacy infrastructure alive, powered, and funded. Do not cancel the legacy carrier contract or unplug the old session border controllers until a full billing cycle has passed since the final port. Hold back final payment to the losing carrier until the ports are complete. It is the only leverage you have.
Fallback must be executable, not just a line in a runbook. The standard fallback mechanism for a risky port is not porting the number at all on cutover night. Instead, provision temporary DIDs on the new platform. On cutover night, instruct the legacy carrier to forward all traffic from the permanent numbers to the temporary numbers. This decouples the platform migration from the number porting process. The actual port happens weeks later, during business hours, once the new platform is proven stable.
Ensure the person with the authority to request that forwarding from the old carrier is actually on the cutover bridge. A bridge full of engineers cannot resolve an account authorization problem. Test the fallback with real calls from outside your network. Internal test calls do not prove anything about external routing.
The old route is part of the migration plan until the new route has been proved from outside the company. The difference between a successful migration and a Monday morning outage is whether the fallback route was still live when the port failed.