Author: John

A business opens a second office, then a third. Each one arrived with its own phone line, its own handsets and its own way of answering. Head office has a receptionist; the Leeds branch rings every desk at once; the warehouse number goes to an answerphone after 5pm. A customer who calls the wrong site is given another number to try. Nobody can say how many calls were missed last week, and adding a new starter means three phone calls to three suppliers.

That is the situation a multi-site phone system is meant to resolve. This guide is about the planning decisions behind it: which numbers to keep, who answers, how calls move between locations, who makes changes, and what happens when one site’s internet goes down. Cisco Webex Calling is the platform used to illustrate the answers, but most of the decisions apply whichever cloud phone system you choose, and they are worth settling before you speak to any supplier.

What is a multi-site phone system?

A multi-site phone system is one business phone service that covers two or more locations, so that calls, numbers, extensions and call handling are coordinated across the organisation rather than managed site by site.

The contrast is with the arrangement most growing businesses drift into: several locations, each operating a disconnected telephone system. Separate lines, separate contracts, separate voicemail, and no way to transfer a caller from one office to another except by reading out a number.

With a coordinated cloud phone system, the service runs in the provider’s data centres rather than in a cupboard at each site. Every location connects to the same system over its internet connection, so staff in different offices can dial each other by extension, transfer calls between sites and appear on the same company directory. Administrators see all locations in one place.

It is worth being precise about what “one system” does and does not mean:

• It does not mean one public phone number. Each site can keep its own numbers, subject to porting, and callers need not notice any change.
• It does not mean identical settings everywhere. Each location can have its own opening hours, greetings, routing and even its own way of connecting to the public telephone network.
• It does not mean every manager gets full administrative control. Access can be scoped, and many businesses prefer the provider to make most changes.
• It does mean one directory, one set of rules for how calls flow between sites, one place to report on calls, and one supplier relationship.

Where Webex Calling fits. Cisco Webex Calling is a cloud phone system in which each physical site is set up as a location within the business’s account. Cisco’s documentation describes locations as the way to organise users and shared devices by physical address; each user and each shared workspace belongs to exactly one location, and calling features and settings are applied at that level. That structure maps naturally onto a business with a head office, branches and remote staff, which is why it is a sensible basis for the decisions that follow.

Keep local numbers or use one main number?

This is usually the first question a multi-site business asks, and the answer is rarely all-or-nothing.

Separate local numbers for each branch. Customers who have always rung the Bristol office keep ringing the Bristol number, and calls land with the Bristol team. Local identity is preserved, which matters for businesses whose customers choose them partly because they are nearby: trades, estate agents, surgeries, regional depots. The trade-off is that each branch needs its own answering arrangement, and a caller who rings the wrong site needs to be transferred rather than told to redial.

One main number with a menu or reception team. All advertised contact goes through a single number, answered centrally or by an automated menu (“press 1 for Bristol, 2 for Leeds”). This gives a consistent experience and makes staffing easier, because one team covers everything. The trade-off is weaker local identity, and a longer route for a customer who simply wants the person they spoke to last week.

A combination. In practice most multi-site SMEs land here. Branch numbers stay live for existing customers and local marketing, while a central number is used for new enquiries, head-office functions and out-of-hours cover. Calls to any number can be routed anywhere, so the public-facing numbers and the people who answer them no longer need to be in the same building.

Two practical points shape the decision.

First, transferring between sites becomes a normal action rather than a workaround. With all locations on one cloud phone system, a receptionist in one office can transfer a caller to a colleague in another office, or to a remote worker, by extension or by name from the directory. That alone removes most of the “let me give you another number” moments.

Second, keeping existing numbers depends on porting. Number porting is the process of moving a phone number from one provider to another. Most UK geographic numbers can be ported, but eligibility depends on the current provider, the type of line and the contract it sits on. Treat retention as something to confirm number by number with your provider, with a plan for the porting dates, rather than an assumption. A business that has acquired another company, or that has numbers spread across several legacy suppliers, should list every number early because this is where surprises tend to surface.

Centralised, local or shared reception?

Once calls can be routed anywhere, who answers them becomes a design choice rather than a consequence of where the phone line enters the building.

Model	When it may suit	Main trade-off
Centralised answering	A small reception or admin team at head office can comfortably handle call volume for all sites; a consistent first impression matters more than local familiarity; branches are small or often unstaffed at the front desk.	Central staff need good knowledge of every site and reliable ways to transfer. Local callers may feel they are talking to “head office” rather than their branch.
Branch-based answering	Each location has staff available to answer, local knowledge matters (directions, stock, local contacts) and customers value speaking to the branch directly.	Quality depends on each site’s staffing. Lunch breaks, sickness and busy periods create gaps unless an overflow is designed in.
Shared or overflow answering	Branches answer first, but unanswered or out-of-hours calls roll to another site, a central team or a remote worker. Suits businesses with uneven staffing across sites or long opening hours.	Needs clear rules about who picks up what, and the overflow team must be able to help rather than just take a message. More routing to maintain.

The third model is often the practical answer, because it keeps local identity while making sure the phone is answered when the local team cannot. Designing it means thinking about:

