Migrating 3CX Cloud Server v14 instances to v15

The following documentation will guide you through the process required to successfully move 3CX Virtual PBX Server v14 (multi tenant) to Cloud Server v15 (single host). The destination server may be running Windows or Linux host OS. The backup is compatible with both platforms. Also in a later stage the backups can be moved from a Windows based v15 to a Linux based host and vice versa. The decision is yours.

Migrate Virtual PBX Server v14 to Cloud PBX v15

On this topic

Migrate Virtual PBX Server v14 to Cloud PBX v15

Abstract

Preparation

Step 1: Create Backup

Step 2: Create Single Cloud VMs

Step 3: Restore

Step 4: DNS Work

Step 5: Switch

IP Phones

3CX Client

3CX SBC

3CX PBX

Abstract

Below can be seen the current hosting model of v14 and  v15.

In this tutorial we assume migrating 3 tenants from the existing v14 server to v15 dedicated hosts. The customers are defined as:

  1. Customer A
  • Instance: Slot 9 (Sip: 13060 Tunnel: 13090)
  • FQDN: stefan.3cx.com
  • Current External IP: 1.2.3.4
  • Uses: STUN IP Phones and 3CX Clients
  1. Customer B
  • Instance: Slot 8 (Sip: 12060 Tunnel: 12090)
  • FQDN: nicky.3cx.com
  • Current External IP: 1.2.3.4
  • Uses: 3CX Clients
  1. Customer C
  • Instance: Slot 7 (Sip: 11060 Tunnel: 11090)
  • FQDN: pierre.3cx.com
  • Current External IP: 1.2.3.4
  • Uses: 3CX SBC and 3CX Clients

Preparation

You should be already familiar with the install and restore process of v15.

Before the upgrade also ensure the following points:

  • All Endpoints are provisioned to the default method of 3CX
  • All Endpoints (IP Phones) are using the latest available Firmware
  • All SBCs are using FQDNs to connect to the Instance
  • Access to Public DNS server to create new A Records
  • All instances must be licensed, customers running on “Free” must order first a “3CX PBX Edition” key (it is free).

Step 1: Create Backup

On the existing multi tenant cloud server start the “3CX Virtual PBX Manager”“Server Backup & Restore” Tab and create a backup of all Instances.

Once created, unzip the backup file. The content are folders for each tenant of v14 labeled with the instance slot. Within the folders are the individual backups of the instance in zip format. Take those backups and place them in a location for restore purposes at a later stage.

Note: The Config Service and the Database Service for each created instance must be started to be able to take Backups of all Instances at once.

Step 2: Create Single Cloud VMs

Now it is time to create the new v15 hosts. V15 gives you multiple different options of installation.

For this example we use Google Compute Engine and create via the provided script 3 new VMs and preinstall 3CX in it. You may deploy the VMs in your existing datacenter. Each VM will have a dedicated public and private IP address.

Step 3: Restore

Take now the backup of the individual instances and load them into each instance.

If your v14 virtual pbx server was covered by a publicly trusted wildcard certificate”, it is up to your liking if you continue to maintain all the certificates and renewal process of all instances or you can delegate this to 3CX while switching to a 3CX FQDN.

Important Note: The FQDN you will give the instance MUST be different to the one the instance has used in v14. Therefore we use in our example stefan.3cx.com ⇒ stefan2.3cx.com and pierre.3cx.com ⇒ pierre2.3cx.com

Select an HTTP(s) port to your liking, for the migration this has no effect at a later stage…

Note: The 3CX default provided Gcloud instance creation script does not cater for any other ports than 5060/5090 and must be added to the firewall rules!

Info: This restore is now alive and active. In case VoIP Providers are used, both PBX Systems will start receiving calls not under the same public number. Until the migration is completed set all SIP trunks to be disabled!

Step 4: DNS Work

To switch to the new v15 PBX, a new A record needs to be present, pointing to the new 3CX v15 public IP address of each instance.

  1. FQDN: stefan2.3cx.com
  • To A 2.2.2.2
  1. FQDN: nicky2.3cx.com
  • To A 2.2.2.3
  1. FQDN: pierre2.3cx.com
  • To A 2.2.2.4

Step 5: Switch

IP Phones

Depending on whether you have most internal devices (VPNed) or STUNed the order of the following varies based on your setup. The procedure is however the same.

On the Virtual PBX v14 server open the IIS Manager. Let’s assume we migrate instance 9 first. Open Sites ⇒ instance09 ⇒ provisioning. Set “HTTP Redirect” and point it to the new internal http://ip/fqdn:port or external https://fqdn:port followed by /provisioning.

Once set, open the phones tab of the instance in v14, select all phones and press “Reprovision”. All internal phones will move to the new server. Now replace the URL with the external provisioning path and repeat the reprovisioning.

3CX Client

The 3CX Clients do not follow HTTP redirection. Therefore re-issue a welcome eMail to the users to re- import to the 3CX Client.

3CX SBC

3CX SBCs will need a small change in the SBC config file. Open the config file located in: “c:\programdata\3cxsbc\3cxsbc.conf” and change TunnelAddr=pierre.3cx.com (instance 7) to the new FQDN (pierre2.3cx.com) and alter the TunnelPort=11090 to 5090. Restart the SBC service to connect to the new instance.

Also update the SBC to the latest v15 version!

3CX PBX

Set now the v14 Trunks to “Disabled” and enable the sip trunks on v15. Leave the instance running to ensure that all devices have taken the new provisioning url. Once completed, shut the instance down.  

Liked this article?


Get notified of new articles
or share
You might also be interested in:

Leave a Reply

  1. Will this method cause any issues with 3CX licensing since both instances will run simultaneously for the migration period?

    November 8, 2016 at 2:35 pm Reply
    • for the momentarily usage it will okey but not for the long run (+-2 days) as the key will be moved to a new server and therefore becomes void on the next key check on the old system.

      November 8, 2016 at 2:53 pm
  2. Pingback: 3CX v15 VPS заменяет мультитенантную версию 3CX Phone System 14 - itfm.pro

  3. The problem is , with this new deployment model, we waste alot of public IP. I Think we should have a way to use ip one to deploy for multiple instances.

    November 21, 2016 at 6:43 am Reply
    • Yes agreed. But it is the way forward. You can add this IP cost to the new charge. Soon there will be IPV6 and this problem will go away.

      November 21, 2016 at 10:15 am
  4. Bora

    Does the Cloud VM require SSD or can the VM use standard SATA HDD? Any performance if we use SATA HDD VM?

    December 1, 2016 at 9:58 am Reply
    • it is more a question what the customer will do with this instance. If they have lots of call recording then def. SSD. SSD are inexpensive now to run on in hosting solutions but they are not a requirement to do so for all customers.

      December 1, 2016 at 11:24 am
  5. justin

    we migrated from v14 to v15 for our cloud hosted folks and kept their ports the same. just create the ports in the google firewall, change it on the phone system (we are linux hosted), and the phones moved right over with the DNS change. only thing was desktop apps had to be re-linked.

    December 3, 2016 at 3:48 am Reply