Skip to main content
Migrating your 3CX phone system from an on-premise server to a cloud-hosted VPS is one of the most impactful infrastructure improvements you can make — but it requires careful planning to avoid dropped calls or registration failures during the cutover. The good news is that 3CX has a built-in backup and restore mechanism specifically designed for this scenario. If you follow the steps in this guide in sequence, your team will experience minimal disruption and your phones and mobile apps will re-provision themselves automatically once the new server is live.
Before starting, read through the entire guide and schedule your migration during a low-call-volume window — typically an evening or weekend. Inform your team that there will be a brief service interruption during the DNS cutover step.

​
Before You Begin — Migration Checklist

Confirm the following before proceeding:
  • You have administrator access to your existing on-premise 3CX Management Console
  • Your new cloud VPS is provisioned and running Debian Linux (see Deployment Guide)
  • The new server’s firewall ports are open (5060, 9000–10999, 5001, 443)
  • You have your 3CX License Key accessible
  • You have access to your domain’s DNS management panel (to update the FQDN record)
  • You have noted your existing FQDN and SIP trunk credentials

​
Migration Steps

1

Create a Full Backup on the Existing Server

Log in to your on-premise 3CX Management Console and create a complete system backup. This backup captures everything needed to reconstruct your system on the new server.
  1. Navigate to Settings > Backup and Restore.
  2. Click Backup Now.
  3. In the backup options, ensure the following items are selected:
    • ✅ Configuration (extensions, trunks, call flows, ring groups)
    • ✅ Call Logs
    • ✅ Recordings (if storage allows — or sync these separately to cloud storage beforehand)
    • ✅ License Key binding information
  4. Wait for the backup to complete. Download the .zip backup file to your local computer.
Store the downloaded backup file in at least two locations — for example, your local machine and a cloud storage service like Google Drive or Dropbox. Do not keep the only copy on the server you are about to decommission.
2

Record Your Current Configuration Details

Before touching the new server, write down the following from your existing system:You will need these values during the restore and DNS update steps.
3

Spin Up and Prepare the New Cloud Server

If you have not already done so, deploy a fresh Debian Linux VPS using your chosen cloud provider. Follow the Deployment Guide through the OS installation step — stop before running the 3CX Startup Wizard.Install 3CX on the new server using the Debian ISO. When the installation completes and you access the management URL for the first time, you will see the Setup Wizard — but do not complete it manually. You will restore from backup instead, which populates all settings automatically.
The 3CX version on your new server must be equal to or newer than the version on your old server. You cannot restore a backup from a newer version of 3CX onto an older installation. If necessary, update your old server first, create a fresh backup, then restore on the new server.
4

Restore the Backup on the New Server

On the new cloud server’s Setup Wizard page:
  1. Select Restore from Backup instead of configuring a new system.
  2. Upload the .zip backup file you downloaded in Step 1.
  3. 3CX will extract and apply all configuration settings — extensions, trunks, call flows, ring groups, user accounts, and recordings.
  4. Once the restore completes, log in to the new Management Console with your administrator credentials.
Verify the following in the new console:
  • All extensions are listed correctly
  • SIP trunk configuration is present (the trunk will show as unregistered — this is expected until DNS updates in the next step)
  • Call flow diagrams (digital receptionists, queues) are intact
5

Update Firewall NAT Rules and DNS Records

This is the cutover step — the moment you redirect all traffic from the old server to the new one.Update Firewall / NAT Rules:
  • On your old on-premise router or firewall, remove NAT rules that forwarded SIP (5060) and RTP (9000–10999) ports to the old server’s internal IP.
  • If your new cloud server is behind a cloud security group, confirm inbound rules for those same ports are already open on the new server.
Update DNS: Log in to your DNS management panel and update the A record for your FQDN (e.g., pbx.yourcompany.com.kh) to point to your new server’s public IP address.
DNS changes do not take effect instantly. Depending on your domain’s TTL (Time To Live) setting, propagation can take anywhere from a few minutes to 48 hours. To minimize this window, lower your FQDN’s TTL to 300 seconds (5 minutes) at least 24 hours before your scheduled migration. After the migration is confirmed stable, you can raise the TTL again.
Use a DNS propagation checker (e.g., dnschecker.org) to monitor when your FQDN resolves to the new IP across global DNS servers. Do not decommission the old server until propagation is confirmed complete worldwide.
6

Re-provision IP Phones and Apps

One of 3CX’s most convenient migration features is its centralized provisioning URL. When your FQDN DNS record updates to the new server’s IP, all registered devices — IP desk phones and the 3CX mobile and desktop apps — automatically detect the configuration change and re-provision themselves without any manual intervention.For most deployments, phones and apps will re-register within minutes of DNS propagation completing. Users may see a brief “re-registering” status on their phone display or app.If a device does not auto-reprovision:
  1. On the phone’s LCD menu, navigate to the provisioning URL settings and confirm it still points to your FQDN (not a hard-coded old IP).
  2. Trigger a manual reprovision from the phone’s menu, or remotely via Extensions > [Extension] > Reprovisioning in the 3CX Management Console.
Yealink, Fanvil, and Polycom phones provisioned via 3CX’s built-in provisioning server will reprovision automatically. Phones that were configured with a static IP instead of the FQDN will need to be manually updated.
7

Verify and Decommission the Old Server

Run the following verification tests before taking the old server offline:
  • ✅ SIP trunk shows Registered (green) on the new server’s dashboard
  • ✅ Inbound calls to your DID numbers reach the correct extensions/queues
  • ✅ Outbound calls from extensions connect successfully
  • ✅ Mobile app users can make and receive calls over both Wi-Fi and cellular data
  • ✅ Call recordings are being saved (check a test recording in Reports > Call Logs)
  • ✅ Bitrix24 or other CRM integrations are logging calls correctly
Once all tests pass and you have monitored the new system through at least one full business day, you can safely power down the old on-premise server. Keep the server accessible (but powered off) for at least two weeks as a fallback, then decommission it permanently.
KHCOLO can assist with post-migration monitoring and provide a managed support arrangement to ensure your new cloud-hosted 3CX system runs reliably. Contact the KHCOLO team for details on ongoing managed services.

​
Zero-Downtime Cutover Tips

Achieving true zero downtime requires a few extra steps that go beyond the standard migration:
  • Run both servers in parallel briefly — Keep the old server running while you validate the new one. During this window, all live calls stay on the old server.
  • Pre-lower your TTL — Set your FQDN TTL to 5 minutes at least 24 hours before migration day so DNS switches take effect quickly when you flip the record.
  • Use 3CX’s built-in tunnel — The 3CX tunnel (port 443) ensures mobile app users stay connected even in mixed-network environments during the switchover.
  • Communicate with your team — Send a brief message to all staff explaining that phones may show “re-registering” for a few minutes during the cutover window. This prevents unnecessary support calls.
  • Schedule during off-peak hours — Even with careful preparation, a brief 2–5 minute registration gap is possible during DNS propagation. Scheduling this at 8 PM rather than 8 AM eliminates any customer impact.