Most logical way to take ownership of a current 3CX system

[Iphoned]

Greetings,

We are currently in the process of taking ownership of an existing 3CX system managed by someone else under the same 3CX license and FQDN deserving 3 different location from the same organization. Each of the 3 locations seems to have it's own SBC and using various Yealink phones. We already created a 3CX account and deployed a PBX in Azure. Would someone have a suggestion on which order the different steps should be taken to complete the transfer of ownership for the license with as little downtime as possible ? This is what we currently have in mind (we don't have a 3CX partner account as of yet):

1. Initiate the request to port both current DID to a new sip trunk provider
2. Once the DID number are transferred we ask the current license owner for administrative access to the current PBX and modify the current sip trunk provider to the new one. Can someone confirm that at this point the phone system will be functional without any other modifications ?
3. After that we require administrative access to the PBX again in order to create a full backup of the system including the license and the FQDN
4. We restore the backup into our newly created PBX in Azure. At this point the ip associated to the FQDN should change automatically and the old PBX can go offline correct ? The phone system should still be functional at this step without modifying the SBC right ?
5. Lastly we ask the the current owner of the license to initiate a transfer of ownership to the email address we used to register with 3CX. My understanding is that we will also obtain the current FQDN associated with the license. This should complete the process and we won't have to reconfigure either the various SBC or the Yealink phones right ? We don't want to use a different FQDN or license if that is possible because we don't want to have to reconfigure anything.

What we are not sure is when we first created the PBX on 3CX website it asked if we wanted to restore from a backup, which we answered no since we don't have a backup yet. Would it be best to recreate the PBX from scratch and choosing this option in 3CX beforehand. Because we currently got assigned a license and FQDN but we don't want to use this one, we want to use the already existing one managed by someone else. Or should we start the whole process by initiating a transfer of ownership for the current license and FQDN to make sure the right FQDN is associated with our 3CX account before going on to create the new PBX ?

Thank you for any assistance you can provide

 

[ChrisC_3CX]

Would it be best to recreate the PBX from scratch and choosing this option in 3CX beforehand. Because we currently got assigned a license and FQDN but we don't want to use this one

Yes, one of the reasons being that you cannot change the FQDN once 3CX is installed, so, in essence, you would not be able to use this new system with the old FQDN.

Or should we start the whole process by initiating a transfer of ownership for the current license and FQDN to make sure the right FQDN is associated with our 3CX account before going on to create the new PBX ?

I indeed recommend this is done first. Ideally you would have complete control over the License Key before undertaking this task.

Once the DID number are transferred we ask the current license owner for administrative access to the current PBX and modify the current sip trunk provider to the new one. Can someone confirm that at this point the phone system will be functional without any other modifications ?

I might actually recommend setting up the SIP Trunk(s) for the new provider beforehand. However a few factors might come into play here as it might matter how the SIP Trunks are configured. What SIP Providers are currently in use and to one which are you porting to? Are they all 3CX Supported SIP Providers?

We restore the backup into our newly created PBX in Azure. At this point the ip associated to the FQDN should change automatically and the old PBX can go offline correct ?

The DNS record for the FQDN will indeed be automatically updated though bear in mind that the DNS TTL for a STD and PRO License is 6 hours whereas for an ENT license it's 5 minutes. That said, the change will not necessarily be instantaneous though it is usually much faster than 6 hours(couple of minutes on Google's DNS servers) (if you got STD or PRO that is). On the other hand, there are many things that affect global DNS propagation so it might even be more depending on the situation. We usually recommend setting up your remote sites (where users or SBC reside) to use Google's DNS servers (8.8.8.8) to help speed up this process. Also, we always recommend against running two PBXs with the same License Key at the same time so I suggest on planning some downtime here so that you actually shutdown the old instance first before deploying the new. I guess you could wait for the backup file to upload before shutting down the old instance, especially if we're talking about a large file.

The phone system should still be functional at this step without modifying the SBC right ?

The SBC won't need any modification since you'll be using the same FQDN. Only downtime it will have is the time it will take for the DNS to propagate. What you could try though is, edit the SBC config on the old server (in SIP Trunks section), go to "Settings" and set the SBC's failover IP to the new server's IP. This of course only if you know the new servers public ip before hand (before it gets deployed). Remember to save and push the config to the SBC once you make this change.

