Migrating from GOautodial

GOautodial runs on VICIdial's own tables, so the data move is standard. What you actually lose is the interface and the REST API, not the data.

A correction first, because our own earlier version of this page got it wrong and the mistake would have cost you a weekend.

GOautodial (often written GoAutoDial) is not a fork of VICIdial with a diverged schema, and migrating away from it does not involve schema mapping. The project's own README lists Vicidial among its core components, its repository ships an astguiclient.conf-sample, its credits page links to vicidial.org, and its interface reads and writes VICIdial's own tables. The project does not describe itself as a fork. The accurate description is a web interface and API layer sitting on top of a VICIdial install - which is covered in more detail on the VICIfast vs GOautodial comparison.

That has a practical consequence. Your data is already VICIdial data, so the move is an ordinary VICIdial-to-VICIdial migration and the automated tooling handles it the same way it handles any other source. What you are giving up is the interface on top, and any integration written against their REST API. That is the decision worth thinking about, not the database.

What transfers

The destination reads database credentials from /etc/astguiclient.conf on your source box, streams a mysqldump over SSH and imports it. Because the tables are VICIdial's, everything lands where the new box expects it:

Campaigns and their settings, with every campaign-scoped child table. They do not need rebuilding.
Lists, leads (vicidial_list), your custom_<list> tables and list-field definitions.
Agents (vicidial_users) and user groups.
Statuses and dispositions, with their categories and groups. These are VICIdial statuses already - there is nothing to map.
Your DNC list, inbound groups, DIDs and call menus.
Phone records with extension, login, password, conf_secret, full name and outbound caller ID intact.
Call and recording history, including the _archive tables, so pre-cutover reports keep working.
Non-stock AGI scripts from /var/lib/asterisk/agi-bin.
Recordings and voicemail, in a background rsync after the database is in.

Tables that exist on your source but not on a stock VICIdial box are handled too: the dump runs a second pass that recreates and repopulates them. So if GOautodial kept its own tables alongside VICIdial's, they arrive. Be clear-eyed about what that means, though - they arrive as tables, and nothing on the new box reads them. Treat them as an archive you can query, not as a feature that followed you.

What doesn't transfer

The GOautodial interface. Your team uses VICIdial's own admin and VICIdial's agent screen from here on. This is the real cost of the move and the thing to pilot with your supervisors before you commit.
The REST API. Anything you built against GOautodial's API needs porting. VICIdial ships its own Agent API and Non-Agent API - different endpoints, different parameters, and worth reading before you schedule the cutover rather than after.
The rest of their stack. The project's README lists components such as Kamailio, NodeJS, SocketIO and JSSIP alongside Asterisk and VICIdial. None of that is present on a VICIfast box. If something you rely on runs there, find out what it is first.
Carriers and trunks. vicidial_carriers, vicidial_server_carriers and vicidial_server_trunks are never copied by the migration.
Anything in /etc/asterisk. No file under it is copied.
Box-identity tables - servers, system_settings, web_servers, conference and conf-template tables - plus the IP-allowlist tables, which are cleared.

What you rebuild

Trunks, and the outbound routing that used them.
Your carrier's IP allowlist, pointed at the new box.
API integrations, ported to VICIdial's Agent and Non-Agent APIs.
Custom dialplan you kept in /etc/asterisk.
Supervisor and agent familiarity with the VICIdial admin. Budget training time; it is a different interface, not a reskin.

Order of operations

The mechanics are identical to any other source, and they are written up step by step on the ViciBox migration page - the two one-shot SSH keys and their lifetimes, the read-only probe, the drain requirement, the streamed dump, the restore, the recordings sync. Two things specific to a GOautodial source are worth checking before you start:

The probe needs to read /etc/astguiclient.conf. It never asks you for raw database credentials. If your install put that file elsewhere, or the SSH user you give us cannot read it, the probe stops there and tells you so. Run it as root, or grant that user passwordless sudo.
The probe also needs to find VICIdial's install.pl. It looks under the usual astguiclient paths. If your install laid things out differently, the probe reports that rather than guessing.

Then: provision a fresh destination, probe, drain the source, migrate, rebuild trunks, re-point the carrier, test, and only then let agents in.

About downtime

This is a scheduled cutover, not a seamless switch. The copy will not run while agents are logged in or any campaign is still active = 'Y', so dialing stops before it starts and does not resume until your carrier has accepted the new box's IP. Recordings sync in the background afterwards; nothing else does.

What to test before you point agents at it

Campaign, list and lead counts match what the probe reported
One outbound call on every trunk you rebuilt
One inbound call to every DID and in-group, IVR paths included
A recording completes, lands in monitorDONE and plays back from the report
An agent completes a full call and the disposition writes back correctly
A report over a pre-cutover date range matches the numbers your old box showed
Every ported API integration, end to end, against the new box
Your DNC count matches

When staying put is the right answer

If the GOautodial interface, its dashboard or its REST API is what your operation is actually built around, moving to stock VICIdial trades a familiar surface for an unfamiliar one and gains you a managed box. That can be the right trade or the wrong one. The comparison page lays out both sides, including where the project is still the better fit. Decide that before you drain anything.

Next steps

VICIfast vs GOautodial - stock VICIdial managed versus the community stack self-hosted.
Migrating from a ViciBox install - the full step-by-step, which is the same tooling.
Migrate from ViciBox - how the migration runs from the dashboard.
VICIfast pricing - billed per server, not per agent.
Start a trial - provision the destination before you drain anything.