What Is a Telecom Migration Cutover?

What happens during a cutover?

By the time a cutover starts, the destination platform should already hold the customer's users, devices, call flows and features. The cutover itself is about switching live traffic and confirming it works. A typical sequence includes:

1. Change freeze. Moves, adds and changes on the legacy platform pause for the customers in the wave.

2. Final sync. Changes made since provisioning are applied to the destination platform.

3. Go/no-go check. The team confirms validation results, open exceptions and readiness against agreed criteria.

4. Routing changes. Numbers and trunks are pointed at the new platform through carrier or SBC routing updates or, where required, a number port.

5. Device redirection. Phones and soft clients are redirected or reconfigured for the destination platform, and registration is confirmed.

6. Live testing. Inbound and outbound calls, voicemail, auto attendants and hunt groups are tested, along with emergency calling where permitted.

7. Post-cutover verification. Service is monitored until the wave meets its agreed exit criteria.

Exact steps depend on the source environment, third-party coordination and the agreed cutover plan.

Wave-based cutover vs. a single cutover

Many service providers move customers in planned waves, also called stages or migration groups, rather than all at once. A smaller group can help contain the impact of any issue and lets the team apply what it learns to the next wave.

A common pattern is a pilot wave of internal or friendly customers, followed by waves grouped by reseller, domain, size, feature complexity or device type.

What should a cutover plan include?

A cutover plan, often called a cutover runbook, sets out who does what, in what order, and what happens if something fails. For a telecom platform migration, it typically covers:

• Wave scope: which customers, numbers and devices move in each window

• Timing: maintenance windows chosen around each customer's calling patterns

• Owners: a named person for routing, devices, testing and customer communication

• Go/no-go criteria: the validation results and exception status required before switching

• Test script: the calls and features checked before a wave is signed off

• Rollback triggers and steps: the conditions that send traffic back to the legacy platform, and how

• Customer communication: what end customers are told, and when

• Exit criteria: what has to be true for the wave to be closed

Why do cutover problems often start earlier?

Many cutover issues trace back to work done before the window opens: a feature that did not map cleanly, a device on unsupported firmware, or a dial plan that looked right in configuration but routed incorrectly. That is why migration validation before cutover matters as much as the cutover itself. Our NetSapiens migration data validation checklist covers what to check before traffic moves.

Otto™, Vox Matic's proprietary automated telecom migration framework, automates repeatable extraction, transformation and provisioning work ahead of the cutover window. Automated validation checks help identify discrepancies for review before customers move, so the cutover can stay focused on switching and verifying live service. The objective is a carefully managed migration that minimizes service disruption and protects the end-user experience.