Note: You would of course have to remove it once the migration is complete or once you've confirmed the FQDN resolves to the correct(new) ip.


Hope this helps!

 

[Iphoned]

Yes, one of the reasons being that you cannot change the FQDN once 3CX is installed, so, in essence, you would not be able to use this new system with the old FQDN.


I indeed recommend this is done first. Ideally you would have complete control over the License Key before undertaking this task.


I might actually recommend setting up the SIP Trunk(s) for the new provider beforehand. However a few factors might come into play here as it might matter how the SIP Trunks are configured. What SIP Providers are currently in use and to one which are you porting to? Are they all 3CX Supported SIP Providers?


The DNS record for the FQDN will indeed be automatically updated though bear in mind that the DNS TTL for a STD and PRO License is 6 hours whereas for an ENT license it's 5 minutes. That said, the change will not necessarily be instantaneous though it is usually much faster than 6 hours(couple of minutes on Google's DNS servers) (if you got STD or PRO that is). On the other hand, there are many things that affect global DNS propagation so it might even be more depending on the situation. We usually recommend setting up your remote sites (where users or SBC reside) to use Google's DNS servers (8.8.8.8) to help speed up this process. Also, we always recommend against running two PBXs with the same License Key at the same time so I suggest on planning some downtime here so that you actually shutdown the old instance first before deploying the new. I guess you could wait for the backup file to upload before shutting down the old instance, especially if we're talking about a large file.



The SBC won't need any modification since you'll be using the same FQDN. Only downtime it will have is the time it will take for the DNS to propagate. What you could try though is, edit the SBC config on the old server (in SIP Trunks section), go to "Settings" and set the SBC's failover IP to the new server's IP. This of course only if you know the new servers public ip before hand (before it gets deployed). Remember to save and push the config to the SBC once you make this change.

Note: You would of course have to remove it once the migration is complete or once you've confirmed the FQDN resolves to the correct(new) ip.


Hope this helps!

Thanks for the help.

So if I understand correctly the new procedure would be something like this:

1. Start by initiating a transfer of ownership for the license and FQDN we want to take ownership of by giving the email associated with the account we already created at 3CX. I'm guessing that when we will accept the ownership our old licence that we generated by mistake will get removed is that correct ?
2. Require administrative access to the PBX we want to take ownership to download a backup containing the 'License Key Information, FQDN & Conference' only and we also do an additionnal full backup for later use
3. Login on 3CX website with the new account we created containing the licence that we plan to scrap (because we already created a PBX in Azure with the wrong license that we will now remove and start fresh) since we want to use the one from the 3CX system we want to take ownership of. I'm guessing that we don't have to create a new account for that and the licence we created by mistake will be replaced by the one we will import.
4. Go to "My Subscription" and press "Reinstall"
5. At the step "Do you have a 3CX backup you would like to restore? " we select yes and select the backup we created containing the license information
7. When the new PBX is created we then shut down the old PBX
8. We connect to the new PBX and restore a full backup from the original PBX we want to migrate
9. We initiate the request to port the current DID numbers to Skyetel and while we wait we ask those DID to be fowarded to temporary DID at Skyetel in order to be able to use the system right away.
10. We configure the new PBX to use our new sip trunk provider (Skyetel). We are currently not aware of the old sip trunk provider.
11. When the DID are fully transferred we configure those and remove the redirected ones in the new PBX

At this point everything should work without having to reconfigure any SBC, 3CX clients app or ip phones

Did we missed something ?

 

[ChrisC_3CX]

Seems fine for the most part, just a few notes:

1. Start by initiating a transfer of ownership for the license and FQDN we want to take ownership of by giving the email associated with the account we already created at 3CX. I'm guessing that when we will accept the ownership our old licence that we generated by mistake will get removed is that correct ?

Here I'm not sure what you mean by "our license will be replaced". Are you talking about the one you used to deploy an instance in Azure? If yes, then not really, you will have to manually delete that VM from within Azure's control panel.

