Upgrade from Self Managed V18 to V20 and Hosted

[Oveis]

Hello,

I am going to upgrade 3CX V18, which currently has a self-managed status, to V20, which will be hosted by 3CX.
After changing the Fully Qualified Domain Name (FQDN), all phones need to be provisioned again. This process will take time, which I don't have, and the phones systems cannot be turned off for even one minute. Additionally, there are several phones located in different places around the state.

Is there an even more efficient way to carry out this upgrade?

Regards,

 

[Evolute IT]

Why change the FQDN? Unless you're currently using a custom one.

 

[Oveis]

Why change the FQDN? Unless you're currently using a custom one.

I have to change the FQDN

 

[Guillaume Bourgeois]

So, buy a separate license and set up a PBX on another VM.



It's like telling a mechanic to replace your car's brakes but not allowing the car to be taken off the road. The solution? Simply buy a new car...

 

[Guillaume Bourgeois]

So, buy a separate license and set up a PBX on another VM.

This way, you can run both PBX systems in parallel without any issues and migrate the phones one by one without any system interruption.

Explain the situation to your SIP provider so they can set up a second trunk for you.
For incoming calls, you can configure a bridge between the two PBX systems to route calls from one to the other using a prefix.

 

[Oveis]

Can we do it via PAT and DNS in the firewall setting, and all incoming calls through the old FQDN / IP address will be routed to the new FQDN and IP

 

[Guillaume Bourgeois]

I've experienced a similar scenario in a previous life (at a previous employer), with 3CX v18.
Where I needed to migrate 300 users, mobile Apps, iP Phone via STUN, iP phone via VPN .
In our case, we had to transition from 3-digit to 4-digit extensions, and we couldn't afford any service interruptions.

So, we set up a second PBX with a different FQDN, with different local iP, different public iP and different Trunk. created a "local bridge", and executed the transition smoothly. For each user we migrated, we configured the DND mode to forward calls to the "new extension." The calls was then redirected via outbound rules through the bridge, reaching the new extension without any issues. The client was very pleased as the entire process was seamless.

The client had no problem paying for the new license, even though the previous one still had 8 months remaining. The cost of downtime would have been far higher than the price of the new license. It was a rewarding challenge.

Can we do it via PAT and DNS in the firewall setting, and all incoming calls through the old FQDN / IP address will be routed to the new FQDN and IP

NO !
Everything is documented in the database, in the 3CX system configuration files, and more. If you attempt to bypass the block by manipulating values in the ADVANCED PARAMETERS (formerly known as custom parameters), everything will break, and the entire system will stop functioning.

Believe me, not only did 3CX warn me not to do this, but I also tried it in a lab with an NFR license... and everything crashed. I had to reinstall everything from OS scratch.

 

[Oveis]

what about this solution:

We can upgrade the self-managed V18 to V20, then install the second V20 PBX as a hosted solution by 3CX with different FQDN, different local iP, different public iP, and different Trunks then configure it as the failover. After ensuring a smooth transition, deactivate the self-managed system and proceed with the hosted setup.

I haven't done a failover so far. Is it possible to do it with different FQDNs and IPs between two 3CX systems?

 

[Guillaume Bourgeois]

what about this solution:

We can upgrade the self-managed V18 to V20, then install the second V20 PBX as a hosted solution by 3CX with different FQDN, different local iP, different public iP, and different Trunks then configure it as the failover. After ensuring a smooth transition, deactivate the self-managed system and proceed with the hosted setup.

...

then configure it as the failover.

However, you will still need a new license.

 

[Oveis]

...


However, you will still need a new license.

I've checked the license. The old one will expire in 2 months.

 

[Evolute IT]

Is it possible to do it with different FQDNs and IPs between two 3CX systems?

Failover is designed for On-prem to On-prem or Cloud to Cloud and requires the use of the same license on both systems, along with the same FQDN.

You'd be better off simply spinning up a new license and restore a backup that doesn't have the FQDN/License in it. This way you can use the new one and setup the new FQDN.

Setup the new trunk, check the devices and then move the phones over.

 

[Guillaume Bourgeois]

Failover is designed for On-prem to On-prem or Cloud to Cloud and requires the use of the same license on both systems, along with the same FQDN.

You'd be better off simply spinning up a new license and restore a backup that doesn't have the FQDN/License in it. This way you can use the new one and setup the new FQDN.

Setup the new trunk, check the devices and then move the phones over.

Indeed, the purpose of FailOver mode is simply to prevent two PBX systems with the same FQDN from being operational simultaneously.

Your FailOver strategy will come into play when transitioning back to "Self Hosted" or "On Premise," ensuring that the local setup is prepared and the switch is made with minimal impact.