Moving Corp Office - need to move v18 PBX Server

[Peterferr]

We are moving our Corp office in a couple weeks and I need to move the PBX to the new data center.
Question: Can I just change the public IP address since we are using the 3CX FQDN?
Question 2: I also need to change the LAN IP address since it will be moving to a new segment.
Question 3: Is there anything I need to do on the endpoint phones since they are scattered throughout the state?

Thanks in advance.

 

[bitn2]

On which update are your pbx? Are the phones remote or local? How are they provisioned, over ip or fqdn?

 

[Peterferr]

Version 18 Build 9
The phones are remote and I believe they are provisioned by IP address of the PBX Server over Office-Office VPN connections.
We do not use SBCs.

If we change the IP address of the PBX will the phones stop working or if we reboot them will they find the new IP Address?

 

[jed]

If they are on FQDN, then there should not be a problem.
Ahead of the move, please change your IP Settings to Dynamic on the existing server; this will ease the Public IP Change (And you can change back after the move when the Server has the Public IP).
Another thing to note is that a 3CX PRO has a 6-hour TTL, whereas ENT only has 5 minutes for the IP to update in the DNS Server.

 

[bitn2]

If the phones are provisioned over ip, they will stop working. They cant get the new internal ip. This is why split dns is the way to go. For v20 it is neccessary anyway.

This is not build 9, its update 9. Which build are you on? Should be 35.

 

[Peterferr]

Build 31.
Is there something I can change now with the provisioning before we pull the plugs and move it?
I.e. Create a FQDN for provisioning or something Internal?

 

[VoIPTools]

Another question is why you are still on V18? I assume you are aware that your version of 3CX is no longer supported. That means you are about to make significant changes to your production 3CX environment with no ability to request help from 3CX. If you get into trouble with this migration you are screwed. That is not a situation I would be happy about as a business owner, and neither should you.

 

[bitn2]

The biggest problem is your pbx can not be activated again. You didnt update to the latest v18 before the date.

Your migration now could break your pbx. Anyway, i would now upgrate to v20 and after that migrate to the new location. As your pbx is now out of date, you need to backup and restore to v20.

https://www.3cx.com/blog/releases/v20-upgrade-checklist-faq/

 

[Peterferr]

I inherited this situation. I am new to the organization and need to move this in a couple weeks.
I have been told this by many people including support. So I get it! I just want to move the server now as we have no choice.

 

[VoIPTools]

That is a bummer Peter. Your predecessor did not do you any favors.

If you have the ability to spin up a new VM and keep your existing server intact, that is one thing I would recommend. If everything goes to hell, at least you can fall back to the original server.

Upgrading to V20 now is not a trivial exercise if you have anything more than a basic 3CX environment. I strongly advise you to turn off your phone and your email and focus on what it will take to upgrade to V20 BEFORE the move. Of all the upgrades I have seen in nearly 20 years of supporting 3CX, this is perhaps the most complicated. Lots of wonderful new features, but a lot of mandatory changes to how you approach configuring your PBX.

I do not envy the challenges before you. The upgrade to V20 is a lot of work to ensure you get that done correctly and figure out all the changes, and the move to a new location is never easy either. You have got your hands full and not much time to get both tasks done. We will do our best to help.

 

[Peterferr]

Thanks.
What if I build a new PBX Server and migrate my data to it? Build a V20 in the new Corp Office and then restore the data?
I have been trying to find a vendor to support this, but no one local will touch a local server.
What do you think?

 

[VoIPTools]

You are suggesting creating a new server and installing V20 on this server at the new location, then manually recreating all your users, trunks, routes, etc. This is a good idea. Then you can address all the V20 configuration changes now before you start moving people (phones). Don't touch the V18 server until the cutover.

There are a couple of considerations:

• Do you have a spare 3CX license? You cannot register and run the same key in both places. As soon as you register the new V20 server, your 3CX key will be upgraded to V20 and the V18 server will stop functioning. I do not know how big your 3CX license is (simultaneous calls) but considering the risk to the business, and the cost of a failed migration, purchasing a 2nd 3CX key would be a good investment. Depending on where you are in the licensing renewal period, this may not be very expensive.
  
  
• Starting from scratch ensures a clean install and may, depending on the complexity of your 3CX environment, be the best approach, but you will lose historical data for reporting. If nobody cares about historical reporting, this is what I would do.
  
  
• You can backup your V18 server and restore the configuration on the new V20 (normal upgrade process). But there may be some complexities with the FQDN. Keep in mind this might be a good opportunity to migrate from 3CX on Windows to 3CX on Linux, and 3CX Pro to Enterprise if you want the new AI and API features only available in the Enterprise edition.
  
  
• You still have the issue of registering phones to the new server. Perhaps others can offer more guidance here. Right now your phones are registered to an IP address. But the new server will have a different FQDN (which you should use going forward), so you are going to need to reprovision the existing phones no matter your upgrade or migration approach. The good news is that you now have a test environment where you can work through how to reprovision the phones to the new FQDN in advance of the migration. Reasonable people should understand that a complex move will require some changes.
  
  
• You may be able to bridge the two servers together and gradually migrate users from the old to the new. But be aware that you cannot route an inbound DID to multiple 3CX servers. You will need to setup the same DIDs on both servers, but your carrier will only route the inbound calls to one of the phone systems. Happily, when the time comes, your carrier can re-route calls to the new server and with any luck you will be ready and things will work instantly. I've not tried bridging 3CX V18 and V20 servers. It is not supported, but it may work.

The honest truth is that I do not do 3CX migrations anymore, and have not for years, so I'm sure many others here in the forums can offer more current guidance on how to do this migration. But if you can convince management to do it, purchasing a 2nd key is a really, really good alternative.

 

[Peterferr]

Here's another thought - what if I moved the existing Corp IP Addresses to the new office - preserving all of the IP's for the Servers, etc. The only thing that would change would be the public IP Address - in that way everything is as it is. I believe this is doable given our move timeline..

 

[VoIPTools]

I'm a little embarrassed to say that I'm having trouble poking holes in your proposal.

If all the phones talk over a private network, and the internal IP address of the 3CX server does not change, the existing phones should continue to work since they will be oblivious to the change.

Depending on whether your trunks authenticate by IP or by password, maybe even that would be transparent.

So, if you are absolutely certain that you can reassign the existing subnet at the current PBX location to the new location, at the moment I cannot think of any significant risks. Then it boils down to timing the move and updating the subnets at both facilities. You can change the PBX public address.

Anyone else have any concerns about this approach?

One caution -- while I believe the activation servers will still work, my strong recommendation is that you do not test this theory by pressing the registration button. Pick the existing server up, move it to the new facility, and don't change anything (but the public address). That should be your mantra.

If all goes well, and I hope it does, then your next big task will be upgrading to V20 as quickly as possible. You are in a situation now where if anything goes wrong in this process you are in real trouble. You do not want this exposure to continue for a second longer than absolutely necessary. That's my opinion.

As with any move, it all depends on execution, but unless I'm missing something it sounds like you have come up with the lowest-risk option on your own. Nice.

 

[Peterferr]

I'm a little embarrassed to say that I'm having trouble poking holes in your proposal.

If all the phones talk over a private network, and the internal IP address of the 3CX server does not change, the existing phones should continue to work since they will be oblivious to the change.

Depending on whether your trunks authenticate by IP or by password, maybe even that would be transparent.

So, if you are absolutely certain that you can reassign the existing subnet at the current PBX location to the new location, at the moment I cannot think of any significant risks. Then it boils down to timing the move and updating the subnets at both facilities. You can change the PBX public address.

Anyone else have any concerns about this approach?

One caution -- while I believe the activation servers will still work, my strong recommendation is that you do not test this theory by pressing the registration button. Pick the existing server up, move it to the new facility, and don't change anything (but the public address). That should be your mantra.

If all goes well, and I hope it does, then your next big task will be upgrading to V20 as quickly as possible. You are in a situation now where if anything goes wrong in this process you are in real trouble. You do not want this exposure to continue for a second longer than absolutely necessary. That's my opinion.

As with any move, it all depends on execution, but unless I'm missing something it sounds like you have come up with the lowest-risk option on your own. Nice.

 

[Peterferr]

IT WORKED!

Mic Drop

Pete Out!