• Opening hours. Which sites open when, and where calls should go outside those hours. A branch that closes at 5pm can route to head office until 6pm and to voicemail after that.
• Holidays and closures. Bank holidays, Christmas shutdowns and local closures such as a stock-take day, and who is responsible for switching the routing.
• Busy periods. Monday mornings in a service business, month-end in accounts, campaign launches. Overflow after a set number of rings or a set wait time protects the caller’s experience without adding permanent headcount.
• Staff availability. Whether the people in an answering group are at desks, on the shop floor or moving between sites, and whether they answer on a handset, the app or a mobile.

Three building blocks make these designs work, and it helps to know their names. An auto attendant is a recorded menu that greets callers and routes them by key press. A hunt group rings a defined set of people, in sequence or all at once, until someone answers. A call queue holds callers in line with announcements until a member of the group is free. In Webex Calling, these are configured against the relevant location, so a Leeds hunt group and a Bristol hunt group can behave differently while living in the same system. Which of them you need, and how they chain together, is the substance of a reception design; the full feature list is a separate subject.

How should calls move between locations?

The internal side of a multi-site phone system is less visible to customers but matters just as much to staff. Five decisions cover most of it.

A clear extension-numbering plan. Every user and shared phone gets an internal extension. Decide the length once, for the whole organisation (Cisco’s dial-plan documentation allows 2 to 10 digits, with 4 as the default), and allocate ranges by site or by department so that numbers are easy to remember: 1xxx for head office, 2xxx for the first branch, and so on. Changing extension length later is possible but disruptive, so it is worth getting right before the first site goes live.

Transferring to another branch or department. Because every location is on one system, a transfer to a colleague in another office is the same action as a transfer to the next desk: by extension, or by searching the directory in the app. Decide whether transfers should be announced (the transferring person speaks to the colleague first) or blind, and make that the house style, because it shapes the caller’s experience more than any setting does.

Duplicate extensions and location prefixes. If two sites have both used extension 200 for reception for years, you have a choice. Either renumber one of them, or keep both and use a location prefix. Webex Calling supports a routing prefix per location: Cisco’s documentation states that where multiple locations share the same extension, users dial the location prefix followed by the extension to reach the other site. Each location’s prefix must be unique, and the prefix length is set organisation-wide. Renumbering is cleaner for a small number of sites; prefixes become more useful as the site count grows or when an acquired business arrives with an established extension plan.

Branch-specific opening hours and overflow. Each location can have its own schedule, so the Leeds auto attendant can switch to an out-of-hours greeting at 5.30pm while head office stays open until 6pm. The overflow destination is a separate decision for each site: another branch, a central team, a named person’s mobile app, or voicemail. Write these rules down as a simple table before anyone configures anything, because this is where most “why did that call go there?” questions come from later.

Remote staff in the wider arrangement. A home-based account manager or a field engineer belongs to a location for administrative purposes but works from the Webex App on a laptop or mobile. They can be a member of a hunt group or queue just like an office-based colleague, which means a thin branch can be backed up by people who are not in the building. The design question is whether remote staff should be in the first ring group or only in the overflow, and whether their presence status in the app should be relied on to show availability.

None of this requires a technical manual to decide. It requires someone who knows how the business actually works to answer the questions above; the configuration follows from the answers.

Who manages the system?

A single system raises a question that separate systems never did: who is allowed to change what?

There are three sensible answers, and most businesses use a mix.

• Central administration. An office manager or IT manager at head office makes changes for all sites. Consistent, but it can become a bottleneck if every branch greeting goes through one person.
• Local responsibility. A nominated person at each branch handles routine local changes. Faster, but it needs training and clear limits, so that a well-meaning branch manager cannot accidentally reroute head office.
• Provider-managed changes. Changes are requested from the provider, who makes them. Lowest effort and lowest risk for the business; the trade-off is that the business depends on the provider’s responsiveness and the terms of the support arrangement.

Three everyday examples show how the choice plays out:

1. Adding a starter at a branch: creating the user, assigning a licence, an extension and a device, and adding them to the right hunt group. Often central or provider-managed, because it touches licensing.
2. Updating a branch greeting for a local promotion or a change of staff: a candidate for local responsibility, if the right person has access to that location only.
3. Changing holiday opening hours across all sites before Christmas: central, with a checklist, because a missed site means callers hearing the wrong message for a week.

Webex Calling’s administration portal, Control Hub, is where all of this happens. Cisco’s documentation describes applying settings and administrative features to groups and locations, and the platform supports administrator roles with different scopes. Whether your organisation holds full administrator access, scoped access for named people, or requests changes through Fidelity, is a matter of the service you agree, not something that comes automatically with the licences. Fidelity’s Webex page describes role-based admin access and a consultative approach to how each business is set up; the right split of responsibilities is one of the things to settle in that conversation, alongside what is included in ongoing support.

What happens if one location loses connectivity?

This is the question that worries operations directors most, and it deserves a clear answer rather than reassurance. It helps to separate four things that are easy to run together.

The cloud service itself. Webex Calling runs in Cisco’s cloud, not at your sites. A broadband fault in Leeds does not switch off the phone system; the other locations carry on, and the Leeds numbers still exist and can still be routed.

