Migrating from ViciBox

If you're already running VICIdial on ViciBox, VICIhost, GoAutoDial, or a self-built box, the platform can move you over with a one-click flow. v2a (shipping now) migrates the DB + custom AGI scripts; v2b will background-sync recordings later.

The three stages

1. Probe — read-only inventory of your source box. We SSH in, read /etc/astguiclient.conf, count tables, find any custom AGIs. Your box is never written to.

2. Dump + restore — drain your source (pause campaigns + log out agents), confirm the destructive overwrite, then we mysqldump + upload + restore + IP-rewrite + restart Asterisk on the new box. End-to-end usually under 15 min on a typical box.

3. Cutover — you flip your DNS + your carrier's IP whitelist when you're ready. The new box is at the VICIfast subdomain we provisioned for you.

What v2a moves

• Every vicidial_* MariaDB table — campaigns, lists, leads, users, dispositions, callbacks, in-groups, hot keys, the call log.

• Every custom_* table (custom fields you added to lists).

• Custom AGI scripts from /var/lib/asterisk/agi-bin/ (anything that isn't on the stock VICIdial list — we keep yours verbatim).

• Audio store / IVR prompts (the /srv/www/htdocs/<random>/ dir on ViciBox or /var/www/html/<random>/ on other distros) — included as a third artifact when under 500 MB. Larger libraries fall through to the v2b rsync flow.

• Auto-generated softphones — every migrated VICIdial user gets a fresh WebRTC phone row pointed at the new box's IP. Random per-phone passwords (your customer-facing webphone URL handles the auth server-side).

• Your VICIdial version family is preserved at the data level, then install.pl reconciles the schema with Asterisk 22.5.1 on the new box.

What stays on the dest unchanged (skipped from the dump)

The dest's own box-specific config is preserved — source's values would clobber working state. We skip these 14 tables on the dump side so the dest's existing rows stay intact:

• servers, system_settings, conferences, vicidial_conferences — box-specific paths, asterisk version, conference rooms

• vicidial_server_trunks, web_servers, vicidial_carriers — platform-managed trunk + web config

• phones — auto-generated per migrated user instead

• vicidial_conf_templates — dest has the right WebRTC + pjsip templates

• vicidial_ip_list, vicidial_screen_colors — cleared / per-box UI

• vicidial_live_agents, vicidial_session_data, cron_status — transient runtime state

Four user accounts are also preserved from your dest (snapshot before import, restored after): 6666 (dashboard manager phone), apiuser (VICIfast platform API access), VDCL, VDAD (VICIdial system accounts). Your source's other users all migrate verbatim with their passwords intact.

What v2a does NOT move (yet)

• Recordings from /var/spool/asterisk/monitor / monitorDONE. They stay on your source box. v2b ships background rsync.

• Voicemail from /var/spool/asterisk/voicemail. Same story.

• Audio store over 500 MB — v2a's inline bundle is size-capped. Big libraries get the v2b rsync treatment.

• Plan for this: any new recording your agents make from the moment the new box goes live lands on the new box. Historical recordings stay where they are until v2b syncs them. We don't lose them — they just take longer to move.

Before you click "Start migration"

• Pause every campaign on your source. The admin UI's campaign list → set active = N on each.

• Log out every agent. Have them close the browser tab; the dump won't run with live agents.

• We re-check both at dump time. If a cron auto-reactivates a campaign between your drain and the worker firing, the dump bails with a clear error and you retry.

What you change after migration completes

1. Your DNS / agent bookmarks — point at the new VICIfast subdomain. The dashboard shows the new hostname.

2. Your carrier's IP whitelist — the new box has a different egress IP. Add it at Twilio / Bandwidth / Telnyx / wherever your trunks live. The migration completion screen shows the new IP.

3. Make one test call before bringing agents back. AGI scripts migrated verbatim; carrier reach is the most likely thing to need an update.

Source-box requirements

SSH access as a user that can read /etc/astguiclient.conf (root, or a user with sudo). The probe + dump scripts run via bash -s over SSH — nothing is ever written to your source box's disk outside of /var/tmp scratch (which the dump script cleans up after itself).

Destination-box state

The new box has to be empty — fresh VICIfast install with no real data. We check this before allowing the dump (counts of leads, call_log, users, campaigns, DNCs). If you've already added campaigns / leads to the new box, you'll need to factory-reset it before migrating.

The destructive confirmation

You'll type WIPE in the UI before the dump key is minted. This confirms you accept that your destination's existing VICIdial data will be replaced by your source's. Once the dump starts, the operation is one-way — we can't roll back to the dest's pre-migration state without a factory reset.

If something goes wrong

The migration row holds a typed failure code and the full report. Common failure modes:

• drain_failed — a campaign was active or an agent was logged in at dump time. Drain again, click "Start migration" to mint a fresh dump key, retry.

• upload_failed — your source's network couldn't reach Hetzner Object Storage. Usually a firewall issue; check outbound HTTPS to *.your-objectstorage.com.

• sha_mismatch — the dump file changed in transit. Retry from scratch.

• asterisk_restart_failed — the destination's Asterisk wouldn't come back. Contact support; we'll inspect logs and recover.

For any failure that leaves the destination half-restored, contact support — they'll factory-reset it and you can retry from a fresh probe.