Legacy PBX to IP Migration: Designing the Cutover Batches

Legacy PBX to IP Migration: Designing the Cutover Batches

Migration projects fail in a characteristic way. The technology works, the configuration converts, and a large proportion of the organisation moves on the same weekend because moving everyone at once feels simpler. It is not simpler. It concentrates every unknown into a single window, removes any possibility of learning from the first attempt, and leaves the business with one large recovery problem instead of several small ones. The alternative is to treat migration as a series of small, reversible batches, each of which produces information that makes the next one better. The design question is not how to cut over; it is where to draw the lines between batches and what has to be true before each one starts.

What Defines a Batch

A batch is a group of users, a site, or a functional area that moves together. Good batches share operational characteristics: similar working hours, similar device requirements, similar call patterns, and a manageable number of simultaneous changes. A batch that mixes a busy retail floor with a back office combines a low-tolerance environment with a high-tolerance one, and the batch will be scheduled to suit the back office.

Size matters less than reversibility. A batch of any size is acceptable if it can be reversed within an acceptable time, and unacceptable if it cannot, regardless of how small it is. The practical limit is therefore the time it takes to restore the previous state, and that is a question to answer before the batch is designed rather than during it.

Sequencing Principles

Order the batches so that each one teaches you something useful. The first batch should be small enough that failure is cheap and large enough to exercise every part of the process: provisioning, device delivery, user training, call routing, and support. Subsequent batches should increase in complexity only after the previous batch has run long enough to reveal its problems.

Two ordering rules are worth stating explicitly. Migrate internal teams before external-facing teams, so that the people answering support questions are already confident in the new system. And leave a genuinely representative batch until reasonably late, because the estate is never as uniform as the configuration export suggests.

Dual-Running and Coexistence

During a phased migration both systems are live, and the coexistence period is where most complexity appears. Numbers exist on one system or the other, not both, which means routing decisions must be explicit. Every number in scope needs an owner and a cutover date, and a list of numbers nobody claimed is the single most common cause of a stalled migration.

• Produce a definitive number inventory early, reconciled against both the old system and the carrier records
• Assign every number, route, and device in scope to a batch with a named owner and a date
• Track a list of unassigned items explicitly, as an item requiring a decision rather than an omission
• Decide the direction of trunk cutover per batch, and confirm the carrier schedule supports that sequence
• Define what users experience during the crossover day, including any period with deliberately limited service
• Plan the physical layer: cabling, ports, power, and switch capacity for each batch before devices are delivered
• Agree how exceptions are handled, such as specialist devices or non-standard locations, before the first batch moves

Per-Batch Readiness Criteria

Each batch should have a short readiness checklist completed before it starts. The point is to discover the batch-specific items while there is still time to fix them, rather than discovering them during the cutover window. Readiness criteria are deliberately concrete and testable.

A ready batch has confirmed network readiness, including switch port capacity, VLAN assignment, power, and quality of service treatment for voice traffic. It has confirmed device readiness, with the correct handsets provisioned and configured before the day. It has confirmed user readiness, meaning the users in the batch know what is happening and have had their handsets touched before the cutover if that is possible. It has confirmed number readiness, with every number in the batch verified. And it has confirmed support readiness, with a named contact and a fallback.

The Cutover Window Itself

The window should be a written procedure, executed the same way each time, with the steps recorded as they are completed. Consistency is what makes the third batch faster than the first, and it is also what makes a problem recognisable. If each batch is handled differently by a different engineer, there is no accumulated learning and the project stalls at roughly the same difficulty throughout.

Sequence the steps so that reversible actions come before irreversible ones. Configure and test new routing before removing old routing. Test the new path before migrating user numbers. Migrate before decommissioning. Each of these orderings gives you a working fallback that most teams give up too early.

Cutover Day Communication

Users care about three things on cutover day: what will not work, what they should do if it does not, and who to tell. Answer all three before the day rather than during it. A short note that names the affected people, states the expected experience, gives a contact, and says when normal service resumes prevents a large share of the support calls that migration projects generate through uncertainty alone.

Be explicit about expected limitations. If recording will be temporarily unavailable, if voicemail greetings will not carry over, if a particular feature will behave differently, say so in advance. Discovering a limitation during the cutover window converts a planned change into an incident in the perception of the people affected.

After Each Batch

Each batch should close with a short review before the next one starts. The review should record what took longer than planned, what was confusing, what support contacts received, and what would be changed. Applying those changes is the mechanism that makes migration a phased process rather than a repeated identical exercise. Without it, every batch costs roughly the same and the project does not get easier over time.

Redstone Approach

Redstone supports legacy PBX to IP migration projects. Our engineers can survey an existing system, help design batch boundaries and sequencing, assist with trunk and number transition planning on Redstone REX IP-PBX and RGW gateway deployments, support cutover windows, and provide post-batch review that captures what should change. We work with organisations at different points on a migration, including those still evaluating approaches, and we are comfortable working alongside an existing integrator or internal team. Migration scope, risk, and resourcing are agreed in writing before any work starts.