# How to Plan a 3CX Office Move Without Losing Calls

*Published:* 2026-09-10
*Author:* Ted

Office relocations tend to be treated like cabling projects, furniture projects, and internet projects. A 3CX move is all of those, but it is also a live voice cutover. Calls, registrations, trunk traffic, mobile apps, desk phones, and emergency dialing all depend on timing and configuration details that are easy to miss when the move checklist is focused on desks and floorplans.

A smoother result comes from treating the phone system move as a staged migration instead of a same-day swap. 3CX supports moving service by restoring a backup to another server or hosted instance, which makes the process very manageable. The catch is that restore operations restart 3CX services, so the cutover plan has to be built around that interruption.

Why a 3CX office move can interrupt calls
-----------------------------------------

A 3CX system can keep working perfectly during normal operations and still run into trouble on move day. The most common issue is not the PBX software itself. It is the combination of SIP trunk routing, DNS updates, phone registration behavior, and network changes all happening at once.

If the new site has a different public IP, different firewall behavior, or different internal DNS handling, [phones may fail to register](https://wearevoip.us/3cx-not-registering-fix-common-issues/) even though the server came up correctly. If the business is still using a PSTN gateway instead of a SIP trunk, the old wiring can become the weak point. If a backup is restored during business hours, active services restart and current calls can drop.

That is why successful moves are usually built around preparation done days before the physical move.

After the core risks are identified, the move plan becomes much clearer:

- backup and restore timing
- SIP trunk testing
- SBC deployment
- DNS propagation windows
- firewall port checks
- emergency location review

Build the new 3CX environment before move day
---------------------------------------------

The safest approach is to create the target environment before anyone unplugs a phone. That target could be a new on-premise server at the new office, a cloud-hosted instance, or a passive standby system prepared for failover. The point is the same: the replacement should exist before the old system is touched.

For many businesses, a [hosted deployment](https://wearevoip.us/we-are-voip-3cx-implementation-service/) creates a simpler cutover. 3CX indicates that a hosted instance can be up shortly after the configuration backup is uploaded, though restore time still depends on backup size and content. That speed helps, but it should not be mistaken for a reason to skip testing. Phones, trunks, DNS records, and app connections still need validation.

A side-by-side plan also gives IT teams room to [test the call flow](https://wearevoip.us/3cx-call-flow-design-service/) without rushing. In practical terms, that means verifying inbound routing, outbound caller ID, voicemail, ring groups, and remote phone behavior while the current office is still operating.

Move scenarioWhat to prepare firstMain benefitOn-prem to new on-premNew server, firewall rules, split DNS, current backupFamiliar setup with cleaner hardware transitionOn-prem to hosted 3CXHosted instance, SBC, tested SIP trunk, current backupFaster site cutover and less hardware at the new officeExisting 3CX with standby/failoverPassive server already restored, FQDN plan, SBC passive IP settingsLower downtime if the active system must be switched quickly3CX backup and restore planning for low downtime
------------------------------------------------

A current, tested backup is the center of the move plan. 3CX supports backups stored offsite or off instance through several destinations, including Remote FTP/SFTP, SMB, Google Storage buckets, Microsoft SharePoint or Microsoft 365, and Amazon AWS S3 buckets. That gives businesses a strong way to keep the recovery file available even if the original office loses access during the move.

The next step is just as important as creating the backup: testing the restore process. A backup that has never been restored is only a theory. Since 3CX states that all services restart during a restore, the business should know exactly how long that interruption lasts in its own environment, with its own data size and call flow setup.

A solid backup plan usually includes these details:

- **Backup location**: Keep at least one recent copy offsite or off instance.
- **Restore test**: Confirm the file actually restores to the target server or hosted instance.
- **Timing window**: Schedule the production restore outside peak calling hours.
- **Rollback option**: Keep the current system available until the new system is verified.
- **Version check**: Make sure the target environment matches the backup requirements.

This is also where a [one-time system review](https://wearevoip.us/we-are-voip-3cx-consulting-service/) can save time. Misdocumented SIP credentials, certificate issues, and FQDN mismatches often stay hidden until move week. Catching them earlier turns the cutover from a gamble into a scheduled task.

SIP trunks, SBC, and FQDN settings to update before cutover
-----------------------------------------------------------

Voice traffic does not care that the furniture arrived on time. It cares whether the trunk, phones, and PBX still recognize one another.

3CX advises businesses using PSTN gateways to [move to a SIP trunk first](https://wearevoip.us/we-are-voip-3cx-sip-trunk-setup-and-testing-service/) and test that trunk on the current on-premise installation before switching. That is a very practical step for an office move. It removes an aging hardware dependency and gives the new environment a cleaner path for inbound and outbound calls.

For multi-phone sites, 3CX also advises [deploying a 3CX SBC](https://wearevoip.us/3cx-sbc-setup-service-remote-office-home-worker-connectivity-that-actually-works/) and reconfiguring phones to use the SBC with the 3CX FQDN. This matters even more when the system is moving into the cloud. Phones that were never placed behind an SBC can become a last-minute problem, especially when NAT and remote registrations change at the new site.

The FQDN deserves special attention. Each 3CX installation requires one, and it is not something that can be changed easily later. If the move includes a new deployment model, the business should decide early whether the same FQDN will stay in place or whether a new naming plan is needed. Internal resolution matters too. 3CX recommends split DNS for on-premise installs so the FQDN resolves to the LAN host IP internally and the public IP externally.

Before the final switch, the following items should already be confirmed:

- **SIP trunk routing**: Inbound DIDs, outbound rules, and caller ID presentation are working on the current system.
- **SBC status**: Phones at the office are already registering through the SBC where required.
- **FQDN plan**: DNS changes are scheduled with caching and propagation time in mind.
- **Firewall readiness**: Required VoIP ports are open and validated at the new site.

A short DNS planning session can prevent hours of confusion. If records are updated without factoring in DNS cache behavior, some phones and apps may point to the old server while others point to the new one. That split state is one of the most common causes of “some calls work, some calls fail” reports after a move.

How 3CX failover reduces office move risk
-----------------------------------------

Failover is not only for outages. It can also support a cleaner office transition.

3CX documents a failover method where the passive server is already restored and prepared. When the active server fails or is switched out, the FQDN is updated to the IP address of the new active server. That model can be very helpful during a planned move because much of the work is already done ahead of time.

There is one critical rule in that process: the previously active server should be shut down after failover to avoid conflict. Running both systems in a confused state can create registration problems and inconsistent call routing.

There is also a smart speed advantage available with SBC planning. 3CX notes that configuring the passive server IP in the SBC settings can reduce switchover delay by avoiding a wait for DNS propagation. For businesses that cannot tolerate long cutovers, that is one of the better ways to keep desk phones reconnecting quickly.

3CX split DNS and firewall checks at the new office
---------------------------------------------------

Even well-run migrations can stumble on basic network changes. A new ISP, a different firewall brand, or a rushed VLAN setup can block ports that worked fine at the old location. 3CX requires proper firewall handling for VoIP traffic, so port validation should happen before users arrive.

That risk is not limited to PBX settings, either; [TeleCo has shown in its review of structured cabling mistakes](https://www.teleco.com/7-structured-cabling-mistakes-that-slow-office-growth/) that hidden patching and labeling problems often surface only after a team is in the space and trying to use live services.

Split DNS is another item that can be missed during an office move. If the internal network does not resolve the 3CX FQDN correctly, local devices may take a longer route or fail to register. That problem often shows up as [intermittent audio](https://wearevoip.us/fix-one-way-audio-in-3cx-calls/), delayed registrations, or phones that work from mobile data but not from the office LAN.

A quick network validation at the new site should cover:

- WAN stability
- public IP details
- firewall port forwarding
- internal DNS resolution
- SBC connectivity
- phone firmware and reprovisioning status

Emergency calling and E911 location updates after an office move
----------------------------------------------------------------

For U.S. businesses, the office move should include a review of emergency-calling settings before cutover. 3CX offers [E911 geolocation features](https://wearevoip.us/e911-for-3cx-service-configuration-testing-and-multi-location-compliance-for-us-businesses/) when supported by the provider and configured correctly. Emergency calls can send a pre-assigned geolocation URL along with other relevant data.

That means the location data tied to a trunk matters. 3CX allows locations to be created per trunk and assigned to users, with [multiple locations available on the same trunk](https://wearevoip.us/best-3cx-setup-for-multi-location-offices/). When the office address changes, those mappings should be reviewed so users, extensions, and emergency-calling data still match the real physical location.

This is not a “later that afternoon” task. If a business has [multiple suites, floors, or remote users](https://wearevoip.us/best-3cx-setup-for-multi-location-offices/) associated with different office addresses, those records should be audited before move day.

A practical 3CX office move timeline
------------------------------------

A phone move becomes easier when each phase has a clear owner and date. Most businesses do better with a phased schedule than a single cutover note in the facilities calendar.

A workable sequence often looks like this:

1. **Two to three weeks out**: Audit the current 3CX setup, confirm license details, export and test backups, review SIP trunk credentials, and verify FQDN, firewall, and DNS design.
2. **One to two weeks out**: Build the target server or hosted instance, deploy or validate the SBC, test the SIP trunk on the current setup, and review E911 location assignments.
3. **Several days out**: Lower DNS TTL where appropriate, confirm the internet circuit at the new site, verify split DNS, and run test calls through the target environment if possible.
4. **Cutover window**: Take a fresh backup, restore to the target, switch trunks or DNS as planned, power down the old active system when required, and validate inbound, outbound, voicemail, queues, and remote access.
5. **First business day after move**: Monitor call quality, registration counts, missed calls, emergency-calling settings, and app behavior across desk phones, mobile clients, and remote users.

When a 3CX hosting partner or system checkup makes sense
--------------------------------------------------------

Some businesses have capable in-house IT teams but [limited time](https://wearevoip.us/best-3cx-features-for-teams-without-a-full-it-staff/). Others do not want to keep a PBX server on-site after the move. Both situations are good reasons to look at outside 3CX support.

A hosted deployment can remove server maintenance from the office checklist. A [one-time 3CX system checkup](https://wearevoip.us/we-are-voip-3cx-consulting-service/) can identify risk items before the move, including DNS concerns, undocumented trunk settings, phones that should be moved behind an SBC, and gaps in emergency-calling configuration. For teams planning new licenses, hosting, or a move from on-premise to the cloud, that kind of review can make the cutover much more predictable.

The strongest office-move plans are rarely the most complicated ones. They are the ones where the backup has been tested, the target is already built, the SBC and FQDN plan are settled, and the emergency address data still matches reality when the first call comes in Monday morning.