How to Migrate from a Legacy PBX to Cloud in 30 Days

Why Is Now the Time to Migrate?

If your business is still running an on-premises PBX — whether it is an Avaya IP Office, NEC SV9000, Mitel MiVoice, or a Panasonic KX series — you are operating on borrowed time. The ISDN network that many of these systems relied on has been fully decommissioned in Australia. Hardware vendors are ending support for legacy platforms at an accelerating rate, with Avaya, NEC, and Mitel all shifting their investment toward cloud-native offerings.

According to Frost & Sullivan's Asia-Pacific UCaaS Market Report (2024), 71% of Australian businesses with on-premises PBX systems plan to migrate to cloud within the next 24 months. The question is no longer whether to migrate, but how to do it without disrupting your business.

This guide walks through a proven 30-day migration framework that PCONNECT has used across hundreds of deployments — from 10-user offices to multi-site organisations with 500+ seats.

Week 1: Discovery and Planning (Days 1-7)

Audit Your Current System

Before touching anything, document exactly what your existing PBX does. This step is where most failed migrations go wrong — not because the technology was inadequate, but because features and call flows were not fully understood before the cutover.

Document the following:

Phone numbers — Every DID (Direct Inward Dial), 1300/1800 number, fax number, and hunt group pilot number. Cross-reference with your carrier invoices to ensure nothing is missed.
Call flows — Auto-attendant menus, hunt groups, ring patterns, after-hours routing, and holiday schedules. Record and transcribe existing IVR prompts.
User requirements — Who has a desk phone, who uses a softphone, who needs mobile twinning, who is a reception operator, who handles call queues.
Analogue devices — Fax machines, EFTPOS terminals, alarm systems, lift phones, door intercoms. Each requires a specific migration approach.
Integrations — CRM screen pops, call recording systems, wallboards, paging systems, overhead speakers.

Select Your Cloud Platform

Based on the audit, select the cloud PBX platform that matches your requirements. A vendor-independent provider like PCONNECT will recommend from platforms including Cisco BroadWorks, NetSapiens, Microsoft Teams Calling, or 3CX based on your specific needs — rather than defaulting to a single option.

Order Number Ports

Initiate number porting requests immediately. Number porting in Australia is governed by the Telecommunications Number Portability Industry Code (C570:2009) and typically takes:

Geographic numbers (02, 03, 07, 08): 1-5 business days
1300/1800 numbers: 3-10 business days
Complex ports (multiple carriers): Up to 15 business days

Starting ports in week one is critical because porting timelines are the single biggest variable in any migration schedule. A 2023 ACMA compliance report found that 12% of number ports in Australia experienced delays, most commonly due to incorrect customer authorisation details or carrier processing backlogs.

Week 2: Configuration and Build (Days 8-14)

Configure the Cloud Platform

With the discovery documentation in hand, configure the cloud PBX to replicate and improve upon your existing setup:

User accounts — Create all users with correct extension numbers, DDIs, voicemail settings, and permissions
Call flows — Build auto-attendants, hunt groups, call queues, and time-of-day routing
IVR prompts — Record or upload auto-attendant greetings. Professional recordings make a measurable difference — a Vonage study found that 75% of callers perceive businesses with professional IVR greetings as more trustworthy
Voicemail — Configure voicemail-to-email, greeting prompts, and distribution lists
Integrations — Set up CRM integration, call recording policies, and any API-based workflows

Provision Handsets and Devices

Order and pre-configure IP phones, headsets, and any ATAs (Analogue Telephone Adapters) for legacy devices. Modern IP phones from Yealink, Poly, and Cisco can be centrally provisioned — configured with user credentials, speed dials, and BLF (Busy Lamp Field) keys before being shipped to each site.

For analogue devices, deploy an ATA at each location that requires fax, EFTPOS, or alarm connectivity. Ensure T.38 fax relay is configured for reliable fax transmission over IP.

Week 3: Testing and Parallel Run (Days 15-21)

Internal Testing

Before any number porting, test the cloud platform thoroughly using temporary numbers:

Inbound call routing — Test every auto-attendant option, hunt group, and after-hours path
Outbound calling — Verify caller ID presentation, emergency services (000) routing, and international dialling
Voicemail — Test voicemail recording, retrieval, and voicemail-to-email delivery
Call quality — Make test calls from every site and verify MOS (Mean Opinion Score) meets acceptable thresholds (4.0+)
Failover — Simulate internet failure and verify calls redirect to mobile or backup routes

User Acceptance Testing

