Migrating VICIdial off CentOS 7: what to carry, what to verify, before cutover

Fast answer: pick a target, do not upgrade in place

Fast answer: CentOS Linux 7 stopped receiving updates or patches entirely on 30 June 2024, so staying on it means running an increasingly exposed dialer on borrowed time, not a stable one. Do not run an in-place distribution upgrade on a production dialer. Instead, build a new server on one of three realistic targets, carry the database, recordings, configuration, cron jobs and carrier setup across deliberately, verify the new server on its own, and only then move live traffic to it.

This is a decision framework for the move itself, not a command-by-command install guide for every target — pair it with the specific install guide for whichever target you choose.

None of the words for agent, campaign, carrier or DID change when the operating system underneath them does — only the box they run on does. See VICIdial terminology for complete beginners: users, phones, campaigns and leads if you need any of them defined.

• Confirm you are reading this because you still have a CentOS 7 VICIdial server running, not because you are planning a brand-new install.
• Pick one target platform before you provision anything.
• Decide who can authorize the cutover and who can order a rollback, before you need either.

What 'end of life' actually means for a box taking live calls

CentOS Linux 7 reached end of life (EOL) on 30 June 2024. Red Hat's own announcement states plainly that no further updates or patches are published after that date. That is not a projection or a marketing warning; it is the documented, permanent status of the distribution, and the date was announced years in advance, so nothing about it is arriving as a surprise.

In concrete terms: every package on that server — kernel, OpenSSL, Apache, PHP, and everything else in the base image — stopped receiving fixes on that date. When a new common vulnerabilities and exposures (CVE) entry is later found in any of those components, CentOS 7 simply does not get the fix. The gap between disclosure and exposure only grows, and it never closes on its own; by August 2026 that gap is already more than two years wide.