2. Require administrative access to the PBX we want to take ownership to download a backup containing the 'License Key Information, FQDN & Conference' only and we also do an additionnal full backup for later use

I recommend also asking for access to the OS too.

3. Login on 3CX website with the new account we created containing the licence that we plan to scrap (because we already created a PBX in Azure with the wrong license that we will now remove and start fresh) since we want to use the one from the 3CX system we want to take ownership of. I'm guessing that we don't have to create a new account for that and the licence we created by mistake will be replaced by the one we will import.

You should be able to transfer the customer's existing License Key to your own 3CX customer portal account and then deploy a new machine using that license key from there. The other instance you have created in azure using your own license key you must delete manually via Azure as mentioned above(step 1).

4. Go to "My Subscription" and press "Reinstall"

Correct.

5. At the step "Do you have a 3CX backup you would like to restore? " we select yes and select the backup we created containing the license information

Yes but something you should be wary of hear is the https port to be used. When deploying a 3CX instance using the Customer Portal deployment wizard (formerly known as PBX Express), the https port to be used is by default set to 443. If what the currently running PBX is using is 5001 then make sure you select the checkbox below. It's available in the same section you upload the backup (new customer portal):


Important: If you select a different https port that the one you are currently using then all endpoints (IP Phones, 3CX clients, SBC, etc) will need to be reconfigured from scratch. If you are not using 443 or 5001 right now you will have to use a different deployment method than the 3CX Customer Portal deployment wizard, namely via the Azure's Marketplace.

7. When the new PBX is created we then shut down the old PBX

As mentioned previously we actually recommend shutting down the machine before the new one is up and running to avoid having two machines running with the same License Key at the same time.

8. We connect to the new PBX and restore a full backup from the original PBX we want to migrate

This should not be needed as you've already uploaded the backup during the deployment process(step 5 above)

9. We initiate the request to port the current DID numbers to Skyetel and while we wait we ask those DID to be fowarded to temporary DID at Skyetel in order to be able to use the system right away.
10. We configure the new PBX to use our new sip trunk provider (Skyetel). We are currently not aware of the old sip trunk provider.

In that case you should not need the old SIP Trunk/SIP Provider at all so this seems fine.

11. When the DID are fully transferred we configure those and remove the redirected ones in the new PBX

Sounds good.

 

[Iphoned]

Seems fine for the most part, just a few notes:


Here I'm not sure what you mean by "our license will be replaced". Are you talking about the one you used to deploy an instance in Azure? If yes, then not really, you will have to manually delete that VM from within Azure's control panel.


I recommend also asking for access to the OS too.


You should be able to transfer the customer's existing License Key to your own 3CX customer portal account and then deploy a new machine using that license key from there. The other instance you have created in azure using your own license key you must delete manually via Azure as mentioned above(step 1).


Correct.


Yes but something you should be wary of hear is the https port to be used. When deploying a 3CX instance using the Customer Portal deployment wizard (formerly known as PBX Express), the https port to be used is by default set to 443. If what the currently running PBX is using is 5001 then make sure you select the checkbox below. It's available in the same section you upload the backup (new customer portal):
View attachment 28912

Important: If you select a different https port that the one you are currently using then all endpoints (IP Phones, 3CX clients, SBC, etc) will need to be reconfigured from scratch. If you are not using 443 or 5001 right now you will have to use a different deployment method than the 3CX Customer Portal deployment wizard, namely via the Azure's Marketplace.



As mentioned previously we actually recommend shutting down the machine before the new one is up and running to avoid having two machines running with the same License Key at the same time.


This should not be needed as you've already uploaded the backup during the deployment process(step 5 above)


In that case you should not need the old SIP Trunk/SIP Provider at all so this seems fine.


Sounds good.

Thanks again ChristC for the useful information.

Yes I know that I'll have to delete the current PBX in Azure I just wasn't sure if the new license information would get applied correctly on 3CX end in this scenario since there was already a license applied during our first PBX test deployment. As for port the PBX we want to take ownership of does use port 5001 to access the Web console so thank you for pointing that out I will definitely check that option. As for uploading backup during the deployment process I think the size of the backup is limited to 1024MB using this method and I am afraid the current backup for this PBX is higher that this. If it is higher then how should we proceed ? Start by restoring only the minimum requirement first during initial deployment ('License Key Information, FQDN & Conference') and then once the new PBX is up perform a full restore from the new PBX web console ? The current owner also didn't gave us the information to log directly into the various Yealink IP phone, do we need each of those phone credentials or are those saved directly in PBX in order to manage those phones directly from the 3CX interface ?

