Issues - Migrating from Host to Onprem

[Grandozer]

I'm looking for advice migrating a live 3CX system from a hosted environment to an on-premises deployment while keeping the production system running until cutover.
I have already created a separate test 3CX instance using a temporary FQDN (e.g. test-fqdn.3cx.com.au) but have not yet activated the trial licence.

Current Production Environment

• 3CX V20 hosted on a cloud VPS by the previous MSP.
• Production system is currently active and handling calls.
• Phones, SIP trunk and mobile apps are all using the hosted PBX.
• Existing FQDN is e.g production-fqdn.3cx.com.au
• We have access to recent backups and can take a fresh backup before cutover.

New Environment Being Built

• New 3CX VM running on On-premises Hypervisor
• Debian 12 / 3CX V20.
• Intended final IP will be on Voice VLAN.
• Current build/testing to be done on a separate LAN subnet to avoid conflicts.

What Happened During Initial Testing

My first attempt was to restore the production backup directly onto the new 3CX VM while it had internet access. The restore completed, however it appeared to cause issues with the existing hosted system:

• We lost access to the hosted 3CX management portal.
• Phones continued to work.
• The previous MSP had to power-cycle the VM to restore management access.
• It appeared the new PBX may have attempted to process the same licence/FQDN as the hosted instance.

This has made me cautious about performing another restore.

Second Attempt
To avoid this issue, we then tried restoring the backup while blocking internet access from the new VM.
However, the restore failed with:
"Unable to connect to 3CX License Server. Check network connection."
This suggests internet connectivity is required during the restore process. but then it conflicts with the live/production 3CX.

Proposed Migration Approach
I am now considering the following:

1. Build the new 3CX VM on a separate subnet.
2. Use a temporary FQDN and/or trial licence during testing.
3. Restore the production backup to validate:
   • Extensions
   • Ring Groups
   • Queues
   • IVRs
   • Voicemail
   • General configuration
4. Keep the hosted old PBX running as production.
5. On cutover day:
   • Shut down the hosted PBX.
   • Enable the final VLAN/IP and firewall rules.
   • Switch to the production licence and FQDN.
   • Test inbound and outbound calls.

Questions

• Is it safe to restore a production backup using a temporary FQDN and trial licence for testing purposes? Will it restore correctly since the license, FQDN are different and will mismatch?
• Can the temporary FQDN and trial licence later be changed to the original production FQDN and licence during cutover? Is changing FQDN allowed or possible?
• What is the recommended way to prevent the new PBX from interfering with the existing hosted PBX while still allowing the restore process to complete?
• What is the recommended method for restoring a backup from a live production 3CX system to a new on-prem server for testing purposes while ensuring the existing hosted PBX remains unaffected?

 

[KyriacosS_3CX]

Hello,

For an intermediary step while the current PBX must remain up, a command line backup is easier to work with than the full backup provided via the UI: https://www.3cx.com/docs/backup-restore-command-line/

Restoring a backup to an secondary system will always cause some problems, if both are up at once. Any SIP Trunk registrations will be firing off from both causing call delivery issues, as an example.

What exactly do you want to verify on the new system/location before the move? Answering this will help to figure out the best path forward for you. If for example you have certain hours of the day where the system overall is idle, then a full backup -> shutdown current PBX -> restore to new -> test -> shutdown new -> restart current cycle will let you check everything during that window.

The key thing is that you should at no time have two "identical" PBXs up.

If you are not comfortable performing this, you can always reach out to a 3CX Partner local to you than can assist you with the move. https://www.3cx.com/ordering/find-reseller/

 

[Alphabetic]

It depends how many endpoints you have to reconfigure once you've moved to PBX B is how i'd consider the approach.

If you have 4 endpoints moving over then yeah, lets just backup/restore to a new FQDN. However, if you have a lot of phones, mobile apps, soft phones that would need to be reconfigured / factory reset for the new FQDN then you need to ask how much you value your time.

If you have a 3CX AI license you can utilise the failover function, and when you're ready, turn off PBX A, failover to PBX B, wait for DNS to change and off you go, no endpoint reconfiguration. Same can be achieved via a full backup/restore it just takes a bit more effort. https://www.3cx.com/docs/failover/

What you noticed during your test, is that once you restored to PBX B, PBX A stopped working.
This is because, once you restored to PBX B, it reached out to the activation servers and said "G'DAY M8, kangaroo.3cx.au now lives on this IP address". PBX A had to be restarted (or license refresh) so that it could let activation servers know its back on original IP.

What you need to takeaway here is, every time your 3CX does a license refresh, it notifies on what the current WAN IP is so be sure to refresh your license on PBX A whilst you're messing about so it doesnt switch during your testing.