Strange Instance

[BCS-Tech2]

I have a customer that has on premise 3cx running V16. They currently have about 15 DID's. The company is splitting up and one office is taking about 8 of the DIDs and becoming a separate company but taking the existing FQDN of the on premise 3CX. To make matters worse, the SIP trunk provider that is currently being used is not approved for 3CX hosted service.

So in the end, I need to have 2 separate companies with 2 separate 3cx systems and be able to be Bridged so they can still do Extension dialing.

This is what "I" think should happen. Please comment on what you think.

1. Move existing DID's to new SIP provider that can be hosted at 3CX cloud service in future. Add this new SIP provider to existing on premise system so they can still stay online.
2. Create new instance at 3CX hosted for new company
3. Do a backup of existing on premise system.
4. Setup 3CX SBC at location that is going to be changed to new company.
5. Restore backup to hosted instance
6. Remove SIP trunk and migrated extensions from the old on premise system. New instance should be online and receiving calls.
7. Remove migrated extensions from the original on premise system
7. Bridge the two systems.

Any suggestions would be greatly appreciated. All of this work will be done on weekends so not to interfere with daily operations. So I want to make sure I understand the steps and not get stuck someplace needing additional help to get out of a bind during off hours.

Thanks

 

[Alphabetic]

When you do the backup, exclude the license and FQDN details.

porting the number might take a while so you might have to set up forwarding over the bridge until it's gone to the new provider.

 

[BCS-Tech2]

I will put that in my notes.

 

[BCS-Tech2]

If the numbers are already ported to a sip provider compatible with both instances, then wouldn't just changing the server that connects to the SIP provider system be all that is required to move the numbers from one instance to another?

 

[Alphabetic]

You said you were moving to a compatible SIP provider.

The DIDs will need to be ported to new provider.

You will then register PBX2 with the supported SIP provider and calls will flow through that.

 

[BCS-Tech2]

Agreed, but I would like to do this in two steps.

Get the numbers ported to the new provider and get that sip installed on the old system (PBX1) and make sure all is good. Let that percolate for a week or so. This part should be transparent to the employees making phone calls.

Then on a weekend, crank up the new instance and move the sip trunk from one PBX1 to PBX2. And do any other work required to get the new PBX2 online and making and receiving calls.

 

[Alphabetic]

Yes thats doable.

From what I read, it didnt read like you wanted to have the 2 SIPs running off the one beforehand.

 

[BCS-Tech2]

Just checking, Can a hosted 3CX Pro version be bridged to an on premise 3CX Pro system?

 

[Alphabetic]

Yes as long as they're running the same build and version and not the free edition.

https://www.3cx.com/3cxacademy/videos/advanced/3cx-bridge-configuration/

 

[BCS-Tech2]

So I will need to upgrade the PBX1 (original) to V18 at the same time PBX2 goes hot? The system is currently V16.

 

[NickD_3CX]

So I will need to upgrade the PBX1 (original) to V18 at the same time PBX2 goes hot? The system is currently V16.

That is correct, yes. You should consider setting Automatic updates on both your 3CX systems so that it occurs at the same time for both so you don't ever be in a case where one is on a different version than the other.

 

[BCS-Tech2]

Automatic updates do not apply for on-premise systems when the update changes the version number. Automatic updates can be automatically applied when the update just changes the revision number of the version currently installed.

Hosted systems at 3CX can do an automatic update from one version number to next.

Found the above out the hard way.

Thanks

 

[NickD_3CX]

That it is the case for major releases (e.g. V16 to V18) on Windows, yes. FYI, it doesn't happen automatically on Debian either, you have to manually trigger it, but the process is significantly more straight forward.

A suggestion would be, make your on-prem installation a Debian too!