The affected site reaching it. Desk phones and apps in the affected building depend on that building’s internet connection. If it is down, those devices cannot register with the service, so they will not ring. A backup connection, such as a second broadband line or a 4G/5G router, is a separate arrangement to specify and pay for, not a default.

Calls reaching somewhere else. Because routing lives in the cloud, calls to the Leeds numbers can be sent to another site, a central team or named individuals. Staff with the Webex App on a mobile can continue to make and receive calls over mobile data, where coverage allows. Whether this rerouting happens automatically, requires an administrator to switch a pre-built “site down” rule, or needs a request to the provider, is a design decision. Make it deliberately, and make sure someone knows how to trigger it at 8.30 on a Monday morning.

Separately configured survivability. Cisco offers survivability options that allow certain calling functions to continue locally during a loss of cloud connectivity. Fidelity’s Webex page refers to survivability options for multi-site organisations. These are additional components with their own design and cost; they are not included with a standard calling licence and are not needed by every business. If a site cannot tolerate any interruption, raise it specifically.

Continuity is therefore a plan, not a feature. Decide which sites matter most, what the fallback is for each, who triggers it, and then test it in a quiet period rather than discovering the gaps during an outage.

One further item to confirm with your provider is emergency calling. In the UK, calls to 999 and 112 from a cloud phone system depend on the service holding accurate location information for each site and each user, and on the arrangements the provider has in place for when a site’s connectivity fails. Keep registered addresses current as staff move between sites or work from home, and ask how the service handles it rather than assuming. Detailed broadband and resilience specifications are outside this guide; Fidelity’s business phone systems page is the starting point for the connectivity conversation.

An illustrative three-site example

The following is a hypothetical design, not a Fidelity customer story, and it makes no claims about results. It shows how the decisions above fit together for a 75-person business with a head office and two branches.

The business keeps all three local numbers. Head office also advertises a national number for new enquiries. Each branch answers its own calls first, with head office as overflow. Head office’s own overflow is a small group of experienced staff who work partly from home.

Location	Preferred incoming-call arrangement	Overflow destination	Who manages local changes
Head office (40 staff)	Local number and national enquiry number answered by a two-person reception team via a call queue; auto attendant out of hours.	After 20 seconds, a hunt group of three account managers (two remote, on the app). After hours, voicemail with email notification.	Office manager holds scoped admin access for all locations; licensing and new users requested through the provider.
Northern branch (20 staff)	Local number rings a branch hunt group of four front-desk staff simultaneously.	Unanswered after 15 seconds, or outside branch hours (8.30am to 5pm), to the head-office reception queue.	Branch manager can update the branch greeting and holiday hours only; everything else via head office.
Southern depot (15 staff)	Local number answered by a shared-area phone on the trade counter, with a second shared phone in the warehouse.	Unanswered after 15 seconds to the depot manager’s mobile app, then to head-office reception.	Depot manager has no admin access; changes go through head office.

Internally, all three sites use four-digit extensions in distinct ranges (1xxx, 2xxx, 3xxx), so no prefixes are needed and any member of staff can transfer a caller to any other site by extension or by name. If the Northern branch’s broadband fails, its number is already configured to overflow to head office, so callers are answered; the branch team use the mobile app for outbound calls until the connection returns. Whether that overflow needs a manual switch or happens on the existing timer is something the business would decide and test.

Planning the next location

One of the quieter benefits of a coordinated system is that a fourth site becomes an addition to an existing design rather than a new project. Even so, each new location should be reviewed on five points before it goes live:

• Users and shared workspaces. Who is based there, who needs a personal extension and app, and which areas need a shared phone (reception, meeting room, warehouse, kitchen).
• Numbers and extension ranges. Whether the site brings existing numbers to port, needs new ones, and which extension range it takes in the organisation-wide plan.
• Reception and opening-hours rules. Which answering model applies, the opening schedule, and the overflow destination in both directions (does the new site also back anyone else up?).
• Devices, connectivity and emergency-calling information. Handsets or apps, the quality of the site’s internet connection, any backup, and the registered address for emergency calls.
• Permissions, training and responsibility. Who can change what at the new site, and a short induction for staff on transferring and the app.

A note of realism for businesses growing by acquisition: an acquired company arrives with its own contracts, numbers, possibly a different phone platform and sometimes a separate Microsoft or Webex tenant. These can usually be brought onto the same system, but not always instantly. Contract end dates, porting lead times and any tenant consolidation set the pace, which is why a phased approach, site by site, is normal. Fidelity’s practical guide to moving a business phone system to VoIP covers how a phased migration is run.

A practical planning checklist

Before speaking to a supplier about a multi-site phone system, gather the following. It turns a vague “we need to sort out the phones” into a brief a provider can respond to properly.

• Sites: every location, its address, headcount and whether it has a front desk.
• Numbers: every number the business owns, which provider holds it, and which contract it sits on.
• Peak incoming calls: roughly when and where calls peak, and how often they go unanswered today.
• Reception model: centralised, local or shared, and who would be in each answering group.
• Operating hours: per site, including seasonal or holiday variations, and who changes them.
• Remote users: who works away from a site and whether they should answer customer calls.
• Existing contracts: end dates and notice periods for current phone, line and broadband services at each site.
• Connectivity: the type and reliability of each site’s internet connection, and whether any site has a backup.
• Continuity requirements: which sites cannot tolerate an outage, and what an acceptable fallback looks like.
• Growth plans: sites or acquisitions expected in the next one to two years.

