How to Switch Phone Systems Without Losing a Call

Why cutovers go wrong

Almost never for technical reasons. Handsets, trunks and platforms have spoken the same open protocol for over twenty years [1], so the pieces fit. Cutovers go wrong because someone tried to do discovery, build, test and switch in a single evening, and discovered at 9pm that the elevator phone is on an analogue line nobody mentioned.

The runbook below is deliberately unhurried. Its central principle is that the new system exists and works before the old one stops mattering, and that reverting is always one change away.

The cutover is not the risky part. Building without a parallel test window is.

Week 1 — Discovery

Document what exists, without touching it.

1. Extensions. Every handset: number, make, model, location, who sits there. Include unused ones.
2. Call flows. Call your own main number from a mobile during business hours, after hours, and on a weekend. Write down the greeting verbatim, every menu option and where it lands.
3. Numbers. Get the assigned-number list from your carrier in writing, and compare it against the caller ID each department actually presents.
4. Analogue. Elevator, alarm dialler, fax, paging, door intercom. Find them physically.
5. Trunk details. Concurrent call capacity, how the carrier authenticates you, and what they need in order to change the delivery destination [3].
6. Network. Upload speed at each site, router model, whether voice prioritisation exists.
7. Voicemail. Identify anything worth preserving, and boxes belonging to people who have left [5].

Discovery findings that change scope almost always come from items four and five. Finding them in week one is the whole point.

Week 2 — Parallel build

The replacement is configured while the old system runs untouched. Extensions, call flows, business hours, holiday dates, voicemail boxes and voicemail-to-email are all built from the week-one documentation.

Then it is tested on a spare number, before any production traffic exists. A temporary number points at the new platform and every path gets walked: each menu option, each department, no-answer behaviour, after-hours behaviour, holiday behaviour, transfers, voicemail delivery to the right inbox. Audio quality is checked in both directions — calls that connect but sound one-way or choppy are almost always a media-path issue rather than signalling [2].

Nothing in your live phone service has changed at this point. The old system has not been modified and nobody in the building has noticed anything.

Week 3 — Staging and pilot

Handsets are prepared to register to the new platform, typically by staging configuration so a reboot moves them. Existing handsets are retained — they are Class 8 property you already own [6] and there is no reason to replace working hardware.

Then a pilot: three to five people, ideally including reception, move to the new system while everyone else stays on the old one. Both systems run simultaneously, which is possible precisely because the protocol is standard. The pilot group makes and receives real calls for several days, and what surfaces is the human layer — a transfer keypress that differs, a speed dial that needs rebuilding, a headset that needs re-pairing. Training happens here, on real calls, with a small group who can then help everyone else.

Week 4 — Cutover

Tuesday or Wednesday evening, after close. Not Friday, because a Saturday problem waits until Monday. Not Monday, because it is the heaviest call day of most weeks.

1. T-2 days: confirm the carrier change request is scheduled. Notify staff of the date and what they will see.
2. T-1 day: save any voicemail worth keeping [5]. Final walkthrough of every call flow on the new platform.
3. Evening, step 1: carrier redirects call delivery to the new platform. This is the actual switch, and it is one setting.
4. Step 2: handsets reboot in a batch and register to the new system.
5. Step 3: test from an outside mobile — main number, each menu option, each department, a transfer, a voicemail, and confirm the voicemail email arrives.
6. Step 4: test the analogue devices explicitly. Call the elevator phone. Trigger a test on the alarm dialler if the monitoring company can accommodate it.
7. Step 5: leave the old system powered on and configured. Do not decommission anything.
8. Next morning: someone technical present at opening, for the first hour.

The two-week fallback window

Reverting should be a documented procedure rather than an improvisation, which is the general lesson of federal disruption-planning guidance [4]. For two weeks after cutover: the old system stays powered on with its configuration intact, the carrier keeps the previous delivery setting on file, and the handset rollback procedure is written down and known. Reverting takes minutes.

This window costs nothing but rack space, and it converts the cutover from a decision into an experiment. Decommission only after two weeks of clean operation — at which point the old hardware can be disposed of, with any residual voicemail on it deliberately destroyed rather than left in a storeroom [5].

When thirty days is the wrong number

The runbook is a default, not a law. Two situations change it.

Compress it when the existing system is already failing — hardware dying, no support available, or an active security exposure. In that case the sequence stays the same but the parallel window shrinks to about ten days, and you accept a smaller pilot. What should never be dropped is the fallback window after cutover, because a rushed build is precisely the one most likely to need it.

Extend it when the environment is complicated: multiple sites, an unusual analogue estate, a contact-centre style call flow with skills-based routing, or a business that genuinely cannot tolerate a bad hour. Six weeks is reasonable for a multi-site cutover, largely because each location needs its own network check and its own pilot, and because staging handsets across buildings takes longer than staging them in one.

What to ask your existing carrier, and when

The carrier is the one external party whose timeline you do not control, so engage them in week one rather than week four. Three questions settle almost everything: what is the exact procedure to change where calls are delivered, how much notice do you need, and can the previous setting be kept on file for a quick reversion. Get the answers in writing, and get the name of the person who will action it.

If the carrier also supplies your current phone system, expect the conversation to be less enthusiastic, and expect a retention offer. That is normal commercial behaviour rather than obstruction, and conditions of service are in any case governed under the general framework of the Telecommunications Act [3]. Ask for the change date in writing and keep the request narrow: you are changing a delivery destination, not cancelling lines.

What actually goes wrong, ranked

• Forgotten analogue devices. The elevator, the alarm, the fax. Almost always the top of the list, and almost always found late.
• Outbound caller ID. A department presents a number the carrier no longer assigns you. Caught by testing outbound from each department, which is why it is a discovery step.
• Local network. No voice prioritisation, so calls degrade when someone uploads a large file. A router-configuration fix, not a phone-system one.
• Voicemail email delivery. Messages route to an address nobody monitors, or filtered as spam. Test with real delivery, not a config screen.
• Staff habits. Transfers done differently. Solved by the pilot group, not by a memo.

Bottom line

Thirty days, four weeks, one evening of actual change. Keep your carrier so numbers never move [3]. Build and test in parallel because the protocol permits it [1]. Pilot with real people before everyone. Keep the fallback available for two weeks [4]. MapleReceptionist setup is $350 at the entry band, or $250 with a 12-month commitment, and it covers this process rather than a configuration handover.