Practice Phone System Migration: Move Lines Without Losing Calls

Changing phone providers looks like an IT task and behaves like a clinical operations risk. The main line usually survives. What goes quiet is the fax the referral desk depends on, the direct extension a hospital has on file for your office manager, and the after-hours number printed on a sign that nobody has updated since 2019.

None of that shows up as a complaint, which is the problem. A patient who calls a dead number does not email you about it. A discharge planner whose fax bounces sends the referral somewhere else. The damage from a botched migration is almost entirely invisible from inside the building, and it can run for weeks before anyone notices the pattern.

This post covers what actually breaks, why ports get rejected, the number inventory nobody completes, and how to sequence a cutover so the old system is still there when something surprises you.

What actually breaks during a phone migration

Three failure modes account for nearly everything. A number that never made it onto the port order simply stops working. A cutover that happened before the new system was fully configured drops calls into a void. And a forwarding rule left over from the old setup quietly sends a slice of traffic somewhere nobody is listening.

Vendor-published windows. Useful for planning, not a guarantee.

The first is the most common and the most preventable. It happens because a practice thinks of itself as having a phone number, singular, when the bill actually lists several and the ones nobody uses daily are exactly the ones nobody thinks to move.

The third failure mode is the sneakiest because it looks like success. Everything rings, everyone is happy, and a forwarding rule set up two years ago for an overflow line is still quietly diverting a share of calls to a voicemail box on a system you no longer own. Nobody finds these by testing the main number.

Porting is a legal right and an administrative obstacle course

Practices often approach this expecting a fight with their incumbent provider. That is usually not what happens. Carriers are required to port a number when they receive a valid request, and an outstanding balance is not a lawful reason to refuse. The incumbent has no standing to keep your number.

What does hold up a port is paperwork. The most common cause of a rejection is mismatched account information, and the mismatch is usually small enough to be invisible until it fails.

It is worth submitting the port order and the account details as one careful piece of work rather than as a form somebody fills in between patients. A rejection does not just cost the correction, it usually costs another full porting window, so a mismatch found in five minutes at the start saves two weeks at the end.

That last row is worth a pause. If a marketing agency or an answering service supplied you a tracking number, it may sit on their account rather than yours, and it may not be portable at all. Find that out before it is printed on anything else.

Inventory every number before you touch anything

The inventory is the job and everything else is scheduling. A single-location practice typically carries more numbers than its staff expect, and the ones that matter most are often the ones used least, which is exactly why nobody thinks to list them when a vendor asks what needs moving.

Eight categories. Most practices find at least two they had forgotten.

Direct extensions deserve their own pass. Hospitals, referring offices, labs, and payers all keep direct numbers for specific people at your practice, collected over years and stored in systems you cannot see. Those numbers are not on your marketing material and they are the ones whose failure costs you referrals rather than patients.

Work from three sources rather than one. The carrier bill lists what you pay for. Your online listings, directory entries, and printed material list what patients actually dial. And the referral desk, the billing team, and the on-call service each know a number that appears on neither.

The cutover window is where calls go missing

Vendors describe migrations as zero downtime, and that is achievable, but only under conditions the marketing page does not state. The new system has to be fully built and tested before anything moves, the port has to complete during a low-traffic window, and the old service has to stay live afterwards rather than being cancelled the same day.

The old service comes down last, never on cutover day.

Never cut over on a Friday. If something surprises you at 4 p.m. you have a weekend of dead lines and a vendor support desk that is closed. Tuesday morning gives you three full business days with everyone available, which is the single cheapest risk reduction in this whole exercise.

There is a second reason to avoid a Friday that has nothing to do with support hours. Cutover day generates a burst of small problems that staff need to report, and the people best placed to notice them are the ones who answer the phone all day. On a Friday afternoon those observations go home for the weekend and arrive on Monday as vague recollections.

Keep the old service running in parallel for at least a week after the port completes. It costs one more month of a bill you were about to stop paying and it is the only thing standing between you and a hard failure with no fallback.

What to test before you release the old system

Test from outside the building, always. Calls placed from a desk phone on your own network can succeed while the outside world reaches nothing at all, and that is precisely the failure mode that survives a cheerful round of internal testing and then runs unnoticed for days afterwards.

Call every ported number from a mobile on a different carrier. Then call the main line after hours and confirm the routing does what it did before. Send a fax to your own fax number from somewhere else and confirm it arrives. Then check that voicemail actually reaches somebody, because voicemail boxes routinely survive a migration as orphans that nobody monitors.

Test with the staff who will actually use it, too. A transfer that works when the vendor demonstrates it may not work the way your team expects to perform it, and a receptionist who cannot transfer a call on day one will invent a workaround that lasts for years.

If you are pointing the main line at an automated system as part of this move, test its escalation path rather than just its greeting, using the approach in designing the handoff to a human. If the system is new to you, what an AI receptionist actually does is worth reading before you decide what the main line should point at.

The lines nobody remembers until they break

Beyond the phones people talk into, most practices have analogue lines doing quiet jobs. The credit card terminal, the alarm panel, an elevator emergency phone, a postage meter, and sometimes a legacy fax line the billing service depends on. Several of these will not work over a standard internet connection without specific handling.

Ask your vendor directly which of these they have handled before rather than whether they support them. The answer to the second question is always yes. The answer to the first tells you whether they will recognise the problem when the card terminal stops settling on the second day.

The alarm panel is the one worth checking personally. Monitored alarm and fire systems often rely on a plain phone line, and a migration that silently breaks that connection creates a compliance and safety problem that nobody discovers until the next test or the next incident.

A realistic timeline

Published vendor figures put number porting at 7 to 14 business days, a full migration at 2 to 4 weeks from kickoff to go-live, and a single-location cutover at 24 to 48 hours including configuration and staff training. Multi-site practices phase it site by site rather than moving everything at once.

Three checks. Any one of them failing is a reason to wait a week.

Walk the readiness check once. Every number on the order, including the ones nobody uses. Account details matching the bill exactly, because a single mismatched character is a two-week delay. Calls tested from outside on a mobile before anything is released. And a cutover early in the week with the old service still live behind it.

One more sequencing note. If you are also changing what answers the phone, do the two moves separately rather than together. Porting numbers and introducing a new answering flow on the same morning makes every problem ambiguous, and you will spend the week arguing about which change caused what.

Budget for the fees nobody mentions in the quote: per-number porting charges, toll-free handling, and premium support if you want somebody reachable during the cutover. These are small individually and they change the comparison between two vendors whose headline pricing looked identical, which is the same pattern covered in the contract terms that set your real bill.

Whatever you move to, size what the phone is currently costing you first. A migration is a good moment to fix a call-handling problem rather than to carry it across, and the free Growth Leak Audit works from your own numbers, with the underlying arithmetic in the real cost of missed calls.