Moving from 3CX to managed VICIdial

This migration is different from moving off a hosted contact-centre platform, and the difference works in your favour. 3CX is a PBX rather than a dialer, and in the normal deployment your phone numbers are not 3CX's to hold - they come from a SIP trunk provider you contract with directly.

3CX says so themselves, in their own marketing: "With 3CX you own the relationship with your SIP trunk provider - not 3CX," and "you own the numbers directly, and you can switch to another hosting provider or even PBX whenever you need." Take them at their word here, because it removes the single slowest step that dominates most migrations.

Still weighing it up? The VICIfast vs 3CX comparison lays out the architecture difference and names the workloads 3CX is genuinely better at.

Most teams should run both

Before planning a replacement, consider not doing one. 3CX is a capable phone system, and VICIdial is a poor substitute for the things a PBX is for - extensions, internal calling, voicemail, an auto-attendant for your main line.

The common arrangement is to keep 3CX for the PBX and add VICIdial for outbound campaigns, with each system on its own trunk and its own numbers. You keep the queues, wallboards and desk phones your office runs on, and you get predictive dialing where the dialing actually happens. Nothing has to be thrown away, and the rebuild below shrinks to just the outbound side.

Full replacement makes sense when outbound is the business and the PBX features are incidental. If you have a busy auto-attendant, a lot of internal extensions, or complex queue logic, the hybrid is usually the better answer.

Why there is probably no number porting

In the standard 3CX deployment your trunk provider holds your numbers, so moving the PBX does not move the numbers. What changes is which machine registers to that trunk and which IP address the provider accepts traffic from.

3CX's own migration guidance describes the safe way to handle it: get your SIP trunk provider "to, at least temporarily, allow both the old and the new public IP Address to minimise downtime." That is the whole cutover for the carrier side - a dual-homed allowlist window, then repoint the registration. It is an afternoon, not several weeks, and it is reversible while both IPs are permitted.

Two caveats. If you bought numbers through a provider that 3CX auto-configured for you, the account is still yours and the same logic applies. And if you genuinely do need to move providers, that is a port and it is measured in weeks - but it is a separate decision from leaving 3CX, and worth not conflating.

What transfers, and what your deployment type decides

The honest version depends on how you run 3CX, and the difference is real.

Self-hosted. You installed it on a machine you control and you hold the root password, so your data is on your own disk. 3CX does note that modifying the system renders the installation unsupported, which matters while you are still a customer but not once you are leaving.

3CX-hosted. Their documentation is explicit: "No remote system-level (e.g. SSH) or web terminal access to the machine," and "paths for recordings and local backups cannot be changed." You cannot go and get files off the box.

That sounds worse than it is. Hosted customers can still take a full backup from the console - 3CX documents clicking Backup Now, enabling the option to include local and temporary recordings, and then downloading the completed backup. So the data is not trapped; it comes out as one archive on 3CX's terms rather than as files you can browse.

SMB Free is a shared multi-tenant instance - 3CX describes it as "a shared instance together with other 3CX users" - so filesystem access is not a possibility there at all.

Two things to know about that backup before you rely on it. It is the container your IVR greetings live in; 3CX documents no separate download for customer prompt recordings. And restoring is version-constrained: 3CX states you cannot restore a backup onto an older version and that you cannot roll a system back to a previous version. Every documented way to read that archive back is a 3CX restore, so treat it as an insurance policy against needing 3CX again, not as a portable export.

Call recordings

There is no bulk download. 3CX documents downloading or deleting a recording one at a time, and while their purge tool does have mass actions, the documented mass actions are deleting and moving - not downloading.

The bulk route out is the remote-storage archive, with one important catch: 3CX states that "archiving a recording will delete the recording from local storage and copy it to the remote storage." That is a move, not a copy. If you archive mid-migration expecting to keep working from the console, you may find it has emptied. Archive deliberately, to storage you control, and verify the far end before you rely on it.

The other route is the console backup with recordings included, which is the practical option for hosted customers.

What you will rebuild by hand

This is where the real work is, and it is worth being blunt: none of it exports into anything VICIdial reads.

