Home › Resources › Migrating to cloud telephony without downtime
Guide · TelephonyMigrating to cloud telephony without cutting the switchboard
A successful telephony migration is not done in one go on a Friday evening. It is done in stages, with both systems running in parallel long enough to check that the real routing matches the planned routing. The item that sets the whole timetable is neither the software nor the training: it is number porting.
Published on 12 September 2026Team activity · Sales
Today, 9:00 am – 6:00 pm
The audit.
Before comparing offers, know what you have. This list takes half a day and prevents unpleasant surprises three months later.
- Every number in service, with its operator and type (geographic, national, special). This is the centrepiece.
- Your current contracts and their end dates — a migration started six months before the end of an engagement is paid twice.
- Your real call org chart, not the one in the original document: who answers what today, informal arrangements included.
- Your volumes: inbound and outbound calls, spread through the day, seasonal peaks.
- Your opening hours and on-call cover, public holidays included.
Check the network.
In cloud telephony the network becomes the single point of failure. This check cannot wait for the cut-over.
- Bandwidth must cover simultaneous calls at peak, not on average.
- Behaviour at peak hours matters more than headline speed: jitter and packet loss are immediately audible.
- Backup — a second link, mobile access or automatic forwarding to mobiles. Decide now, not on the day of the outage.
- Handsets — browser, IP phone or mobile. The headset is the best-value purchase for perceived quality.
Porting: start here.
This stage determines the timetable, and it is the only one you do not fully control: it depends on your current operator, the country and the number type. Some numbers port easily, others not at all.
- Do the inventory first and send it early: we confirm what is portable, on what conditions and in what timescales.
- Plan for non-portable numbers — forwarding from the old number during a transition period, then communicating the new one.
- Do not announce a cut-over date until porting is confirmed. That is the mistake that costs most in internal credibility.
See our virtual numbers page for number types and the documents expected by country.
Run both systems.
The most reassuring phase, and the one most often skipped out of impatience. For a few days the old switchboard keeps working while the new one takes part of the traffic.
- Start with a pilot team — the one with the steadiest volume, not the most critical.
- Compare real routing with planned routing. This is where the informal rules nobody mentioned come to light.
- Test at peak hours, not at 3 pm on a Tuesday.
- Test overflow and closing hours — otherwise you discover them in production.
Cut over, then train.
The cut-over is a moment; adoption takes a few days. It is quicker than feared when the interface is a browser — most of the training effort goes to supervisors, not agents.
Agents
Answer, transfer, hold, consult the customer record. An hour is usually enough.
Supervisors
Queues, statuses, listening, whispering, barge-in, dashboards. This is where to invest.
AutonomyAdministrators
Opening hours, voice menus, queues, adding seats and numbers — all online.
What derails a migration.
- Announcing a date before porting is confirmed. The most frequent, and the most visible internally.
- Documenting the theoretical routing. What counts is what actually happens when nobody answers at 12:30.
- Skipping parallel running to save a week, then spending the following month correcting in production.
- Forgetting the network. A perfect migration on a saturated link produces mediocre telephony — and the provider carries the blame.
- Neglecting supervisor training. Agents adapt on their own; supervisors do not, and they are the ones who keep the tool alive.
Send us your number list.
With your numbers, their operators and your call volume, we confirm what is portable and in what timescale — before any commitment.
No commitment · Reply within 24 working hours
Frequently asked questions
How long does a migration take?
Almost entirely determined by porting timescales, which vary by operator, country and number type. The rest — configuration, parallel running, training — is counted in days. Send us your number list and their operators: that is the only way to give a timetable that holds, rather than a meaningless average.
Can we keep our existing numbers?
In many cases yes, but it is assessed number by number. Some number types and some countries have particular rules. Treat it before comparing offers.
Do we have to switch everything at once?
No, and it is not advisable. A pilot team first, then the rest: that leaves time to discover the informal routing rules nobody had documented.
What happens during parallel running?
Both systems coexist: part of the traffic goes through the new one, the rest through the old. You compare real behaviour with expected behaviour, at peak hours, with no risk to the business.
Do we need new hardware?
No switchboard: it disappears. For handsets, a browser is enough; existing IP phones can often be kept depending on compatibility. The one purchase we recommend systematically is a headset.
What if our internet connection is not reliable?
Then secure the network before migrating, not after. A second link or mobile backup is part of the project, not an option. Without it, a network outage becomes a complete telephony outage.