Frequently asked questions

Can each branch keep its local phone number?

Usually, through number porting, but it must be confirmed for each number with the provider. Eligibility depends on the current supplier, line type and contract, and porting needs to be scheduled around the cut-over for each site.

Can two locations share responsibility for answering calls?

Yes. Hunt groups and call queues can include staff from different locations and remote workers, and one site can be set as the overflow for another. The design work is deciding the order and the timing, not whether it is possible.

Can different offices have different opening hours?

Yes. Each location can have its own schedule, greetings and out-of-hours routing within the same system, which is one of the main reasons to treat sites as separate locations rather than one block.

Can we introduce the system one location at a time?

Yes, and a phased roll-out is the usual approach. The sequence is typically set by contract end dates, porting lead times and which site’s current arrangement causes the most problems. Calls can be routed between the new system and sites that have not yet moved during the transition.

Can an acquired business join the same system?

Generally, yes, but the timing depends on its existing contracts, numbers and platform, and on whether any separate tenant needs consolidating. Treat it as its own phase with its own review rather than assuming it can be absorbed on day one.

Fidelity Group’s role and the next step

The decisions in this guide are not technical ones, but they do benefit from someone who has seen how they play out across many businesses. Fidelity Group works with UK organisations on this basis: starting with how the business operates, its sites, its numbers and its call-handling requirements, and then designing the Webex Calling set-up around that, rather than fitting the business to a standard template. Fidelity’s Webex page describes this consultative approach, phased roll-outs and ongoing administration through one accountable partner.

If your business operates from two or more locations and the phones have grown up site by site, the useful first step is a structured look at what you have and what you want it to do. Book a multi-site phone system review with Fidelity to work through your sites, numbers and reception model, or read more about Cisco Webex Calling from Fidelity Group.

Sources referenced in this article

• Cisco, Locations in Control Hub (updated 5 June 2026)
• Cisco, Configure your Webex Calling dial plan (updated 22 April 2026)

Businesses replace their phone systems for practical reasons: the existing system has become costly to maintain, the company has outgrown it, staff now work from more than one location, or the current provider is no longer meeting expectations. Some are planning ahead of the wider industry move away from legacy copper-based services. Whatever the trigger, moving a business phone system to VoIP, hosted telephony or a cloud phone system is a project, not a product swap.

A successful VoIP migration starts with assessment and planning. Before any platform is chosen, the business needs a clear picture of its numbers, users, call flows, connectivity and contract position. Number porting, network readiness, call routing, testing and staff training all need consideration, and the right approach depends heavily on what is in place today.

This guide is written for businesses in Oxfordshire, Buckinghamshire and across the UK that are reviewing their phone system. It does not assume which system you use now, and it does not pretend every migration looks the same.

If you are reviewing your current business phone system, Fidelity Group can help you assess your requirements and identify the right migration approach.

Why replace an existing business phone system?

Most businesses do not replace a phone system for its own sake. Reviews usually start when one or more of the following becomes a problem:

• Maintenance cost or difficulty. An ageing on-premise system may depend on spare parts, specialist engineers or a support contract that is becoming harder to justify.
• Growth. Adding users, lines or a new site may be slow or expensive on the current system.
• Location flexibility. Staff may need to make and receive business calls from home, from client sites or from a second office.
• Limited call routing. The business may want queues, auto-attendant menus, time-of-day rules or overflow routing that the current system handles poorly or not at all.
• Reporting. Sales and customer-service leaders often want visibility of answered, missed and abandoned calls that older systems cannot provide.
• Integration. The current system may not connect to the CRM, helpdesk or Microsoft 365 environment the business relies on.
• Provider support. Slow responses, unclear billing or a lack of proactive advice are common reasons for switching provider even where the technology still works.
• Premises changes. Opening, closing or consolidating offices is a natural point to reconsider telephony.
• Legacy services approaching replacement. If the business still relies on analogue lines or ISDN, the provider may already have set out a migration plan as part of the wider transition to digital services.
• Future fit. The current system may simply not support where the business is heading over the next few years.

None of this means every legacy system is poor, or that VoIP is automatically cheaper. A well-maintained on-premise system can serve a business for years. The question is whether it still fits how the business works now and how it expects to work next.

Is VoIP suitable for every business?

VoIP suits a very wide range of organisations, but suitability should be assessed rather than assumed. A professional review before any platform or supplier is selected should cover:

• Size and user count. A five-person office and a 200-seat multi-site organisation have different needs, but both can usually be served by a hosted phone system with the right design.
• Locations. Multiple sites, home workers and field staff all affect the design and the connectivity needed at each location.
• Call volumes. High inbound volumes, particularly in sales or customer-service teams, place greater demands on queuing, reporting and network capacity.
• Internet and network suitability. VoIP depends on a stable IP connection and a well-configured internal network, not just a fast headline broadband speed.
• Mobile and remote working. If the business needs the same number and features on mobiles and laptops, this should shape the platform choice.
• Regulatory and emergency-calling considerations. Businesses should understand how emergency calls are handled from a VoIP service, including what happens during a power or internet outage, and any location-information requirements. Where specific rules apply, current Ofcom guidance and the provider’s own terms should be checked.
• Existing hardware. Some desk phones and headsets may be reusable; many will not be. This needs checking against the chosen platform.
• Integration requirements. CRM, Microsoft Teams and other software integrations vary by platform and licence tier.
• Budget and contract commitments. Existing contract end dates, notice periods and early-termination terms can affect timing as much as technology does.
• Resilience. Businesses that cannot afford to lose inbound calls may need backup connectivity, automatic call forwarding or both.

