Migrating from a ViciBox install

One thing to get straight before the steps, because it changes what this page is. ViciBox is a free openSUSE-based installer ISO from the VICIdial maintainers, not a hosting service - the VICIfast vs ViciBox comparison covers that in detail, and hosting from the same group is sold separately as VICIhost. So "migrating from ViciBox" means moving a box you or your host built from that ISO. The software underneath is stock VICIdial, which is why most of this can be automated.

We have an automated migration for exactly this: Migrate from ViciBox, run from the server's dashboard. It is not a one-click, no-downtime move, and this page is the honest account of where the work and the downtime actually are.

What transfers

The destination pulls a mysqldump straight from your source box over SSH and imports it. What lands:

• Campaigns and every campaign-scoped table, lists, leads (vicidial_list), your custom_<list> tables and list-field definitions
• Agents (vicidial_users) and their user groups
• Statuses and dispositions, including your categories and status groups
• Your DNC list (vicidial_dnc)
• Inbound groups, inbound DIDs and call menus - your IVR trees come across
• Phones with their identity intact: extension, login, password, conf_secret, full name, outbound caller ID, voicemail settings
• Call history - vicidial_log, vicidial_closer_log, vicidial_agent_log, recording_log, call_log and their _archive twins. Reports for pre-cutover dates keep working
• Timeclock, audit and time-off logs
• Non-stock AGI scripts from /var/lib/asterisk/agi-bin. Stock VICIdial AGIs are skipped - the new box already has current ones
• Recordings from /var/spool/asterisk/monitor, /var/spool/asterisk/monitorDONE and /var/spool/asterisk/voicemail, plus the audio store under your webroot

What doesn't transfer

The new box is authoritative for its own identity, so these tables are deliberately never copied - and this list is where migrations surprise people:

• Your carriers and trunks. vicidial_carriers, vicidial_server_carriers and vicidial_server_trunks are all skipped. Nothing about your SIP connectivity moves.
• /etc/asterisk. No file under it is copied. Hand-written dialplan, custom contexts, an edited manager.conf - none of it comes over. The new box keeps the configs it was provisioned with.
• servers, system_settings, web_servers, conference and conf-template tables, screen colours, and the IP-allowlist tables (which are cleared, with allow_ip_lists forced off).
• Runtime state - hopper, live agents, auto calls, parked channels, sessions. All of it points at processes on a box you are leaving.
• Custom sounds in /var/lib/asterisk/sounds/custom. The probe measures that directory so you know its size, but nothing copies it. Move it yourself if you use it.
• Your VICIdial version. The new box runs the VICIdial 2.14 series, taken from VICIdial's own SVN trunk when its image was baked, on Asterisk 22.5.1 and Ubuntu 22.04. The exact revision is recorded on the box in servers.svn_revision. The restore keeps the destination's newer schema and imports your rows into it. You are not getting your old build on new hardware - you are getting your data on a current build.
• Your DIDs. Those live with your carrier and always did.

What you rebuild

Budget real time for these. They are the migration.

1. Trunks. Re-add every carrier on the new box. The dashboard has partner templates for common carriers; otherwise it is the same PJSIP details your old box had.
2. Carrier IP allowlist. Your new box has a different egress IP. Until your carrier accepts it, nothing dials.
3. Custom dialplan. Anything you kept in /etc/asterisk has to be re-applied by hand. Copy it off the old box before you cancel it.
4. Phone protocol. Every migrated phone except the platform's own 6666 is switched to PJSIP with the WebRTC template and is_webphone set. Agents on softphones through the browser are fine; anyone on a chan_sip hardphone needs reconfiguring.
5. Anything outside the box that knew its address - a CRM reading the old MySQL directly, webhooks, monitoring, bookmarks.

Order of operations

The dashboard walks these as Connect → Paste key → Review → Migrate → Sync → Done.