Queues. 3CX queues carry a lot of configuration - a long list of polling strategies, plus wrap-up time, maximum callers, priority handling, SLA timers, callback behaviour, comfort prompts and position announcements, with skills-based routing and per-agent skill levels on the higher edition. VICIdial in-groups can express most of the intent, but not by translation. Someone has to sit down with the current settings and decide what each one should become.

IVR / digital receptionist. Rebuilt as call menus on the VICIdial side. Basic trees map over readily; deep nested menus with time-of-day and holiday branching are a genuine project. This is the most common reason teams keep 3CX for inbound.

Extensions and DIDs. 3CX documents CSV import for DIDs but no matching export, so expect to reconstruct the inbound routing map from the admin console rather than from a file.

The FQDN. This one catches people. On hosted deployments the PBX hostname is issued by 3CX and does not follow you, and phone and SBC provisioning is bound to it. Even though your numbers stay put, endpoints need re-provisioning. Budget for touching every device.

On the VICIfast side the rebuild happens in dashboard screens rather than config files: campaigns and pacing, lists and custom lead fields, dispositions, in-groups and call menus, DIDs and inbound routing, trunks, caller-ID groups, agents and user groups, calling windows and holidays. Leads load through a CSV importer that maps your columns onto VICIdial's lead fields, needs at minimum a phone number and a last name, and offers dedupe scoping, DNC skip-or-flag, timezone assignment from area code or postal code, an error report and a ten-minute undo.

Our automated migration reads a standard VICIdial database over SSH. It does not read a 3CX installation, hosted or self-hosted.

The order to do it in

For the hybrid, which is most teams:

1. Ask your trunk provider to allow the new server's IP alongside the existing one.
2. Provision the VICIfast server and configure the trunk.
3. Decide which numbers serve outbound campaigns and route those to VICIdial; leave the rest on 3CX.
4. Build one campaign, import a pilot list, and dial.
5. Scale up. 3CX carries on doing what it already does.

For a full replacement, add:

6. Take a full 3CX backup, recordings included, and store it somewhere you control.
7. Archive or download the recordings you actually need, checking the move-not-copy behaviour.
8. Rebuild queues as in-groups and the auto-attendant as call menus.
9. Re-provision phones against the new host.
10. Run both in parallel until inbound is proven, then decommission.

Hybrid is a day or two of work. Full replacement is paced by the IVR and queue rebuild and by re-provisioning endpoints - not, as is often assumed, by number porting.

What to test before cutover

• Outbound on the trunk from the new IP, while the old IP is still allowed
• Inbound on every number you moved, including out-of-hours routing
• The auto-attendant path end to end, if you rebuilt it
• Internal calling and voicemail, if you are replacing rather than running hybrid
• Dispositions writing back correctly
• Calling windows, holidays and per-state rules
• DNC scrubbing against a deliberately seeded suppressed number
• Recording capture and playback on the new box
• Every re-provisioned handset registering and completing a call

Cost

The two products are licensed on different axes, so compare carefully. 3CX licenses per system on an annual basis, priced by the number of simultaneous calls rather than per seat, across four editions including a free tier for small deployments, with each simultaneous-call tier bundling a user cap. VICIfast bills per server per month - $219 for Growth at a suggested 25 agents, $399 for Pro at 50, $749 for Ultimate at 100 in the US region.

The unit is the thing to watch. Predictive dialing places several calls per agent, so an outbound floor's simultaneous-call requirement is a multiple of its headcount - which climbs the tier you need on a per-call licence while leaving a per-server bill unchanged. That is the actual financial argument for the split, and it is also why the hybrid often costs less than it looks: your 3CX system keeps serving the office at a low concurrency tier while the dialing concurrency lands on hardware you have already paid a flat price for.

For current 3CX prices, check their pricing page directly rather than a figure quoted second-hand here. The comparison is at VICIfast vs 3CX and our grid is at pricing.

Next steps

• VICIfast vs 3CX - per-simultaneous-call licensing versus per-server, and which workload each tool is strong at.
• VICIfast pricing - the plan grid this migration lands on, billed per server.
• Start a 7-day trial - card validated, nothing charged until day 7. Enough to run a pilot campaign alongside your existing 3CX.

Want help scoping the split? Talk to us - scoping costs nothing. A done-for-you migration is a paid onboarding add-on, included free on the top plans.