The short version
Most of an 8x8 implementation is not technical. The platform configuration is the straightforward part. The work that determines whether go-live is calm or chaotic is discovery, porting and testing.
| Stage | Who does the work | Typical elapsed time |
|---|---|---|
| Discovery | You and the installer | Days |
| Network readiness | Installer | Days, longer if remediation is needed |
| Licence and platform build | Installer | Days |
| Number porting | Losing carrier | Weeks — usually the long pole |
| Handsets and apps | Installer, then users | Days |
| Testing and training | Everyone | Days |
| Cutover | Scheduled | Hours |
Discovery: what actually happens to a call today
This stage exists because businesses rarely have an accurate picture of their own call handling. Numbers were added over years, diversions were set during a staff absence and never removed, and the person who configured the original system may have left.
What needs establishing:
- Every number the business owns, including ones nobody uses
- Where each number currently terminates
- How calls are distributed — reception, ring groups, direct lines, mobiles
- After-hours, holiday and overflow behaviour
- Voicemail arrangements and who monitors which box
- Any number printed on vehicles, signage, invoices or advertising
- Which staff need a handset, which need an app, and which need both
That last point matters for licensing. The most common costing error is assuming everyone needs the same licence, which is covered in which 8x8 licence do you actually need.
The numbers printed on signage deserve particular attention. A number nobody uses internally may still be the one customers dial.
Network readiness
Cloud voice runs across the internet service, so the site needs verifying before go-live rather than diagnosing afterwards.
This covers upload capacity against expected concurrent calls, whether voice traffic can be prioritised, whether the gateway handles call sessions predictably, and whether handsets will be cabled or on Wi-Fi. Where remediation is needed — a connection upgrade, a business-grade gateway, cabling to desks — that work has its own lead time and should be identified early.
Network requirements for 8x8 before go-live covers this in detail.
Number porting: start it early
This is the stage that sets the calendar, and it is largely outside the installer’s control. Porting depends on the losing carrier releasing the numbers, and their process determines the pace.
Two practical points. First, the details on the port request must match the losing carrier’s records exactly — account name, address, service numbers. A mismatch is the most common cause of rejection, and each rejection costs time. Second, do not cancel anything with the existing provider until the port completes. Cancelling a service before its numbers transfer can lose them permanently.
Porting is scheduled, so the actual switch happens at a known time rather than unpredictably.
Platform build and call flow design
While porting proceeds, the platform is configured: users, extensions, ring groups, auto attendants, business hours, voicemail, call recording where required.
This is the point to improve things rather than replicate them. If reception has been manually transferring every call for years, or after-hours callers reach a voicemail nobody checks, a migration is the natural moment to fix it. Rebuilding the old behaviour exactly, including its faults, is a missed opportunity — and it is what happens by default if nobody asks the question.
For businesses weighing whether they need queueing and reporting, do you need a contact centre, or just a better phone system is worth reading before the build rather than after.
Handsets, apps and training
Desk handsets are provisioned and, where possible, cabled rather than placed on Wi-Fi. Softphone and mobile apps are installed for staff who need them.
Training is short but should not be skipped. Most complaints after a phone migration are not faults — they are people not knowing how to transfer a call, park it, or pick up a colleague’s ringing phone. Twenty minutes per group prevents a fortnight of tickets.
Testing before cutover
Testing should cover inbound calls to every published number, outbound calls including to mobiles, transfers between staff, call flows at each time of day, after-hours behaviour, voicemail delivery, and emergency calling with the correct registered service address.
That last one matters. Cloud voice is not tied to a physical line, so the address associated with the service is what emergency services receive. It should be verified as correct for the site.
Cutover and the days after
At cutover, numbers begin arriving on the new platform. The old system stays available briefly rather than being decommissioned immediately.
Expect a short settling period. Typical items are a diversion nobody knew about, a staff member’s mobile app not signed in, or a number that was never included in discovery because nobody remembered it existed. These are normal and quick to resolve when someone is watching for them, which is why support presence in the first days matters more than in the following months.
If call quality problems appear, they are almost always network rather than platform, and dropped calls on cloud phones covers the diagnosis.
Helpful starting points
If you are evaluating whether to move at all, UCaaS vs traditional phone systems and on-premise PBX vs UCaaS cover the case. If the decision is made, 8x8 cloud communications covers how we run these deployments.