Before you plan anything else, look at what the box is actually running today. CentOS 7 shipped with an old PHP (the scripting language VICIdial's web admin and agent screens are written in) release, and years of accumulated patches rarely bring that current. Confirm the real numbers instead of assuming.

(set -euo pipefail cat /etc/centos-releaseuname -rphp -v | head -n 1mysqld --versionasterisk -rx 'core show version'du -sh /var/spool/asterisk/monitordu -sh /var/lib/mysqlcrontab -lls -la /etc/cron.d )

• Write down the exact PHP, MariaDB/MySQL and Asterisk versions before you touch anything.
• Record the recordings directory size; it usually drives your transfer time more than the database does.
• Save the crontab and cron.d listing verbatim; you will need to recreate every entry on the new server.

Why an in-place distribution upgrade is not the move

It is tempting to look for a supported upgrade path from CentOS 7 straight to a newer release and run it against the live server. Resist that. VICIdial's Asterisk is typically built from source and pinned to a specific version, kernel telephony modules (DAHDI, if hardware cards are involved) are compiled against the exact running kernel, and MariaDB's storage engine defaults and configuration assumptions differ across major versions. An in-place jump changes all of those under a system that may have agents on live calls when it happens.

There is no official, supported leap from CentOS 7 directly to a current Red Hat Enterprise Linux (RHEL) family release, an Ubuntu release, or a ViciBox release. Third-party distribution-upgrade tools exist for some RHEL-family jumps, but none of them know anything about Asterisk, VICIdial's schema version, or your carrier trunks. A failed mid-upgrade kernel or library swap can leave a dialer half-working in a way that is harder to diagnose than simply starting from a clean, current server.

Build the replacement server in parallel instead. The old CentOS 7 box keeps taking calls, unmodified, for the entire time you are building and testing the new one. That is what makes a rollback possible at all.

• Do not run yum or dnf distribution-upgrade tooling against a live VICIdial server.
• Do not touch the CentOS 7 kernel, Asterisk build or MariaDB version while it is still carrying traffic.
• Build the new server on separate hardware or a separate VPS from day one.

The three realistic targets, and their trade-offs

This publication has not verified a production migration target. The ViciBox 12 lesson is for a disposable lab; the AlmaLinux 9 and Rocky Linux 9 article is an unverified planning guide. Other supported RHEL-family releases also exist, but operating-system lifecycle alone does not establish VICIdial compatibility. Verify vendor lifecycle, the chosen VICIdial/Asterisk stack and a tested rollback before choosing a production target.

ViciBox 12.0.2 is the current prebuilt VICIdial appliance: openSUSE Leap 15.6 as the base, Asterisk 18 with PJSIP support, MariaDB 10.11.9 and PHP 8.2, installed through a staged Phase 1 (base OS) and Phase 2 (VICIdial itself) sequence documented directly by the ViciBox project. It trades some of the control of a from-scratch install for a maintained image — though, as above, its openSUSE base is itself lab-only, not yet a production platform. See this site's ViciBox 12 installation guide (Install ViciBox 12 in a lab and reach a secure first login) for the phase-by-phase console steps; this article covers only the trade-off of choosing it, not the keystrokes.

AlmaLinux 9 or Rocky Linux 9 continue the RHEL family CentOS 7 came from, which appeals if your operational habits already assume that family. This publication has not verified a step-by-step install procedure for either — the material available is third-party community documentation, not an official VICIdial or vendor reference. The cited community guides describe disabling SELinux, which this publication has not verified as universally necessary; package names and repositories differ from the Debian family; and a community-maintained installer (the CyburDial project, at dialer.one) is the actively maintained option for this family. Treat the scratch-install instructions posted on the VICIdial forum as the authority for the underlying steps, and the community installer as a starting point to review carefully, not a script to run unread.

Treat the PHP and VICIdial code upgrade as a separate project

Record the PHP version on both servers and test the exact VICIdial revision and customizations against the target version; compatibility cannot be inferred from the operating system name or code age alone.

That means moving the operating system and moving the application version are two different projects, even though a migration makes it feel like one event. The most common mistake in a CentOS 7 migration plan is treating the new server's PHP and Asterisk versions as a drop-in replacement for whatever custom admin screens, reports or agent-screen modifications were written years ago against the old versions. They are not automatically compatible just because the database schema copies across cleanly.

Before cutover, inventory every custom PHP file, cron script or Perl script that touches the web interface, and test each one against the target server's actual PHP version — on the new server, before agents depend on it, not after. A page that throws a fatal error under PHP 8 is a far worse discovery in front of a live agent floor than in a quiet test window.

• List every customized or third-party PHP file separately from the stock VICIdial tree.
• Run each customization against the new server's real PHP version before cutover, not just the database migration.
• Do not assume a clean schema copy means the application works.

What must move, and what a fresh install already gives you

A migration is not a full clone of the old server; it is a deliberate copy of the parts that hold your data and identity, onto a server that already has the platform installed and current. Knowing which is which up front keeps the copy step from turning into copying the entire old, unpatched filesystem onto the new box.

The database is not one lump. Runtime and configuration tables — vicidial_campaigns, vicidial_lists, vicidial_users, phones, vicidial_server_carriers and the like — are what makes the new server behave like your old one. Call-detail and archive tables — vicidial_log, vicidial_closer_log, recording_log and similar — are large, grow without bound, and matter for reporting history rather than for the system working at all. Decide deliberately whether history rides along on day one or migrates separately afterward; either choice is defensible, but do not let a multi-gigabyte log table silently turn a planned short cutover into an overnight one.

For the general backup and restore architecture — layered copies, integrity checks, retention, and a properly measured recovery point and recovery time objective — see “VICIdial backup and disaster recovery: design for a tested RTO/RPO”. This article only covers what is specific to moving off CentOS 7: which pieces exist on the old box that a fresh install does not already provide for you.

MUST CARRY ACROSS FROM THE OLD CENTOS 7 BOX:the VICIdial database named in /etc/astguiclient.conf's VARDB_database setting (vicidial_list, vicidial_campaigns, vicidial_lists, vicidial_users, plus your log/archive tables)/etc/astguiclient.confcarrier trunk definitions (pjsip.conf or sip.conf entries, plus the Admin carrier records)crontab and /etc/cron.d entriescustom AGI and Perl scripts outside the stock install treecustom or modified PHP files under the web treerecordings under the monitor spool directoryTLS/SSL certificates, if you terminate your own A FRESH INSTALL ALREADY PROVIDES:Asterisk, MariaDB, PHP and the web server, at current versionsthe VICIdial schema and stock Perl/AGI scripts at a pinned revisiondefault cron entries for the standard AST_ jobsa firewall baselinea self-signed certificate to replace before production traffic

• Separate runtime/configuration tables from call-detail and archive tables before deciding how much history to copy on day one.
• Treat recordings as their own transfer, sized and timed separately from the database.
• Confirm carrier trunk definitions exist in both the Asterisk configuration and the Admin carrier records — VICIdial keeps both.

Size the database before you copy it

Unbounded growth in call-detail tables is a documented operational risk on its own, and it is exactly what makes a database copy take longer than anyone plans for. A years-old vicidial_log or recording_log table can dwarf everything else in the schema combined. Measure before you move, so a multi-hour copy does not surprise you during a cutover window.

Run this against the old server's database with a read-only account. It only reads catalog metadata — it changes nothing and it does not lock any table.

On the source host, complete this access check before collecting the migration inventory. If the linked option file is root-owned mode 600, an authorized administrator can start the client with sudo mysql --defaults-file=/etc/vicidial-readonly.cnf, then run SELECT CURRENT_USER(), DATABASE(); and confirm the intended read-only account and schema before these queries. Do not expose or copy its credentials.

SELECT table_name, table_rows,  ROUND(((data_length + index_length) / 1024 / 1024), 1) AS size_mbFROM information_schema.tablesWHERE table_schema = DATABASE()ORDER BY size_mb DESCLIMIT 15;

Sequence the cutover so a rollback is still possible

Build and verify the new server completely before it carries a single real call. Keep the old system intact during the build. Once the new system accepts writes, the old copy becomes stale; reconcile or preserve those changes before any rollback.

A workable sequence: provision and install the target platform; copy configuration, custom scripts and a first pass of the database and recordings while the old server keeps taking live traffic; verify the new server fully, as its own step, before it touches any carrier; schedule a short freeze window and copy only what changed since the first pass; test with isolated test trunks and numbers; then move production trunks and DIDs during the approved cutover. Define how post-cutover writes and recordings will be reconciled before restoring the old server, and keep it reachable for the rollback window — days, not hours — before you even consider decommissioning it.

Rollback only works if the old server is still whole. Do not repurpose its disk, its IP address or its carrier trunk registration until the rollback window has fully passed.

(set -euo pipefail # Dry run only. Plan and authorize the real transfer separately after checking this output.rsync -avz --dry-run root@203.0.113.10:/var/spool/asterisk/monitor/ /mnt/new-server-staging/monitor/rsync -avz --dry-run root@203.0.113.10:/etc/astguiclient.conf /mnt/new-server-staging/astguiclient.conf )

• Set a rollback window measured in days, not hours, before you schedule the freeze.
• Name who can authorize pointing carrier trunks at the new server, and who can order them back.
• Do not decommission, wipe or repurpose the CentOS 7 server until the rollback window has passed.

What to verify on the new server before anything real touches it

Verification happens before carrier trunks move, not after. A server that boots, shows a login screen and lets you click around Admin has not yet proven anything about whether it can carry your actual traffic.

At minimum, confirm the following before cutover. If you chose the AlmaLinux 9/Rocky Linux 9 or a from-scratch path, confirm your own equivalent checks manually — only the ViciBox appliance path documents a vendor-provided verification sequence on this site. Beyond that: PHP, MariaDB and Asterisk are the versions you expect, and every custom script from the application-upgrade review above runs cleanly under them; the database schema version matches what the old server reported, and row counts for key tables reconcile against the old server's counts from before the freeze; every crontab and /etc/cron.d entry from the old server exists and is scheduled on the new one; recordings from before the freeze are present and playable; test trunks are reachable as their authentication model requires; and one inbound and outbound call over isolated test numbers completes and is logged correctly before production traffic moves.

Reconcile row counts with a read-only account, comparing the same tables you sized before the copy.

SELECT (SELECT COUNT(*) FROM vicidial_list) AS list_rows,  (SELECT COUNT(*) FROM vicidial_campaigns) AS campaign_rows,  (SELECT COUNT(*) FROM vicidial_lists) AS list_defs,  (SELECT COUNT(*) FROM vicidial_users) AS user_rows;

• Do not point a single carrier trunk or DID at the new server before every item above is confirmed.
• Use isolated test trunks and numbers to verify one inbound and outbound call before moving production traffic.
• Keep the old server's final pre-cutover counts written down for comparison after the freeze.