Step 1 – Audit your existing phone system

Before requesting proposals, document what you have today. A provider can only design a reliable migration if the starting point is accurate. The following pre-migration audit checklist is a good starting point:

Numbers – Main business numbers – Direct-dial (DDI) numbers for individuals and departments – Geographic numbers (for example, an 01865 Oxford or 01494 High Wycombe number) – Non-geographic numbers (03, 08 and similar ranges) – Any numbers used for fax, alarms or card terminals

Users and structure – Number of users, including part-time and shift staff – Number of sites and which users work at each – Departments and teams – Mobile users and remote workers

Call handling – Hunt groups – Call queues – Auto-attendant menus – Opening-hours rules and out-of-hours routing – Voicemail boxes and who monitors them – Call recording, including retention requirements – Call reporting currently used

Equipment and software – Existing handsets (make, model and quantity) – Headsets – Softphones already in use – CRM or software integrations – Emergency calling arrangements

Connected services – Alarm lines, lift lines, door-entry systems, payment terminals, franking machines or other devices that may use telephone connectivity

Commercial – Contract end date and notice period – Current support arrangements and response times

The connected-services point deserves emphasis. Devices such as lift alarms, intruder alarms and older payment terminals sometimes rely on an analogue line. These may need separate investigation, and possibly separate solutions, before the line is migrated or ceased.

Step 2 – Define your requirements

With the audit complete, translate it into requirements. This is the document that lets you compare proposals on a like-for-like basis. Cover:

• Number of users now and projected growth over the contract term
• Number of locations, including home workers
• Desk phone requirements by role
• Mobile app requirements
• Desktop softphone requirements
• Reception needs, including transfer and presence visibility
• Call queues for sales or customer-service teams
• Call recording, including which teams and how long recordings are kept
• Call reporting and who needs access to it
• CRM integration
• Microsoft Teams integration
• Multi-site working, such as internal dialling and cross-site overflow
• Out-of-hours routing
• Business continuity and failover expectations
• Admin permissions: who can change call flows and add users
• Training required for users, reception and administrators
• Support hours and escalation routes
• Compliance requirements relevant to your sector

Example requirement statement (illustrative only, not a recommendation):

We need a phone system for 20 users across two sites, with a main reception number, sales and service queues, mobile access, call recording for selected teams and the ability to add users as the business grows.

A statement like this gives a provider enough to propose a design. It also makes it obvious when a proposal has ignored something you asked for.

Step 3 – Assess broadband and network readiness

VoIP runs over an IP network, but call quality depends on far more than the headline download speed. A broadband speed test alone is not a VoIP readiness assessment. A provider should review:

• Download and upload performance, including at busy times
• Latency, jitter and packet loss on the connection
• The number of concurrent calls the business expects at peak
• Wi-Fi coverage and performance where softphones or wireless handsets will be used
• Wired network quality, including cabling and switch capacity
• Switches and power, including Power over Ethernet for desk phones
• Router and firewall configuration, including how voice traffic is prioritised
• Other business-critical traffic sharing the connection, such as cloud backups or video calls
• Backup connectivity, for example a secondary broadband line or a 4G/5G fallback
• Power resilience, since IP phones and routers stop working during a power cut unless protected

Bandwidth requirements are often quoted as a single figure, but the actual requirement depends on the codec used, the platform, the number of simultaneous calls and the other traffic on the network. The supplier should assess the specific environment rather than apply a generic threshold. A business may need to improve its connectivity or internal network before introducing VoIP, but this cannot be determined accurately without assessing the specific environment. Where a provider supplies both connectivity and telephony, both can be assessed together. Fidelity Group provides business broadband and connectivity alongside hosted telephony, so the voice service and the network it runs on can be reviewed as one requirement.

Step 4 – Choose the right VoIP model

“VoIP” covers several different deployment models. None is universally right; the choice should follow the requirements.

Hosted VoIP / hosted telephony. The phone system runs in the provider’s cloud and users connect over the internet with desk phones, apps or softphones. Suits small and mid-sized businesses, multi-site organisations and hybrid teams that want features without on-site equipment. Ask what is included per user, how call flows are administered, and what happens if the site’s connection fails.

Cloud PBX. Often used interchangeably with hosted telephony, though some providers use “cloud PBX” to describe a more configurable platform aimed at organisations with complex routing. Ask about admin controls, reporting depth and how multi-site routing is handled.

SIP trunking with an existing or new phone system. The business keeps (or buys) an on-premise or virtualised PBX and connects it to the public network over SIP trunks instead of ISDN or analogue lines. May suit organisations with a recent PBX investment or specific on-site requirements. Ask whether the PBX is SIP-compatible, how many concurrent channels are needed, and who supports the PBX itself.

