Moving from on-prem to cloud PBX: an Australian migration playbook

Most Australian on-prem PBX customers eventually face the same conversation: hardware refresh in 12 months or a planned move to cloud now. Doing a proper migration is straightforward - if you follow the right playbook. Here’s the one we use.

Step 1: Audit your current setup

Document the things that matter:

• PBX platform - vendor, model, software version, age, support-contract status.
• User count - total extensions, active users, hot-desk users, voicemail-only mailboxes.
• Handsets - model list, age, condition. Identify which can re-provision for SIP, which need replacement.
• Numbers - full list of inbound numbers (1300/1800, landline, mobile), carrier, contract status.
• Call flows - auto-attendant menus, after-hours rules, queues, IVR trees.
• Recording - what’s recorded, retention rules, storage location, current archive size.
• Integrations - CRM, helpdesk, time-billing, hotel PMS, anything else touching the PBX.
• Reporting - what reports the business currently relies on.

Audit drives scope. Skip this step and you discover surprises three weeks into the project - never fun.

Step 2: Design the new system

Map the old system to the new. For 3CX:

• Edition choice - PRO or AI Edition based on feature needs.
• System size - team size tier. Sized by call concurrency, not headcount.
• Hosting - Cloud Phone System Australia hosted in Australian data centres.
• Handset plan - re-provision compatible existing handsets; spec replacements for proprietary ones.
• Number plan - which numbers to port, which to retire, any new numbers needed.
• Call-flow design - auto-attendant, queues, IVR rebuilt in 3CX. Improvements to consider during the rebuild.
• Integrations - CRM, helpdesk, etc - confirm pre-built or scope custom templates.

A good design saves time during build and prevents the “we didn’t have that on the old system but…” requests after go-live.

Step 3: Build and provision

In parallel - typical week 1–2:

• Provision 3CX tenant in the chosen hosting environment.
• Configure call flows - auto-attendant, queues, IVR, after-hours, holiday script.
• Set up users - extensions, voicemail boxes, permissions, SSO with M365 or Google.
• Provision handsets - re-provision compatible existing devices; ship new auto-configured replacements.
• Build integrations - CRM screen-pop, click-to-dial, auto-logging.
• Configure recording - disclosure messages, retention rules, encrypted storage.
• Enable AI features - voicemail transcription, AI Receptionist if AI Edition.
• Set up reporting - wallboards, scheduled reports.

The system runs alongside the old PBX, not replacing it yet.

Step 4: Port numbers

Run in parallel - submitted week 1, completes week 2–3:

• LNP request submitted to current carrier (Telstra, Optus, TPG, or others).
• Carrier processing typically 10–15 business days. Some legacy/regional carriers slower.
• Test calls continue to flow through old system during the port window.
• Co-ordination with carrier on the exact cutover date.

The old PBX stays live. Until the port completes, inbound calls still hit your old PBX; outbound can start flowing through 3CX immediately.

Step 5: Train staff

Run in parallel with build/port - week 2:

• Admins/super-users - 3CX Admin Console, queue management, basic troubleshooting.
• End users - mobile app, web client, desktop client, transfer/hold/conference, voicemail.
• Reception - auto-attendant overrides, holiday menu, after-hours rules.
• Supervisors (contact centre) - wallboards, listen-in/whisper/barge, scheduled reports.

Training works best as 15–30 minute video sessions per role, plus on-demand short videos for self-service. Most staff are productive on 3CX within hours.

Step 6: Cut over and decommission

Typically week 3 (smaller) or week 4–6 (larger):

• Port completion confirmed - inbound calls now reach 3CX.
• Old PBX inbound disabled - to prevent dual ringing.
• Staff fully on new system - all incoming and outgoing through 3CX.
• Monitor for 7–14 days - catch and resolve any teething issues immediately.
• Decommission old PBX - once you’re confident, power down and remove old hardware.
• Recycle hardware - per Australian e-waste regulations.
• Cancel old contracts - carrier, maintenance, support, recording archive.

The decommission step is also when the old vendor’s recurring costs stop. Time it right.

Where migrations go wrong (and how to avoid it)

We see the same three failure modes:

1. Underestimating number porting timelines. Some businesses assume porting is instant. It’s not - 10–15 business days minimum. Plan around it.

2. Forgetting integrations. “Oh, we also use 3CX with that booking system” surfaces three days before cutover. The audit step should catch this. Don’t skip it.

3. Not running parallel. Don’t try to switch off the old PBX before the new one is fully verified. Run both for a week minimum. You will catch issues you couldn’t predict.

We’ve done many migrations. The playbook works.

What CPS handles

End-to-end. Specifically:

• Discovery + audit + design
• 3CX licence + system provisioning
• Hosting in Australian data centre
• Handset provisioning and shipping
• Number porting paperwork with current carrier
• Call-flow rebuild
• Integration setup
• Staff training
• Parallel-run management
• Cutover co-ordination
• Post-cutover monitoring
• Old-PBX decommissioning

You sign off; we deploy.

Frequently asked