UCaaS Migration Guide: How to Move to Cloud Communications Without Downtime

Pre-migration: what to document before you start

• Full inventory of phone numbers: Every DID, toll-free number, fax line, and modem line. Include the carrier account name and account number for each — this information is required for LOA submission.
• Current call flows: Auto-attendant menus, IVR trees, ring groups, hunt groups, and time-of-day routing rules. Document in a flow diagram before attempting to recreate in the new platform.
• Hardware inventory: Physical phones, conference units, and ATAs (for fax/analog devices). Identify what is SIP-compatible and what needs replacement or adaptation.
• User directory: Extension assignments, voicemail settings, and speed dials. Export from the current system before migration.
• Integration dependencies: Any system that dials out via the PBX — alarm panels, door intercoms, elevator phones, fax machines. These require special handling and cannot be assumed to work with SIP without validation.

Number porting: the critical path

Number porting is almost always the critical path in a UCaaS migration timeline. Key steps and failure points:

• LOA (Letter of Authorization): Required to authorize the port. Must exactly match the carrier's billing account name and address — errors delay the port by days.
• FOC date (Firm Order Commitment): The confirmed port completion date from the losing carrier. Once set, do not change it unless unavoidable — rescheduling adds delay and can complicate multi-number port coordination.
• Pre-configure before FOC: All call flows, ring groups, and routing must be configured and tested before the FOC date. The port completes on schedule whether the new platform is ready or not.
• Port in stages: Port a small batch of non-critical numbers first to validate the process end-to-end. Port main business numbers last.

For the full porting process including LOA requirements, timeline expectations, and common failure modes, see the business phone number porting guide.

Network preparation

• Bandwidth assessment: Calculate required bandwidth for peak concurrent calls. One G.711 call requires approximately 90 kbps with overhead; G.729 approximately 32 kbps. Ensure sufficient headroom above your data traffic baseline.
• QoS configuration: Mark VoIP traffic (DSCP EF) for priority queuing on all network equipment between users and the internet edge. Without QoS, voice traffic competes with data traffic at peak times.
• Router: Disable SIP ALG; enable consistent NAT; verify SIP/RTP ports are open to the provider's SBC.
• Firewall rules: SIP (port 5060/5061) and RTP (typically 10000–20000 UDP) must pass to the provider SBC. Overly permissive rules create security exposure; overly restrictive rules cause connectivity failures.

For network quality requirements and testing methodology, see VoIP call quality.

The pilot phase

• Start with a small pilot group: IT team, internal support, or a non-customer-facing department. Not your main customer-facing lines.
• Test all call flows: Inbound, outbound, extension-to-extension, auto-attendant, voicemail, and fax — every call type the organization uses.
• Test from every location and device type: Office, remote, mobile, softphone, and hardware phone. Issues that only appear on specific combinations are common.
• Run parallel operation during pilot: Keep the legacy system active so pilot users can fall back if needed. This is the safety net that allows honest testing.
• Document all issues discovered in pilot before rolling out to the full organization. Pilot is your last opportunity to find and fix problems before they affect all users.

Cutover execution

• Schedule during lowest-call-volume window: Late Friday evening or early Sunday morning for business-hours operations.
• Maintain a rollback plan: Keep the legacy system able to receive calls for 24–48 hours post-cutover as a fallback if critical issues emerge.
• Coordinate port and cutover: The port should complete and the new system should be live at the same time. Avoid a gap where neither system receives calls reliably.
• Immediate post-cutover tests: Test every number, every call flow, and every ring group within 30 minutes of cutover completing.
• E911 registration: Update E911 records for all physical locations immediately post-port. Do not wait — E911 accuracy is a life-safety requirement.

User training and adoption

• Train before cutover, not after: Users who know the new softphone or device before go-live produce fewer Day 1 support tickets.
• Day-one support: Dedicate IT support capacity for the first full business day post-cutover.
• Quick reference guides: One-page guides for the most common actions — transfer, voicemail, hold, and conference. Most users need this, not the full manual.
• Admin training: Whoever manages the UCaaS admin console needs separate, deeper training before go-live — not the same session as end-user training.

Post-migration monitoring (first 30 days)

• Monitor call quality: Check MOS scores and jitter in the platform's reporting. Investigate any degradation immediately rather than waiting to see if it resolves.
• Track missed calls and voicemail delivery: Confirm routing is working as configured. Voicemail delivery failures are often silent until a caller complains.
• E911 verification: Test one E911 call per physical location within 30 days. Coordinate with the local PSAP before testing — do not place an unannounced emergency call.
• Usage anomaly monitoring: Watch for unexpected call volume spikes or routing failures that indicate misconfiguration not caught during pilot.

Frequently asked questions