Identify 3-5 power users from different departments and have them use the new system for a full day. These users will uncover workflow-specific issues that generic testing misses — a particular speed dial that is critical, a call transfer behaviour that works differently, or a headset compatibility issue.

Parallel Run Strategy

A parallel run means operating both your old and new phone systems simultaneously for a defined period. This is the single most important risk mitigation step in any PBX migration.

During the parallel run:

Incoming calls continue to ring on the legacy PBX via the existing numbers
Users have access to both systems and can make outbound calls from either
The new cloud PBX is tested with temporary or ported numbers that are not yet the primary numbers
Issues are identified and resolved before the final cutover

A 3-5 day parallel run is sufficient for most businesses. Longer parallel runs increase cost (you are paying for two systems) without proportionally reducing risk.

Week 4: Cutover and Go-Live (Days 22-30)

Number Porting Cutover

Coordinate the final number port to move your business numbers from the legacy carrier to the cloud PBX platform. This is the point of no return and should be scheduled carefully:

Midweek, mid-morning — Avoid Mondays (carrier processing backlogs) and Fridays (limited time to resolve issues). A Tuesday or Wednesday at 10:00 AM is ideal.
Confirm porting date — Verify with both the losing and gaining carrier that the port is scheduled and on track at least 48 hours before the cutover date.
Brief your team — Ensure all staff know the cutover date and time, and have their new phones or softphones ready.

Go-Live Day

On cutover day:

Verify number port completion — Test inbound calls to every ported number within 15 minutes of the scheduled port time
Monitor call quality — Actively listen to calls and check for audio issues during the first 2 hours
Support desk — Have your provider's support team (and internal IT) available on-site or on standby for the first full business day
Legacy system — Keep the old PBX powered on but disconnected for at least 5 business days in case an emergency rollback is needed

Post-Cutover (Days 23-30)

Monitor and tune — Review call analytics daily for the first week. Look for missed calls, long queue times, or unexpected call patterns.
User feedback — Collect feedback from staff after 3 days and again after 7 days. Address issues promptly.
Decommission — Once the new system is confirmed stable (typically after 5-10 business days), decommission the legacy PBX hardware. Arrange for secure disposal or recycling.

Common Pitfalls and How to Avoid Them

Pitfall 1: Incomplete Number Audit

Missing a ported number — especially a 1300 number used in advertising or a fax number on legal documents — causes immediate business disruption. Always reconcile your number list against carrier invoices, not just what your staff can recall.

Pitfall 2: Underestimating Analogue Requirements

Fax machines, EFTPOS terminals, and alarm systems are easy to overlook in the excitement of deploying a new cloud phone system. Each requires an ATA and specific configuration. Test fax transmission and EFTPOS connectivity during the parallel run, not on go-live day.

Pitfall 3: Inadequate Internet Bandwidth

Each concurrent call requires approximately 100 Kbps of bandwidth. If your internet connection is already saturated, adding voice traffic will result in poor call quality. Conduct a bandwidth assessment in week one and upgrade your connection if necessary.

Pitfall 4: Skipping the Parallel Run

Cutting over directly from legacy PBX to cloud without a parallel run eliminates your ability to catch issues before they affect live business calls. Every migration should include at least a 3-day parallel run.

Frequently Asked Questions

What happens to my fax machines during migration?

Fax machines are connected to the cloud PBX via an Analogue Telephone Adapter (ATA) using T.38 fax relay protocol. This provides reliable fax transmission over IP. Alternatively, many businesses use the migration as an opportunity to move to an email-to-fax service, eliminating the physical fax machine entirely.

Can I keep my phone numbers?

Yes. All Australian geographic numbers, 1300/1800 numbers, and most other number types can be ported to a cloud PBX platform. The porting process is regulated by the ACMA and your provider manages the entire process. Numbers are maintained without interruption when the port is coordinated correctly.

What if something goes wrong during cutover?

A well-planned migration includes a rollback procedure. If critical issues are discovered during cutover, calls can be redirected back to the legacy PBX within minutes using call forwarding or emergency re-porting. This is why the legacy system should remain powered on for at least 5 business days after cutover.

Do I need to replace all my desk phones?

Not necessarily. If your existing phones are SIP-compatible (most IP phones manufactured in the last 10 years are), they may work with the new cloud platform. However, older analogue phones connected to the legacy PBX will need to be replaced with IP phones or connected via ATAs. Most businesses use the migration as an opportunity to refresh their handsets.

How much downtime should I expect during migration?

With a properly executed parallel run and coordinated number port, downtime should be less than 15 minutes — the time it takes for the number port to propagate. During this brief window, inbound calls may experience a short delay before routing to the new platform. Outbound calling on the new platform is available immediately.