Microsoft Teams telephony. Calling is added to Microsoft Teams so users make and receive external calls from the Teams client. Options generally include the vendor’s own calling plans, Operator Connect, or Direct Routing through a certified session border controller and a provider’s SIP trunks. Suits organisations already standardised on Teams, but licensing, call-centre depth and reception functionality vary. Ask which model is proposed and why, and how queues, recording and reporting will be delivered.

Mobile and desktop softphone solutions. Some businesses need very few desk phones and can operate mainly on apps. Ask how mobile users are reached when out of signal or data, and how presence and transfers work across devices.

Contact-centre platforms. Sales and customer-service teams with high volumes may need skills-based routing, wallboards, detailed reporting and quality management beyond a standard phone system. Ask whether this is a separate platform or a tier of the same one, and how the two interact.

Feature availability depends on the selected platform, configuration, supplier and commercial package. Do not assume a feature is included because it appears in a brochure; ask for it to be confirmed in writing against your requirements.

Step 5 – Plan business number porting

Number porting is the process of transferring your existing telephone numbers from your current provider to the new one, so callers continue to use the numbers they know. For most businesses, keeping the existing number is non-negotiable, which makes porting one of the highest-risk parts of a migration.

Key points:

• Eligibility must be confirmed. Not every number can be ported to every provider. Eligibility depends on the number range, the location, the service the number currently sits on and the arrangements between the losing and gaining providers. A provider should check each number before committing to a plan.
• Geographic numbers. Standard area-code numbers can often be ported, but the process depends on how they are currently delivered and whether they are single numbers, multi-line groups or DDI ranges.
• Non-geographic numbers. 03 and 08 numbers follow different processes and may sit with a different provider from your main lines.
• Direct-dial numbers. DDI ranges need to be listed accurately; a missing or mis-typed number in a range can cause a port to be rejected.
• Lead times. Porting has lead times that vary by number type and provider. Complex or multi-line ports generally take longer than single-line ports. A provider should give a realistic window rather than a promise.
• Data accuracy. The port request must match the losing provider’s records exactly, including the installation address, account holder and account number. Errors are a common cause of delay.
• Existing contract and billing. Check whether your current contract has a minimum term, and understand how billing overlaps during the port window.
• Temporary forwarding. Ask how calls will be handled if there is a gap between the new system going live and the port completing.
• Failure or delay planning. Agree in advance what happens if a port is rejected or delayed, and who owns the fix.

⚠️ Do not cancel your existing business phone service until your new provider has confirmed the porting plan, cutover date and fallback arrangements. Cancelling a line before the port completes can result in the number being lost.

Step 6 – Design your future call flows

Migration is a good moment to improve how calls are handled, rather than simply copying the old setup. Map out:

• Main number: what callers hear first
• Reception: whether calls are answered by a person, an auto-attendant or a combination
• Department options: which menu choices exist and where each leads
• Sales and customer-service queues: who is in each, how calls are distributed and what callers hear while waiting
• Hunt groups: for teams that need ring-all or sequential ringing
• Voicemail: which numbers have it and who is notified
• Out-of-hours messages and where calls go outside opening hours
• Holiday closures: how bank holidays and company shutdowns are handled
• Overflow routing: what happens when nobody answers within a set time
• Mobile users: whether mobiles ring simultaneously, sequentially or only when selected
• Multi-site routing: whether sites cover each other and how internal calls are dialled
• Emergency or priority contacts: routes for urgent callers or key accounts
• Call recording notifications, where recording is used and an announcement is required

Example:

A call to the main number might be answered by a welcome message, offered department options during opening hours, routed to an overflow destination after a defined period and sent to an out-of-hours message when the office is closed.

The precise capabilities available depend on the chosen system. Document the call flows as diagrams or tables so they can be tested line by line before cutover.

Step 7 – Decide on handsets, apps and accessories

The right device depends on the role, not on a blanket policy. Options generally include:

• Desk phones, from basic models to executive handsets with colour screens and busy-lamp fields
• Desktop softphones running on laptops and PCs
• Mobile VoIP apps that present the business number from a personal or company mobile
• Headsets, wired or wireless, for high-volume users
• Reception consoles or expansion modules for handling multiple calls and transfers
• Conference devices for meeting rooms
• Teams-compatible devices, where Teams telephony is part of the design

Example by role:

• Reception may need a desk phone or console with presence visibility.
• A sales team may prefer headsets and softphones.
• Field staff may need a mobile app.
• A meeting room may need a dedicated conference device.

Do not assume existing handsets are compatible with the new platform. Some can be re-provisioned; others cannot, or can only be reused with reduced functionality. Compatibility must be checked with the selected platform and supplier before the commercial proposal is finalised.

Step 8 – Test the system before cutover

Testing should involve representative users from each team and real working scenarios, not just a technician placing one test call. Use a testing checklist along these lines:

