
Guides
Part of Making sense of VoIP systems: live or die on the network path
VoIP systems migration: audit what the old system does
A VoIP systems migration starts with an audit: record extensions, queues, out-of-hours routing and non-phone devices, then use the list to test the pilot.
The decision to move to a phone system takes a week. A VoIP systems migration takes a quarter, and the part that hurts is not the technology. A phone is the one system your customers use directly, so every mistake is public within minutes.
What to take away
- Record what the old system does before you design the new one: extensions, direct numbers, hunt groups and the out-of-hours path.
- Treat the audit list as the test script for the pilot, row by row.
- Decide the numbering and the account holder on paper, before any handset is deployed.
- Anything that is not a phone, such as a lift phone or an alarm panel, is the item most likely to cause an incident.
Map what the old system does
Start with an audit of what the old system actually does, not what anyone remembers it doing, and keep the result as a written list. Almost every unpleasant surprise in a phone migration is something the old
Inventory before migration
- Every extension and who sits at it
- Every direct-dial number and where it lands
- Hunt groups and queues, in order
- Out-of-hours and holiday routing
- Voicemail boxes and who reads them
- Non-phone devicesalarms, lifts, terminals
- Recorded greetings to re-record
| What to record | Why it bites later | How to check it in the pilot |
|---|---|---|
| Every extension and who sits at it | The list in the directory is always out of date | Call each one from an outside line and confirm the right person answers |
| Every direct-dial number and where it lands | Some belong to a person who left in 2019 and still ring | Dial each number and note where it lands |
| Hunt groups and queues, in order | Order is behavior, and nobody remembers it | Call the group and listen to the order it rings |
| The out-of-hours and holiday routing | It only fails on the day it matters | Call in the evening and on a public holiday |
| Voicemail boxes and who reads them | Boxes get orphaned and messages get lost | Confirm every box has a named reader |
| Anything that is not a phone | Alarm panels, lift phones, card terminals, a door entry panel | Test each device after it moves |
| Recorded greetings | Re-recording them takes longer than anyone allows | Play each greeting on the new system |
The last two rows are the ones that turn a smooth migration into an incident. A lift phone that stops working is a safety matter, not an inconvenience.
Design the numbering before the hardware
Numbering is a design decision, and it is cheaper to make on paper than after the handsets are deployed.
Decide how extensions map to direct numbers, and keep the mapping mechanical.
Two numbering decisions
What number do staff present when calling out?
main number keeps callbacks at switchboard
direct number sends callbacks to a person who may be on leave
Two decisions to make consciously:
- What number staff present when they call out.The main number keeps callbacks going to the switchboard. A direct number sends them to a person who may be on leave. Pick per team, not for the whole company.
- Who is the account holder.The organization, with contact details that survive staff changes. Everything about your numbers, including whether you can take them away later, runs through that record, which business phone numbers treats as the first thing to get right.
Turn the audit into the pilot
The pilot is where the audit earns its keep, because each row gives you something specific to check. The hunt groups and queues on the new platform are only useful if they ring in the order the old ones did.
- Build the new system fully, including out-of-hours routing.
- Give one team new handsets alongside their old ones, and forward a copy of their calls to the new system so real calls arrive.
- Run for a full week, including a Monday and a month end.
- Work down the audit list and mark every row as passed or failed.
- Fix what the pilot surfaces. There will be something, and it is usually about the network path rather than the phone system.
- Move the remaining teams a group at a time.
- Port the numbers last. The record checks for that step sit with business phone numbers migration.
Porting is last because it is slow and awkward to reverse. Carriers must complete a simple port request within one business day, unless the new provider or the customer asks for longer. Complex ports can take longer.
The rows that become incidents
Quiet devices fail quietly. Alarm panels, lift phones and card terminals do not complain until the day they are needed, and they are rarely in any inventory, so a walk through the building finds more than the configuration does.
Emergency dialing belongs on the same list.
Confirm with the provider how emergency calls are handled from the new service and what address is passed, before staff rely on it.
Under 47 CFR 9.16, anyone who installs, manages or operates a multi-line telephone system must configure direct 911 dialing, with no extra digit such as the 9 used for outside lines, so test that from every kind of handset.
Common questions
Can we split a block of numbers?
Sometimes, and it is worth asking early: the answer decides whether you move in stages or all at once.
Why decide caller ID per team?
Because the two choices send callbacks to different places. A main number sends them to the switchboard, while a direct number sends them to a person who may be on leave.
Do we keep the old system afterward?
Keep it live until the last number is confirmed and tested. Keep the configuration export permanently, because it is the only record of what the old routing did.







