Migration of PBX - FQDN questions

Status
Not open for further replies.

TynesoCOV

Bronze Partner
Advanced Certified
Joined
Feb 3, 2021
Messages
5
Reaction score
0
Hi all,

We're going to migrate our client to 3CX hosted solution from a VM of my clients' previous partner.
I don't have full control over the VM itself, I only have full control over the 3CX management portal on the old partner's VM.

My client provisions over FQDN, restoring a backup onto the 3CX hosted environment should point the FQDN to the new server IP after DNS has propagated as far as I understand it, right? Seeing that I don't control the VM itself, I'd like to leave it running and disable the trunk on it while the migration is happening, is this feasible?

In case of a catastrophic failure during migration, what options do I have to make the FQDN point to the old server again, are there even any options for this? If I search on Google I can only find topics regarding the "activate.3cx.com" FQDN.

Thanks in advance!
 
If it’s a 3CX FQDN it will update its IP limited by the TTL.
https://www.3cx.com/docs/fqdn-management-allocation/

If you just shut down the old server and restore the new from backup it will update. IIRC restarting the server or its services will update the FQDN but if both servers are running they will fight for it and the license.
 
If it’s a 3CX FQDN it will update its IP limited by the TTL.
https://www.3cx.com/docs/fqdn-management-allocation/

If you just shut down the old server and restore the new from backup it will update. IIRC restarting the server or its services will update the FQDN but if both servers are running they will fight for it and the license.
Hi, thanks for taking the time to reply.

I understand what you are saying but the issue is if I turn off the original VM I won't have any way to rollback my change, seeing that I can't start it up again by myself. The VM itself is not in my control.

I was hoping I could restore back-up to the new VM hosted by 3CX -> FQDN points to new 3CX hosted VM -> in case of a catastrophic failure -> delete the new 3CX VM and let the FQDN point back to the original server.

It's not that I'm expecting any real issues but "Murphy's Law" and all that :D
 
You could try stopping 3CX services via the GUI but I don't know offhand if that's enough to get it to stop updating the hostname/IP/license. If it's a Pro license (?) it's a 6 hour TTL anyway so neither migration nor recovery would be instant. If that does work, you'd still need to be able to access the old server's GUI via IP to turn the services on again. Restarting services or setting the IP to Dynamic will update the IP.

Best case is the old partner is helpful...back up, they shut down the old server, and create/restore the new. In that case recovery is that partner starting the VM. (plus the TTL time)
 
I know this post is 6 months old, but I recently came across a similar situation and figured I would share what worked for me.
First, make sure to note the old IP and the new IP that way you can always get to the server if DNS updates unexpectedly.
2nd, start spinning up "aka" restoring a backup to a new server, on your desired hosting platform.
3rd, go to "backup and restore" on the old server and click on the "failover" button on the top right; set it to passive and input the new server IP as well as set a long time-out interval and check all failover tests. (so that basically it won't ever try to take over the new active server)
4th occasionally you will need to reboot the new active/running server depending on the timing of everything.
- it is recommended to be using an Enterprise license when doing anything with failover as it will update DNS much faster.
- if DNS is not updating to the new server you can try switching IP to dynamic on the new server (this can be done by clicking on the IP address from the dashboard) and then restarting your sip and gateway services, waiting some time then setting it back to static. Just for good measure, I recommend rebooting the entire new server one more time from the CLI by clicking on the terminal from the dashboard and typing in "reboot" and pressing enter.
In my experience, this has always worked for me.
Hope this helps someone one day, Best JP
 
Status
Not open for further replies.

Forum statistics

Threads
111,974
Messages
590,081
Members
164,899
Latest member
mazet