What to Check When Moving to a VoIP Phone System: A Site Checklist

2026-10-27　　Views:

Most VoIP migrations are delayed by things nobody wrote down. Not the software, not the internet connection — the fact that a fax machine was on a shared line, that the alarm panel needs a specific ringing pattern, or that one building has no power socket where the rack needs to go. A site checklist turns all of that into a list, and the list is what keeps a cut-over date intact.

Start with an inventory of everything that draws a line

Walk every floor and every room with a phone point, a wall plate or a device that connects to a phone line. For each one, record what it is and what it needs. The categories that get forgotten are consistently the non-voice ones, so make sure you look specifically for them.

Analogue phones that will stay, including wall-mounted and ruggedised units
Fax machines and multifunction printers
Door entry and access control panels
Lift and elevator intercoms
Point-of-sale and payment terminals
Public lobby and corridor handsets
Paging and announcement amplifiers
Alarm panels that signal over a phone line
Time clocks and other serial-over-phone devices
Any wall plate that is currently unused but might be needed later

The last one is worth including deliberately. A spare wall plate in a meeting room costs nothing to record and saves an electrician visit later.

Map the cabling and the distance

Every endpoint needs a path back to the equipment room, and the path is often the real constraint. Legacy analogue cabling runs are generally fine for the existing phones. The question is what happens to a new endpoint in a new location, and whether any device is far enough from the rack that it cannot be served reliably.

Record, per location: the cable type if you can identify it, where it terminates, and the approximate run length. Note any outdoor or exposed runs. Voice over IP is more sensitive to delay than web traffic, and the voice quality and QoS guide covers how that shows up in practice.

Confirm power and rack space

The equipment room is where the physical constraints converge, and it is worth measuring rather than estimating.

Check the available rack units against the equipment you intend to install plus the spares you want to keep. Check the power outlets and whether they are on a UPS. Check whether there is capacity for the MA50-LS survivable branch exchange. Confirm the environmental conditions — this is equipment that stays powered and warm for years.

Decide, per device, whether it becomes SIP or stays analogue

This is the central design decision of the migration, and it is a decision per device rather than per site. Some devices can only work on an analogue line. Some can be replaced with a SIP equivalent. Some should be replaced with something that speaks a protocol your system understands rather than emulating a phone line.

Device	Keep on analogue (FXS)	Replace with SIP equivalent	Notes
Desk phone	Possible but limits features	Usually preferred	Legacy handsets work but lose softphone and app integration
Fax / MFP	Common	Where the vendor supports it	Check the model's supported line type
Door entry panel	Often	Rarely	Verify the signalling type, not just the connector
Lift intercom	Often	Rarely	Needs a specific ringing pattern
POS terminal	Often	Depends on the vendor	Confirm the line interface it expects
Paging amplifier	Common	Vendor-specific	Check input type and control method

Newrock's OM series has combinable FXS/FXO ports, so keeping a mix of legacy devices is a supported approach rather than a workaround. The MX8G gateway provides 8 FXS/FXO ports when the analogue devices are not near the main chassis, and the MA50-LS concept of a local survivable branch applies where a site must keep working independently.

Check the internet path for voice

Before go-live, test the actual connection rather than the advertised one. Upload bandwidth, latency to the carrier's point of presence, and jitter are what determine voice quality. If the site shares a link with other traffic, plan how voice will be prioritised.

Do this at the times your site is actually busy. A connection that measures fine at 10am on a Friday can be quite different at 5pm on a Monday, and the busy-hour measurement is the one that matters.

Record the numbers and plan the porting

List every number the site uses, who owns it, and whether it needs to be ported or can be released. This list gates the cut-over date because porting is a carrier process with its own lead time — start it before the hardware decision, not after.

Plan the cut-over day itself

Write the cut-over as a sequence with named owners and a rollback point. Who disconnects the old system, who confirms the new one is answering, who calls the carrier if a number has not ported, and how long you stay in the old building if something is wrong.

A cut-over that has a defined rollback path takes less time overall than one without, because the person doing it can make a decision instead of improvising.

The most expensive item on a migration list is always the device nobody remembered to list. Budget for one surprise and you will have covered it.

Frequently asked questions

How do I know which devices are analogue?

Physically, they are usually obvious — RJ11 connectors, wall plates with a single socket, devices with a phone cord. The hard part is not the identification but the inventory discipline: the device nobody remembers in the storage room is the one that bites you on cut-over day.

Do I need to re-cable the whole building?

Usually not. Existing analogue cabling generally serves existing analogue devices, and IP phones need a network outlet with power, which is where the cabling work concentrates. The IP phone and cabling guide covers the cabling and power side of that.

What about devices I have not used in years?

Record them, decide deliberately, and either keep them working or retire them before the cut-over. An undocumented device that still has a line attached is a source of surprise calls and confusion.

Can a site keep working if the internet fails?

That depends on the design and has to be designed in, not hoped for. Local survivability options exist, and they need to be specified as part of the project with the hardware placed accordingly.

Conclusion

The checklist is unglamorous and it is the thing that protects your cut-over date. Inventory the line-drawing devices, map the cabling, measure the rack and the power, decide per device whether it becomes SIP or stays analogue, test the internet path at busy hour, start the number porting early, and write the cut-over as a sequence with a rollback. Every one of those steps is quick. The alternative is discovering the same information, more expensively, on the day.

Return

News