Multi-Site VoIP Migration Plan for UK Businesses
Coordinate phone-number transfers, branch cutovers, shared call routes and supplier sign-off without treating every office as an isolated change.
Illustrative decision model, not a tested supplier migration or guaranteed porting sequence.
Quick answer: A successful multi-site VoIP migration depends on a common number and dependency register, named provider responsibilities, controlled cutover waves, branch-by-branch call tests and a contingency plan that respects the actual number-porting state. Do not release the next location until shared routing and safety evidence have been accepted.
Jump to a Section The plan
How to Plan a Multi-Site VoIP Migration Without Losing Control
A multi-site VoIP migration plan is a controlled programme for moving telephone services across multiple branches. It brings each branch’s numbers, critical devices, suppliers, shared routing and recovery arrangements into one schedule, then releases sites in waves only after the evidence for that wave is approved.
The central job is not to choose a handset or repeat a one-office migration checklist. It is to prevent one site’s change breaking calls at another: a main number might route across branches, one carrier may control shared SIP trunks, or an out-of-hours team may answer calls for the entire estate.
Give a programme lead authority over dependencies, communications and go/no-go decisions.
Require each site to confirm numbers, network, devices and user acceptance.
Obtain written gaining/losing-provider responsibilities, cutover states and escalation contacts.
Record what can be re-routed, what cannot simply be undone and who approves recovery.
Create One Register for Every Branch and Shared Service
Start with a single estate register, not separate email threads. Give each branch a stable site ID and a named person who can confirm what is installed. Record any shared numbers or central functions as separate entries, because these may affect several branches even when only one location changes.
| Record | Minimum evidence to capture | Owner / completion rule |
|---|---|---|
| Branch identity | Site ID, address, opening hours, local contact and business criticality | Local branch manager confirms the record. |
| Number ownership | Main number, DDIs, ranges, account holder and current provider reference | Carrier owner reconciles with bills and written inventory. |
| Call dependencies | Shared reception, overflow, queues, out-of-hours, branch-to-branch extensions | Telephony lead signs off a tested call-flow map. |
| Legacy devices | Alarm, lift, payment terminal, fax, door entry, telecare or other connected device | Competent third-party owner confirms replacement/test evidence. |
| Resilience | Access circuit, router, switch, Wi-Fi, power, alternate connection and user instructions | IT and voice provider agree minimum service/failover checks. |
| Change control | Wave, port reference, provider contact, gate status, fallback and approver | Programme lead refuses release if critical fields are missing. |
Swipe within the table to view all columns.
For device discovery at each premises, reuse the existing PSTN business readiness checklist rather than recreating the whole single-site audit. Keep the estate register focused on dependencies and approval status across sites.
Map What One Branch Change Could Break Elsewhere
A cutover wave should be based on dependency order, not geography alone. First identify the services whose configuration lives centrally: published main numbers, hunt or ring groups, out-of-hours divert rules, SIP capacity, customer contact-centre queues and disaster-recovery paths.
Show the original accessible call-dependency diagram
| Shared service | Potential failure if changed too early | Control and test |
|---|---|---|
| Published main number | External calls ring the wrong branch or reach a dead destination. | Name number owner; confirm intended answer point in each wave. |
| Central reception or queue | A site stops receiving transfers or overflow calls. | Trace all routing branches; test primary and secondary targets. |
| Common SIP trunk or SBC | Carrier or gateway change disrupts multiple sites. | Define shared-change window and full-estate rollback/contingency lead. |
| Out-of-hours cover | Closed branch fails to divert to the active duty team. | Test open, closed, holiday and failure-mode scenarios. |
| Shared Wi-Fi, LAN or identity | Phones authenticate or register differently across offices. | Validate local network, handsets/apps and assigned users per branch. |
Swipe within the table to view all columns.
Assign Clear Supplier and Business Responsibilities
Every cutover needs a named decision-maker, implementation lead, communication owner and verifier. Avoid ambiguous lines such as “IT/provider will manage” without saying which organisation performs the action and who accepts the outcome.
| Activity | R — Responsible | A — Accountable | C — Consulted | I — Informed |
|---|---|---|---|---|
| Wave release | Programme manager | Business sponsor | Branch lead; carrier | Affected sites |
| Number port coordination | Gaining provider case owner | Provider delivery owner for carrier task | Losing provider; programme manager | Business sponsor; local branch |
| Call routing changes | Telephony engineer / integrator | Contracted telephony service owner | Branch operations; carrier | Helpdesk; programme manager |
| Site network readiness | Local IT engineer | IT service owner | Network supplier; voice provider | Branch lead |
| Alarm or lift acceptance | Relevant equipment specialist | Site facilities / service owner | Monitoring centre; carrier as relevant | Programme manager |
| Business acceptance | Branch operations lead | Business sponsor | Telephony lead; specialist owners | Support desk; other branches |
Swipe within the table to view all columns.
Agree a single escalation bridge for each wave. Include the main provider, any separate SIP carrier, network operator, integrator and local branch owner, with a named deputy in case the primary contact is unavailable.
Control Number Porting Separately From PBX Configuration
Numbers are frequently the longest cross-company dependency. A handset can be configured ahead of time, but an external number’s live route depends on the relevant provider and porting process. Ask the gaining provider to state the required records, the validation steps, who contacts the losing provider, and the procedures if a port is rejected or delayed.
| Record | Why it matters | Release evidence |
|---|---|---|
| Number(s) / range | A shared range may affect services at multiple premises. | Complete inventory with account and location mapping. |
| Present service / owner | The current provider might differ from the PBX supplier. | Bill/service record and authorised account holder. |
| Gaining provider / order ref | Someone must track port acceptance and status. | Named case owner and written order acknowledgement. |
| Planned activation window | The date is a dependency, not a guaranteed universal SLA. | Provider-confirmed window and branch readiness. |
| Pre- and post-port routing | The number may require temporary forwarding or alternate destinations. | Approved routing diagram for each port state. |
| Rejection / delayed port | Cutover cannot rely on a date that the provider has not confirmed. | Delay decision, customer notice and rescheduling owner. |
Swipe within the table to view all columns.
See our dedicated UK business number porting guide for number-transfer fundamentals. The multi-site ledger focuses on the consequences for the whole estate.
Release Branches in Waves Using Evidence Gates
Choose a representative pilot where a failure can be contained, then group later sites by dependencies, complexity and service criticality. A wave is not complete because an installation engineer has left the building. It is complete when its agreed acceptance criteria have been met and the next wave has been explicitly released.
Named numbers, call flows, dependencies, devices, roles and agreed fallback.
Carrier confirmation, engineering contacts, approved window and realistic contingency.
Network, endpoint setup, emergency location records, user instructions and specialists ready.
Sponsor reviews exceptions, pilot lessons and evidence; go/no-go recorded.
| Evidence | Pass criterion | When blocked |
|---|---|---|
| Routing dependency map | Shared main numbers and inter-site transfers have assigned tested routes. | Do not move a dependent branch until the route owner approves. |
| Porting status | The required numbers have carrier-confirmed acceptance and a controlled plan. | Defer port-dependent actions; maintain supported existing service. |
| Emergency and resilience | Provider-specific 999/112/location/failure arrangements documented and tested by approved procedures. | Hold the wave; escalate safety and location evidence. |
| Critical third-party devices | Installer or specialist provides a signed migration/test position. | Exclude device from the wave only with documented continuity accepted. |
| Incident escalation | Named authority can halt the work; suppliers can be reached during the window. | Reschedule instead of relying on informal availability. |
Swipe within the table to view all columns.
For a UK programme nearing the PSTN withdrawal, keep unresolved waves visible to the sponsor; do not treat Openreach’s last-resort safeguards as a substitute for a completed migration plan.
Use a Wave-by-Wave Cutover Runbook
A runbook should say what to check, who records the result and who can stop the change. The table below is an operational model to tailor with your provider. It is not a promise about an actual deployment window.
| Stage | Action / evidence | Halt or escalation trigger |
|---|---|---|
| Before release | Freeze routing config, export inventories, confirm carrier order, publish contacts and capture pre-change call evidence. | Missing number approval, unresolved shared-service dependency or no agreed fallback. |
| Supplier change window | Record exact start, ports/routing activity and carrier tickets in a shared incident log. | Provider status differs from approved plan or shared services change unexpectedly. |
| Business calling validation | Call main numbers and DDIs externally; test outbound display and transfers across open and closed branches. | Critical call path fails or calls reach the wrong destination. |
| Safety and connected devices | Confirm provider’s 999/112/location checks using its approved method; obtain specialist sign-off for non-voice devices. | Unresolved emergency/location or third-party alarm dependency. |
| Go/no-go | Programme manager presents evidence and exceptions to the named authority. | Unresolved P1 issue or an unowned exception. |
| Observation and closure | Observe agreed traffic and queues; record communications, handover and old-service termination dependencies. | Unexpected failure after go-live or unresolved shared-service event. |
Swipe within the table to view all columns.
Prove Customer Journeys Across the Whole Estate
Accept a migration by testing the calls people and customers actually make, not merely by checking dial tone. Include at least one path that starts outside the business and crosses branch boundaries. Write down the expected destination, result, owner, evidence and whether the test passed.
| Scenario | Expected observable result | Record / owner |
|---|---|---|
| External call to branch DDI | Correct branch, team or configured user answers. | Source number, destination, outcome, branch tester. |
| Main switchboard/central queue | Customer can reach intended teams across sites. | Primary and overflow tests with telephony lead. |
| Inter-site transfer | Answering team transfers to another office without losing the call. | Origin/target, transfer type and result. |
| Out-of-hours routing | Call reaches designated duty cover when branch is shut. | Time setting, target destination and test log. |
| Outbound presentation | External callee sees approved caller ID, where supported. | Branch, dialled destination, displayed number. |
| Loss-of-connectivity scenario | Documented alternate answer route behaves as promised. | Carrier/PBX owner and safe approved simulation. |
| Emergency call arrangements | Provider confirms correct location records and approved evidence by site. | Recorded service/provider attestation; authorised test only. |
| Alarm/lift/payment dependency | Appropriate specialist signs off connected-device functionality. | Installer’s documented result and escalation contact. |
Swipe within the table to view all columns.
When an issue affects several branches, do not close the wave after testing only the pilot site. Require an explicit retest at every dependent branch or shared service.
Keep Emergency Calling and Analogue Devices in Their Own Risk Tracks
Digital voice depends on premises power and connectivity unless suitable alternative arrangements are in place. Ofcom’s General Conditions impose obligations on regulated communications providers for emergency-call access and, where technically feasible, reliable caller location information. A business programme must still verify the real arrangement at each operating location, including shared numbers and remote users.
For the detailed UK obligations, follow our VoIP emergency calls 999/112 guide and the Ofcom emergency access compliance statement. Do not assume that providing a UPS or listing a mobile phone automatically satisfies a provider’s obligations.
Review each site address, nomadic workers and how location is conveyed/maintained for the actual service.
Document whether phones, router, access circuits and local network have the resilience needed for the agreed service.
Obtain specialist checks for signalling paths, monitoring contracts and fail-safe behaviour.
Confirm supplier support for digital operation; voice handset success is not evidence that data devices work.
For alarm signalling and specialist dependencies, use the dedicated PSTN alarm systems guide. Keep specialist sign-off as an independent gate even when branch voice tests pass.
Know What Can Be Reversed — and What Requires Provider Escalation
“Rollback” is often used too loosely. Write a contingency plan for each possible state, and agree it with the providers before a port or service cutover. If the carrier has already moved the number, the same steps used to undo a PBX rule may not restore the former service.
| Actual state | Practical response to arrange in advance | Decision owner |
|---|---|---|
| Port not started | Pause the planned carrier move and retain working legacy service where supported. | Programme lead and both carriers. |
| Port accepted, activation pending | Escalate or reschedule through gaining provider; keep internal configuration consistent with the confirmed state. | Gaining provider coordinates carrier status. |
| Port complete; PBX route broken | Use provider-supported re-routing/alternate answering if configured and confirmed. | PBX/SIP owner, business sign-off. |
| Port complete; carrier-side fault | Open provider incident, apply agreed continuity route and communicate known limitations. | Carrier incident manager and sponsor. |
| Site broadband/power failure | Invoke validated branch or cross-site answer route; confirm emergency arrangements per contract. | Local IT, communications provider and branch lead. |
Swipe within the table to view all columns.
Set severity triggers in advance: loss of main published number, failed 999/112 arrangements or failure affecting other branches should trigger an immediate hold and the relevant escalation plan, not a routine helpdesk ticket.
Three-Branch Example: A Delayed Port Without a Failed Programme
Illustrative scenario, not a real deployment: A business has three offices—North (central reception), East (sales), and West (out-of-hours cover). The organisation intends to move to one managed phone platform but has separate legacy accounts and shared published numbers.
| Branch | Original wave role | Specific programme constraint |
|---|---|---|
| North — reception | Pilot for central routing and call reporting | Main number answers here and overflows to West. |
| East — sales | Wave 2 after pilot acceptance | Uses a local DDI but receives transfers from North. |
| West — duty cover | Final wave after shared-route validation | Answers out-of-hours calls for North and East. |
Swipe within the table to view all columns.
What changes: East’s gaining provider reports that its port is not accepted for the planned date. The programme lead does not assume an instant carrier reversal or proceed with the East number cutover. East’s legacy service remains in its confirmed supported state, its deployment is rescheduled with the supplier, and the team retests North-to-East transfers and the West out-of-hours route before deciding whether West can proceed independently.
Why this is a multi-site control decision: the issue is not merely an East engineer delay. It affects shared switchboard routing, customer notices, supplier schedules and the next wave’s acceptance evidence. The programme register records the rejected dependency and the executive go/no-go decision.
Close Each Site Only After Ownership and Evidence Are Recorded
Separate technically live from formally accepted. Site closure means that the business has an owner for daily support, the current call journey is documented, critical issues are resolved or formally accepted, and a responsible person knows when legacy services can safely be cancelled.
| Evidence / record | Completion requirement |
|---|---|
| As-built dial plan and DDI list | Matches live call flows and approved owners. |
| Supplier / incident contact sheet | Includes normal hours, out-of-hours escalation and responsibilities. |
| Test evidence | Contains accepted customer-journey, shared-routing and provider-specific emergency checks. |
| Specialist sign-off | Covers alarms, lift equipment, terminals or other dependent technology where relevant. |
| Exceptions register | Names action owner, impact, target resolution and business acceptance. |
| Legacy service cancellation approval | Confirms port status and that no third-party device or dependent service still needs the old line. |
| User and branch communication | Explains changes to numbers, transfers, voicemail and outage reporting. |
Swipe within the table to view all columns.
The general PSTN migration guide covers the standard switchover process. Keep this handover pack focused on evidence shared between the branch, programme office and providers.
Plan Against the 31 January 2027 PSTN Closure
As of the latest Openreach update on 24 September 2026, the date for the closure of the analogue PSTN remains 31 January 2027. Openreach has described temporary last-resort safeguards for some connections, but they are not a replacement for arranging a supported digital communications service.
For multi-site organisations, prioritise locations with alarms, lifts, older voice connectivity and known carrier dependencies so that provider coordination and specialist testing can occur before the deadline. Where a site has particular service or user requirements, seek confirmation from the relevant communications provider rather than assuming one migration pattern will fit every premises.
Programme-Level Go/No-Go Checklist
Use these as approval prompts—not proof that a migration has been technically tested. Enter the supporting evidence, approver and outcome in your actual change-management record.
For an interactive working assessment, continue to the VoIP Migration Planner. The tool is the appropriate place to develop your operational readiness record; this article explains how those records fit across multiple offices.
Multi-Site VoIP Migration Questions
Does every branch need to migrate on the same day?
No. A phased programme often reduces the number of simultaneous changes, but shared numbers, central queues and carrier arrangements may force particular sites or functions to move together. Base the grouping on an approved dependency map.
Can an office keep its existing UK telephone number?
Porting may be available, but it depends on the number, current and gaining providers, account details and the agreed process. Confirm eligible numbers and written port orders; do not assume a requested date is guaranteed.
Who is responsible if a number port is delayed?
Record the gaining provider’s case owner, losing-provider responsibilities and the business escalation contact. Where routing and PBX support are separate contracts, identify who maintains working customer call paths while the issue is resolved.
Can a completed port be rolled back immediately?
Do not assume so. PBX routing changes can sometimes be reverted quickly, but reversing a carrier-level number transfer requires provider processes and may not be immediate. Agree alternate answering and escalation before go-live.
What happens if one branch loses power or broadband?
Invoke the service-specific continuity design that has been confirmed with the communications provider. That may include validated alternate call destinations, resilient connectivity or backup power, but capability and limitations vary. Assess emergency-call arrangements separately.
Can we migrate an alarm or lift telephone as part of an ordinary VoIP cutover?
Only after the relevant alarm, lift or equipment specialist confirms the supported replacement path and acceptance testing. A successful desk-phone call does not demonstrate those systems are safe or supported.
What should a branch manager sign off?
At minimum, the local user call journey, published numbers, transfers, opening-hours routing, contact information, operational exceptions and escalation arrangements. Specialists or providers must sign off technical obligations within their remit.
Is this page a replacement for the existing PSTN migration guide?
No. That guide owns the general switch-over process; the multi-site systems guide owns architecture and platform fit; this plan deals with estate-wide dependencies, change waves, accountable owners and programme approval.
Official Sources and Scope Notes
This guide uses official public evidence for PSTN and emergency calling and provides illustrative operating templates, not a claim of onsite tests, carrier quotations or completed business deployments. Validate any supplier-specific terms against the actual contracted service before scheduling change.
- Openreach: PSTN closure and temporary safeguards (24 September 2026)
- Openreach: Switch your business phone line to digital
- Ofcom: obligations for access to 999/112 and caller location (updated June 2026)
- Ofcom: rules for providers, including emergency access in power cuts
- Ofcom: General Conditions protecting business customers, including switching
- UK Government: Non-voluntary telecoms migration checklist (specific provider-led context)
Editorial research reviewed: 22 October 2026. UK service eligibility, porting procedures and equipment support depend on suppliers and may change.
Multi-Site Migration Readiness Brief
Turn the Branch Plan Into Verified Migration Evidence
Agree the estate-wide dependencies, branch owners, supplier responsibilities and acceptance rules before moving live numbers. Then use the existing planner to structure the readiness checks.
Bhav Giva
Founder & Lead Analyst at CompareVoIPService.co.ukBhav Giva publishes UK-focused business communications research and practical VoIP guidance. This guide provides an evidence-led multi-site migration planning framework, with fictional examples and official-source references. It does not claim first-hand supplier deployments, live porting tests or certified emergency-call commissioning.