Telecom Migration Capacity Planning

Most telecom migration challenges begin long before the first subscriber is moved. Capacity planning—not the migration platform itself, is often what determines whether a program stays on schedule or falls behind.

Not because of the platform. Not because of the team. Because nobody sized the program for the actual subscriber base.

Waves get too large, exception work stacks up, and by mid-program the team is fighting fires instead of moving subscribers. The timeline that looked reasonable on paper is gone.

The fix is a capacity plan built before the contract is signed—one that ties automation coverage to wave size, staffing, and a timeline that actually holds.

Summary

• Wave size should be set by automation coverage, not by guesswork.

• A realistic plan separates standard subscribers from complex ones early.

• Exception handling and escalation design must be staffed before the first cutover.

• For providers moving off legacy platforms, planning before the contract is signed saves time, cost, and rework.

  
  

Three questions need answers before the first subscriber moves: How many subscribers can move per wave without quality slipping? What does that require in staffing and automation? Where are the data and exception risks hiding?

Providers who work through these early finish on schedule. Teams that skip this planning often encounter avoidable bottlenecks several waves into the program.

Automation Is the Variable That Changes Everything

A migration wave is a group of subscribers moved together in a single cutover window. Provisioning, validation, number porting, and configuration transfer all happen within it.

Wave size depends on one variable more than any other: how much of the repeatable work your platform handles automatically. Manual migration caps wave size by engineering bandwidth. Automation raises that ceiling by reducing the engineering effort required for repeatable work.

Automation Coverage	Subscribers Per Wave
Under 50%	20 to 40
50 to 80%	50 to 150
80%+	200+ with a lean team

Make the platform decision and the capacity plan together, since each influences the other.

Automation coverage sets wave size. Wave size drives staffing and cost.

Capacity Planning Timelines by Subscriber Volume

Subscriber count is a starting point. The following examples illustrate potential planning ranges, though actual timelines depend on automation levels, subscriber complexity, data quality, and available resources.

200 Subscribers: 8 to 12 Weeks

The risk at this scale is not volume. It is data quality and configuration variability.

A two-week discovery phase and a pilot wave of 10 to 20 subscribers will surface most issues before they reach the full base.

Teams that skip the pilot phase often encounter issues later in the program that could have been identified earlier.

2,000 Subscribers: 20 to 26 Weeks

Complexity segmentation becomes critical here.

Treating all subscribers identically creates bottlenecks. Separate standard subscribers from complex ones early and resource each tier differently.

Program management becomes a distinct function at this scale—not a shared responsibility.

10,000 Subscribers: 40 to 52 Weeks

This is a 12 month initiative requiring executive sponsorship and formal governance.

A 2% exception rate is 200 subscribers requiring manual intervention.

Exception handling is not an edge case. It is a parallel workstream that must be staffed independently from the main wave team.

Four Factors That Shape Migration Capacity and Timelines

Subscriber count is not the primary driver of program duration.

These four variables are:

Data quality. Legacy platforms collect years of inconsistencies. A data audit before planning is not optional—what it surfaces often reshapes the timeline before a single wave is sized.

Complexity distribution. A base that is 80% standard subscribers moves very differently from one that is 40% complex. Segment early and resource each tier accordingly.

Automation coverage. The most controllable variable in the plan, and the one most providers underinvest in. Higher automation means larger waves, a shorter program, and lower cost per migrated subscriber. Otto, Vox Matic's proprietary migration framework, is built to raise that coverage rate across every wave.

Escalation design. Decide who resolves exceptions, what triggers a rollback, and who can authorize a cutover extension before the first production wave. Decisions made under pressure rarely go well. A clear cutover protocol is the difference between a managed delay and a subscriber-impacting failure.

Organizations with successful migration programs typically define these variables before execution begins

The Mistakes That Turn a Good Program Into a Difficult One

Programs that go over budget and over schedule usually share one cause: capacity planning happened after the contract was signed.

Three mistakes come up repeatedly:

• Skipping the pilot wave. A 10 to 20 subscriber pilot is not a delay. It is insurance against finding a systemic data issue on wave six.

• Treating complexity as uniform. A base with mixed tiers needs tiered resourcing. One-size-fits-all wave design breaks down fast.

• Underestimating exception volume. At scale, even a 1% exception rate creates a real manual workload. Plan for it from day one.

  
  

While timelines and resource requirements vary by subscriber volume, the core planning principles remain the same.

Capacity Planning Starts Before the Migration Begins

Capacity planning is not a box to check. It is the work.

Get it right and the program runs on schedule, on budget, without disrupting the subscribers you are trying to retain. Get it wrong and you spend the back half recovering.

Start the conversation before vendor selection, not after. If you are moving from Metaswitch or BroadWorks, the migration planning considerations are worth reading before the first wave is sized.

When you are ready to map your subscriber base to a program plan, talk to our migration team.

It’s that simple!