1. Order the destination server first. It has to be fresh - the restore refuses to run on a box with call history already in vicidial_log or call_log. Provisioning takes about 40 seconds.
2. Connect. Enter the source hostname, SSH port and user. We mint a one-shot ed25519 keypair with a 15-minute TTL and show you the public half to append to ~/.ssh/authorized_keys on the source. If your source firewall blocks us, the screen shows the destination IP and paste-ready firewall-cmd / iptables rules.
3. Probe. Read-only, no writes of any kind. It reads DB credentials from /etc/astguiclient.conf (the VARDB_* lines) rather than asking you for them, then inventories every vicidial_* and custom_* table with row counts and sizes, measures the recording and voicemail directories, finds the audio store under /srv/www/htdocs or /var/www/html, hashes any non-stock AGI scripts, reads your servers rows, confirms Asterisk and the VICIdial build, and checks you have at least 10 GB free on /var/tmp. You review that manifest before anything else happens.
4. Drain the source. This is where dialing stops. The copy will not run while vicidial_live_agents has rows or any campaign is active = 'Y' - the worker re-checks at run time and bails. Log every agent out and set every campaign inactive.
5. Confirm. You type WIPE to acknowledge that the destination's database is about to be replaced. That is the point of no return for the destination, not for your source.
6. Migrate. A second one-shot key is issued, this one with a 4-hour TTL because the recordings sync reuses it. The destination then SSHes back to your source and streams mysqldump | gzip directly across - no object storage in the path, no scratch file on your source, and --skip-lock-tables so your source database is never locked. Non-stock AGI scripts follow as a tarball, and the audio store rides along if it is under 500 MB.
7. Restore. On the new box: cron and the astguiclient daemons are stopped so the keepalive watchdog cannot race the import, a full dump of the destination is taken to /var/tmp first, the destination's tables are truncated, your rows are imported into the destination's schema, platform-owned rows are put back, install.pl is re-run, every server_ip reference is rewritten from the old IP to the new one, vicidial.service is restarted, and it smoke-tests the Asterisk CLI and a database round-trip. If any of that fails, the destination is restored from the dump taken in the first step.
8. Sync recordings. The destination rsyncs them from your source with --partial --append-verify, so an interrupted run resumes rather than restarting. You can set a bandwidth cap. This runs in the background - the new box is usable while it works.
9. Cut over. Update your carrier's IP allowlist, point DNS and bookmarks at the new hostname, then let agents back in.
10. Clean up. On a successful sync we remove our own public keys from your source's authorized_keys. If that step could not reach your box, the dashboard shows you the one-line sed to run yourself.

Limits worth knowing before you start

• Very large databases are refused. The tool estimates the dump from your table sizes and declines anything projected to run past roughly two hours, pointing you at support for a manual migration instead. The probe tells you your total table size, so you find this out before you drain anything.
• IPv4 sources only. An IPv6-only source box is not supported.
• Account owner only. Sub-users cannot run a migration.
• Do not cancel mid-copy. A cancelled migration can leave the destination half-restored, which means a factory reset before you can retry. Let it fail on its own if something goes wrong - it rolls the destination back for you.

About downtime

Do not plan this as a zero-downtime move, because it isn't one. Dialing stops when you drain the source in step 4 and does not resume until your carrier accepts the new IP. Between those points sit the database copy - which scales with your table sizes, and vicidial_log dominates on a long-running box - plus the restore, your trunk rebuild, and however long your carrier takes to apply an allowlist change. Recordings are the one part that genuinely runs in the background afterwards.

Book a maintenance window outside dialing hours and keep the old box until you have finished testing. The pre-import dump we take of the destination protects the destination, not your data - your rollback is the old box, still switched off but intact.

What to test before you point agents at it

• Admin loads over HTTPS, and your campaign, list and lead counts match the probe manifest
• One outbound call on every trunk you rebuilt, not just the first one
• One inbound call to each DID and in-group, including your IVR paths
• A recording completes, lands in monitorDONE, and plays back from the report
• A real agent logs in on the phone they will actually use - remember the PJSIP/WebRTC overlay
• Your non-stock AGI scripts are present and executable in /var/lib/asterisk/agi-bin
• A report over a pre-cutover date range returns the same numbers as the old box
• Your DNC list count matches what the probe found

Next steps

• VICIfast vs ViciBox - the free installer ISO versus managed hosting, and where the ISO still wins.
• Migrate from ViciBox - the automated migration described above.
• VICIfast pricing - the plan grid this lands on, billed per server.
• Start a trial - provision the destination box before you drain anything.