3CX migration from another provider

[Madman69]

Hi all, it seems i only have permission to post in this category. hopefully someone can give me some advice.

A client has asked if I can host there 3CX system, I already work with a sip trunk provider for other systems i manage. Asterisk PBX. I have a 3CX account with 1 4SC instance and 1 8SC pro subscription. I have submitted to form to become a partner, I'm not sure if this will be required.

I would like to test the restore, i had hoped this would help me understand the migration process, the existing server is managed by a third party but i have management access.

When I attempt to create a trial instance, I receive the following message:

"You exceeded the maximum number of free subscriptions for this installation type."

Could someone advise how I can obtain a trial/NFR instance for migration testing?

My goal is to migrate an existing customer from a third-party hosted 3CX system. The current installation uses a custom FQDN and DNS managed by the existing provider, so I will not be able to retain the existing FQDN. I could host the replacement system either on-premises using VMware or in AWS. AWS is prefferred.

I have a backup of the existing system and would like to test the migration process by restoring the configuration (extensions, users, ring groups, queues, IVRs, etc.) onto a new 3CX instance with a new FQDN. I do not intend to use the existing SIP trunk and will be porting the numbers to a new provider and configuring a new trunk.

My questions are:

1. What is the recommended approach for restoring a customer backup to a new 3CX instance with a different FQDN?
2. Can I restore the configuration without affecting the live system that is currently using the same licence?
3. Are there any specific considerations when migrating away from a provider-managed FQDN and SIP trunk?
4. What is the recommended process for cutover to minimise disruption?

Any advice from those who have completed similar migrations would be appreciated.

Thanks.

 

[Evolute IT]

1. You'll need to change FQDN and such. It will be a PITA to do, but doable.
2. No you cannot. Never run two systems on the same license.
3. Porting timeline, FQDN switch, phones and users mobile apps reprovisioning. There's a lot.
4. Depends on the setup of the customer and the setup you want afterwards.

Might wanna hire someone who has experience with this, as it seems you don't have much experience with 3CX. You don't wanna mess it up during transition.

 

[Madman69]

Hi, Evolute.

I wouldn't be able to make any changes with the existing sever, if they decide to migrate I assume this will become unavailable shortly after the contract ends.

I had hoped i could restore the backup and then update the FQDN to either the 3CX DNS service or my own, 3CX is preferred as I assumed this will make it easier for lets encrypt ?

The existing 3CX server has approximately 30 users + call groups etc. how would you normally handle this or is the process different for partners?

thanks

 

[Evolute IT]

Hi, Evolute.

I wouldn't be able to make any changes with the existing sever, if they decide to migrate I assume this will become unavailable shortly after the contract ends.

I had hoped i could restore the backup and then update the FQDN to either the 3CX DNS service or my own, 3CX is preferred as I assumed this will make it easier for lets encrypt ?

The existing 3CX server has approximately 30 users + call groups etc. how would you normally handle this or is the process different for partners?

thanks

Plan for downtime. Yes 3CX FQDN is way easier and simpler. For phones, use Option 66 if possible on their network. Apps will need reprovision manually.

You will need to do this in the proper order or you will break something.

The backup will contain everything you need, but it needs to be done manually via command line so that license/FQDN aren't included in the backup, which allows you to change it during reinstall.

 

[Sunil Wadje]

I'd recommend spinning up a new 3CX instance (AWS should be fine) and restoring the customer's backup to that for testing. Since you won't be keeping the existing provider-managed FQDN, you'll need to use a new FQDN and reprovision any phones/apps after the migration.

Testing the restore on a separate instance shouldn't affect the live system and is a good way to validate everything before cutover. I'd also suggest configuring the new SIP trunk and routing ahead of time, then scheduling the number port and final cutover during a maintenance window to keep disruption to a minimum.

As for the trial/NFR instance, if you've already applied for partner status, it may be worth waiting for that to be approved as NFR licensing is typically available through the partner program.