• Inbound calls to every ported and new number
• Outbound calls to landlines, mobiles and international numbers where relevant
• Caller ID presentation on outbound calls
• Number presentation for different teams or sites
• Internal transfers between users and sites
• Blind and attended transfers
• Call queues, including wait messages and agent distribution
• Hunt groups
• Auto-attendant menus, including every option and invalid-input handling
• Voicemail deposit, retrieval and notifications
• Call recording, including where recordings are stored and who can access them
• Call reporting output
• Mobile apps on the devices staff actually use
• Desktop softphones, including headsets
• CRM integration, such as screen-pop and click-to-dial
• Microsoft Teams integration, if relevant
• Out-of-hours rules
• Holiday routing
• Overflow routing
• Multi-site calls
• Audio quality under normal and peak load
• Failover or forwarding during a simulated connection loss
• Emergency-calling arrangements
• User permissions and admin access

Record the results. Any failed test should be resolved or formally accepted as a known issue before the cutover date is confirmed.

Step 9- Prepare employees and stakeholders

User adoption is part of the migration, not an optional afterthought. A technically perfect system that reception cannot operate on day one will still feel like a failed project. Plan for:

• User training on the basics: answering, holding, transferring and voicemail
• Reception training on consoles, presence and transfer etiquette
• Sales and customer-service workflows, including queue behaviour and wrap-up
• Admin training so someone in the business can change call flows and add users
• Call-recording responsibilities, including who can retrieve recordings and how retention is managed
• Mobile app setup on staff devices ahead of cutover
• Voicemail greetings and PINs
• Call transfers between sites and to mobiles
• Reporting: who receives it and what they should act on
• Support contacts: how users raise a problem and to whom
• Internal communication explaining what changes, when and why
• Cutover-day responsibilities so every team knows who is checking what

Short written guides or a one-page quick reference often do more than a single training session, especially for staff who were absent on the day.

Step 10 – Plan the cutover and fallback

The cutover plan is the document that turns preparation into a controlled go-live. It should record:

• Date and time of cutover
• Technical owner at the provider
• Supplier contact and escalation route for the day
• Internal business owner with authority to make decisions
• Porting status for every number
• User readiness, including devices issued and apps installed
• Call-flow confirmation against the design
• Device delivery and configuration status
• Testing results and any accepted known issues
• Communication plan for staff and, where appropriate, customers
• Fallback arrangements if the new service has a problem
• Temporary forwarding in place during any porting gap
• Escalation process if something goes wrong
• Post-cutover checks in the hours and days after go-live

There is no universally correct time to cut over. The best timing depends on business hours, call volume, porting requirements and the supplier’s process. A business with a quiet Friday afternoon may choose differently from one whose busiest period is the end of the week.

How long does a VoIP migration take?

There is no universal timeframe for a business phone system migration. Factors that affect it include the number of users and sites, number-porting requirements, the existing contract, platform complexity, hardware requirements, network changes, CRM or Microsoft Teams integration, call-flow complexity, training and supplier availability. Porting and any regulatory requirements can set the pace regardless of how quickly the rest of the project moves.

The stages, however, are broadly consistent:

Stage	Main activity
Discovery	Review the existing system, numbers, users and locations
Requirements	Confirm features, integrations and working patterns
Design	Build the proposed system and call flows
Preparation	Configure users, devices, apps and network
Testing	Validate calling, routing, integrations and resilience
Cutover	Move live services and confirm number arrangements
Optimisation	Review user feedback, call reports and outstanding issues

Ask any prospective provider to walk you through these stages for your specific project and to say which ones they expect to take longest, and why.

Common business phone system migration mistakes

• Selecting a provider only because of a low monthly price
• Failing to document existing numbers, particularly DDI ranges
• Not checking number-porting eligibility before signing
• Cancelling the old service too early
• Ignoring broadband, Wi-Fi or internal networking
• Assuming all existing handsets will work
• Forgetting out-of-hours call routing
• Not testing the auto-attendant from a caller’s perspective
• Not checking caller ID on outbound calls
• Failing to train reception and customer-service users
• Not planning fallback arrangements
• Not confirming what support looks like after cutover
• Forgetting alarm, lift, payment or other services that use telephone lines
• Not checking contract notice periods with the current provider
• Treating the project as a licence change rather than a business-process change

VoIP migration for businesses in Oxfordshire and Buckinghamshire

Businesses in Oxfordshire and Buckinghamshire may have different requirements depending on their premises, connectivity, workforce and existing phone system. A company in Oxford with a hybrid team may need a different approach from a multi-site organisation operating across High Wycombe, Aylesbury or Milton Keynes.

Connectivity is a good example. A business park on the edge of Bicester or Didcot may have full-fibre options that a rural premises near Thame, Witney or Henley-on-Thames does not, which affects whether backup connectivity should be part of the design. A professional-services firm in Abingdon or Marlow may prioritise call recording and Teams integration, while a distribution business in Banbury may care most about mobile apps for staff who are rarely at a desk. An organisation in Beaconsfield with staff who commute into London may need the same number to work in the office, at home and on the train.

Local relevance in a VoIP provider should mean something concrete:

• Understanding the service area and the connectivity typically available across it
• Being clear about which activities are handled remotely and which, if any, are carried out on site
• Assessing each customer’s actual location and network rather than assuming
• Supporting multi-site organisations whose offices span both counties or extend beyond them
• Providing accurate contact and service information so you know exactly who to call