With those last questions answered we should be ready to start the migration process, thank again ChristC

 

[ChrisC_3CX]

As for uploading backup during the deployment process I think the size of the backup is limited to 1024MB using this method and I am afraid the current backup for this PBX is higher that this. If it is higher then how should we proceed ? Start by restoring only the minimum requirement first during initial deployment ('License Key Information, FQDN & Conference') and then once the new PBX is up perform a full restore from the new PBX web console ?

In that case what I recommend you regarding the restore process is:

• Take a full backup from the current 3CX PBX excluding License Key Information.

• Deploy a machine via the customer portal using the transferred Key and select "Restore backup" so that you can then specify HTTPS port 5001 but DO NOT upload the backup. This will deploy a new machine from scratch with no config.

• Once the machine is up and running you can upload the backup that does not contain the License Key information and restore on the already running PBX.

Just make sure that:
1. The backup was taken from a PBX running v16.0.8.9 or higher.
2. You place the backup in the new PBX's backup location (default: /var/lib/3cxpbx/Instance1/Data/Backups)
3. The backup file has been provided with the following permissions:

-rw-r--r-- 1 phonesystem phonesystem

4. You should then be able to restore from the "Management Console >> Backup and Restore" section.

The current owner also didn't gave us the information to log directly into the various Yealink IP phone, do we need each of those phone credentials or are those saved directly in PBX in order to manage those phones directly from the 3CX interface ?

IP Phone credentials are saved in the backup yes. It goes without saying that to access the IP Phone UI via the Management Console the IP Phone must be Local to the PBX and of course provisioned using the Local LAN provisioning method.

 

[Iphoned]

Can I just make a full backup excluding recordings, choose that one during initial deployment and after that restore a second backup containing only the recording from the new running PBX ?

 

[ChrisC_3CX]

Can I just make a full backup excluding recordings, choose that one during initial deployment and after that restore a second backup containing only the recording from the new running PBX ?

Yes you can, you can also just move the recording to the recordings folder after the PBX is up and running. The latter because you may not have recordings in the backup, but they are still indexed in the database.

So, to recap:

1. Transfer the License Key's ownership. You may do this from the old customer portal, just login, click on "old portal" in the upper right corner, go to Keys, click on the key and then "transfer ownership".

2. Go into the current "PBX >> Settings >> License" and click on "Refresh License Key Information". Make sure you see new registration details here.

3.
a. Take a backup excluding recordings but including License Key Information. Move it offsite to a safe location.
b. Take a second backup containing everything including recordings and move it to a safe location off the machine. Alternatively, just copy all recordings from the recordings folder to a safe location off the machine. You can find the recordings path in "3CX MC >> Reporting >> Recordings >> Location".

5. Login to Customer Portal with your own account (new owner of the key), go to subscriptions, find the key and Install.

6. Select "Yes" when it asks if you want to restore and then upload the backup file excluding the recordings. Also check the "HTTPS Port 5001" option.

7. Once the PBX is up and running shut down the old machine.

8. Upload the backup that includes the recording files and restore, or, upload or recording files into the recordings path (default: /var/lib/3cxpbx/Instance1/Data/Recordings).

9. Do a Google DNS query for the FQDN and make sure you see the new IP. This might need some time, especially for it to propagate to your remote sites.

 

[Iphoned]

Just to be absolutely sure, the account to where the key will be transferred is NOT a partner account so we don't have access to the partner portal. The key will be transferred to an existing single account which already have a different key. From what I gather this won't be an issue and the transferred key will overwrite the current key of the existing account is that correct ? Thank you

 

[ChrisC_3CX]

From what I gather this won't be an issue and the transferred key will overwrite the current key of the existing account is that correct ?

Not to worry, this won't be an issue. It won't overwrite the existing key though, you will simply end up with two, regardless of whether it's a partner account or not.