Number Porting and E911 in Cloud Telephony: The Cutover Details That Decide Whether Your Genesys Cloud Migration Succeeds

A Genesys Cloud environment can be configured, tested and ready for users while the business’s phone numbers still route through its existing carrier. That gap can delay go-live even when the technical migration appears complete.

Number porting and emergency calling deserve their own workstream in any cloud telephony cutover. Port requests can be rejected over mismatched account details, while unverified emergency locations can create serious operational and compliance exposure. Both require early preparation and clear ownership.

1. Treat porting as a go-live gate

Genesys Cloud supports porting Direct Inward Dial (DID) and toll-free numbers between carriers in the United States and Canada. Genesys follows FCC local number portability standards, with a standard DID porting schedule of Monday through Friday, 8:00 a.m. to 7:00 p.m. Eastern Time.

Until the transfer is complete, the losing carrier may still control the numbers. In other words, a completed configuration is not the same as a completed cutover.

Port timelines depend on the size and complexity of the order:

• Simple ports: One number, no bundle or special features. Typically 1–2 business days if accurate information is submitted by 1:00 p.m. in the losing carrier’s local time and there are no rejections.

• Standard ports: One order of up to 100 numbers, with one BTN, address, losing carrier and rate center. Typically 7 business days.

• Project ports: Generally more than 100 numbers on one BTN, address and carrier. Handled manually and typically completed in 3–4 weeks.

• Complex ports: Multiple BTNs, addresses, rate centers or carriers. These cannot be guaranteed to complete at the same date and time and require account team consultation.

For planning, allow 2–3 weeks for DID submissions. A complex estate should not be treated as one cutover night: different groups of numbers may have different requirements and release dates.

Actionable takeaway: Build the port schedule around the number inventory and carrier release process, not just the date the new Genesys Cloud configuration is ready.

2. Audit records before submitting a port

Most avoidable delays start with differences between the port request and the losing carrier’s records. Required information typically includes a signed Letter of Authorization (LOA), the current service address, not simply the billing address, and the registered end-user name. Depending on the carrier, the order may also require an account number, password or PIN, a recent invoice, BTN, and a list of numbers remaining on the account.

Use this pre-flight checklist to catch common rejection causes:

• Confirm the name, service address, ZIP code and account number match the carrier’s records.

• Verify every number is active. Do not disconnect service with the current carrier; disconnected numbers cannot be ported.

• Ask the carrier to clear pending orders. Even a non-port change, such as an address or Calling Name update, may block the request.

• Confirm the BTN or ATN and whether the order is a partial or full port. Genesys assumes ports are partial by default.

• Check for an account freeze. Unfreezing can take 1–3 weeks.

• Deactivate distinctive ring and other special features that prevent porting.

• Compare the CSR (Customer Service Record) name and address with the LOA, and ensure the LOA signatory is authorized.

• Separate shared or bundled services before porting the affected numbers.

Actionable takeaway: Audit the carrier’s CSR against the LOA line by line, and resolve account changes or service dependencies before submitting the order.

3. Account for the different DID and toll-free processes

DID porting uses a 10-digit Location Routing Number (LRN) to route calls to the current carrier. Its eight-step sequence is: the gaining carrier notifies the losing carrier; subscriber details are validated; the losing carrier accepts or rejects the order; the gaining carrier notifies the Number Portability Administration Center (NPAC); a pending port is created; the losing carrier may concur; the port activates at the scheduled time; and the network receives the activation broadcast.

Toll-free numbers work differently. A Responsible Organization (RespOrg), registered with NANPA, controls a toll-free number’s routing. Porting changes the controlling RespOrg and routing information. Genesys does not submit toll-free requests to the losing carrier until two weeks before the requested port date.

That timing creates a distinct risk: some carriers place automatic disconnect orders as soon as five business days after accepting a toll-free release. A postponed port can therefore leave the number disconnected before its new activation date. Genesys requests no less than 10 business days before disconnect, but organizations should also confirm with the losing carrier that service will remain active.

Change requests need the same discipline. A DID order that has not been accepted can be cancelled at any time. Once accepted, cancellation requires at least two business days’ notice before the port date. Date changes require losing-carrier approval, and the new date must be at least three business days out. Requests made inside 48 hours of activation cannot be guaranteed.

Actionable takeaway: Track toll-free acceptance and disconnect timing separately from DID milestones. Keep existing service active until the transfer and routing are confirmed.

4. Make emergency calling part of the cutover

Emergency calling is not a configuration detail to leave until after launch. For Genesys Cloud Voice, Kari’s Law support enables direct 911 dialing without a prefix and automated 911 call notifications to designated contacts. Setup requires a security desk email address and the complete physical location address in Location Details.

Notification instructions are submitted to Genesys Cloud Voice support as a CSV. Organizations can choose a universal list for all locations or custom lists by location. Each location can have up to 100 notification addresses. An email distribution list can simplify updates when personnel change. Notifications are not supported for Canadian addresses; SMS notification is supported only for U.S. addresses.

Location-based routing directs emergency calls according to the caller’s geographic location. For Genesys-provided PSTN in the U.S. and Canada, dynamic E911 dispatchable location runs through RedSky. MyE911/RedSky portal data must reflect agent locations accurately; the organization remains responsible for maintaining that information. HELD protocol support lets phones retrieve location from an E911 provider’s Location Information Server (LIS).

Remote and hybrid work make location maintenance critical. A home address that is outdated is not merely an administrative error; it can mean the dispatchable location is wrong. Organizations using BYOC Cloud or BYOC Premises should confirm Kari’s Law and emergency-services implementation with their carrier.

Actionable takeaway: Map each site and user to a current physical address, confirm the emergency notification recipients, and verify notification paths for each site before go-live.

5. Run the cutover as a controlled sequence

A practical porting and E911 runbook reduces last-minute surprises:

• 30 days out: Freeze non-essential carrier changes. Inventory numbers, locations, users and carrier account dependencies.

• Before submission: Audit CSR data against the LOA; deactivate special features; clear pending orders; confirm the authorized signatory; and separate bundled services.

• During planning: Classify orders by port type. Submit with realistic lead time and schedule ports by cluster rather than all at once.

• Before go-live: Map every location and user to a current physical address. Configure emergency calling and test 911 notification paths per site, coordinating any testing with the appropriate support teams.

• During transition: Keep both environments live through the transition window. Maintain a documented rollback plan and clear decision-makers for holding or reversing a cutover.

This approach aligns port acceptance, activation timing and location readiness instead of treating them as separate tasks. For a broader migration perspective, see Dunamis Consulting’s cloud telephony migration guide.

Actionable takeaway: Assign one owner to the port schedule and one to emergency-location readiness, then make both workstreams explicit go-live checks.

6. Make the final go/no-go decision on operational readiness

A successful Genesys Cloud migration depends on more than a working platform. The numbers must be released and routing correctly; carrier records must be accurate; and emergency calls must use current location information with notifications configured for the right people.

Dunamis Consulting brings 15 years of cloud telephony experience to consultation, project scheduling, flexible staffing and managed services. If your organization is planning a Genesys Cloud cutover, contact Dunamis Consulting to review the porting and E911 workstreams and build a practical plan for your cloud communication solutions.

Actionable takeaway: Do not declare go-live readiness until number-port status, emergency locations, notification paths and rollback responsibilities have all been verified.