Fidelity Group serves businesses across Oxfordshire, Buckinghamshire and the wider UK.  Based in Henley on Thames, Fidelity Group offer onsite scoping, demonstrations and installations with 1-2-1 training to ensure a smooth transition takes place to your new VoIP services

Questions to ask a VoIP migration provider

Put these to every provider you shortlist, including Fidelity Group:

1. What information do you need about our current system?
2. Can you assess our network and connectivity?
3. Can we keep our existing numbers?
4. Which numbers are eligible for porting?
5. What happens if porting is delayed?
6. What is included in design and configuration?
7. Are handsets included?
8. Are mobile apps and softphones included?
9. Can the system integrate with our CRM?
10. Can it work with Microsoft Teams?
11. What support is available during cutover?
12. What happens if we experience a problem after launch?
13. How are failover and forwarding handled?
14. What training is included?
15. Are there minimum terms or minimum user numbers?
16. What happens if we add users or locations?
17. What services may need separate investigation?
18. What information is required before the project begins?

A provider who answers these clearly, in writing, is showing you what the migration will actually be like.

Why speak to Fidelity Group about your phone system?

Fidelity Group is a UK-based business telecoms provider supporting business phone systems, VoIP and hosted telephony, alongside business broadband and connectivity, business mobile, contact-centre solutions and Microsoft Teams telephony options. Because voice, connectivity and mobile can be assessed together, the whole requirement can be reviewed rather than one part of it.

If your organisation is reviewing its current setup, Fidelity Group can discuss your users, locations, working patterns, connectivity, number-porting requirements and future plans before recommending an appropriate next step. The aim is a migration plan you understand and can hold us to, not a proposal built on assumptions.

Start planning your VoIP migration

Replacing a business phone system should begin with a review of your current numbers, users, call flows, connectivity and contract position. Whether your organisation is based in Oxfordshire, Buckinghamshire or elsewhere in the UK, a structured assessment can help identify migration risks before you commit to a new system.

If you are ready to move your business phone system to VoIP, or simply want to understand what a migration would involve for your organisation:

• Request a business phone system review
• Discuss a VoIP migration with a Fidelity telecoms specialist
• Check whether your existing numbers can be retained
• Review our hosted telephony options

Frequently asked questions

How do I move my business phone system to VoIP? Start by auditing your current numbers, users, call flows, equipment and contract. Define your requirements, have your network assessed, choose a deployment model, plan number porting, design the new call flows, test with real users, train staff and cut over with a documented fallback. The exact sequence and effort depend on your existing system and the platform chosen.

Can I keep my existing business number when switching to VoIP? Often, yes. Geographic, non-geographic and direct-dial numbers can frequently be ported to a new provider. Eligibility is not automatic, though: it depends on the number range, location, current service and the arrangements between providers. Ask your new provider to confirm eligibility for every number before you commit.

How long does a business VoIP migration take? There is no fixed answer. A single-site business with a handful of numbers and no integrations is a smaller project than a multi-site organisation with DDI ranges, call recording and Teams integration. Number-porting lead times often set the minimum timescale. Ask for a stage-by-stage plan for your specific project.

Will my current handsets work with a new VoIP system? Possibly, but it must be checked. Some IP handsets can be re-provisioned for a new platform; others are locked to a previous provider or lack required features. Analogue handsets generally need an adapter or replacement. Confirm compatibility with the supplier before assuming any equipment can be reused.

Does VoIP require faster broadband? Not necessarily faster, but suitable. Voice traffic is sensitive to latency, jitter and packet loss, and it competes with other traffic on the connection. The actual bandwidth needed depends on the codec, platform, number of simultaneous calls and other usage. A provider should assess the connection and internal network rather than rely on a speed test.

What happens if the internet connection fails? It depends on the design. Many hosted systems can automatically divert calls to mobiles or another site if a location drops offline, and some businesses add backup connectivity such as a secondary line or 4G/5G router. Ask exactly what happens to inbound and outbound calls during an outage, and test it before go-live.

Is VoIP suitable for small businesses? Generally, yes. Hosted telephony can give a small business features such as auto-attendant, mobile apps and call reporting without on-site equipment. Suitability still depends on the connection, the working pattern and the budget, so an assessment is worthwhile even for a small team.

Can a VoIP system integrate with Microsoft Teams or a CRM? Many platforms offer Microsoft Teams telephony options and CRM integrations such as screen-pop, click-to-dial and call logging. Availability and depth vary by platform, licence tier and the specific CRM in use, so name your systems during requirements and ask for the integration to be demonstrated.

What should I check before cancelling my existing phone service? Confirm in writing that every number has ported successfully, that the new system has passed testing, that fallback and forwarding arrangements are in place, and that any alarm, lift, payment or other devices on the old lines have been dealt with. Then check your existing contract’s notice period. Only then should the old service be cancelled.

Is VoIP migration available for businesses in Oxfordshire and Buckinghamshire? Yes. Fidelity Group supports businesses across Oxfordshire, Buckinghamshire and the wider UK with business phone systems, VoIP and hosted telephony. The right approach for a business in Oxford, High Wycombe, Aylesbury or Milton Keynes depends on its premises, connectivity, workforce and existing system, which is why the process starts with an assessment.