Having a rollback plan for your VICIdial migration

Most migration planning focuses on the forward path: export, import, configure, cut over. The rollback plan — what you do if VICIdial is not ready or something breaks on day one — gets far less attention. That is a mistake. A migration with no credible fallback puts your call center floor at risk of a full stoppage, and a stopped floor means agents paid to sit idle and leads going un-worked.

This post covers how to define a rollback, keep the old platform accessible long enough to use it, and decide in advance what threshold triggers a return.

For the full migration sequence, the VICIdial migration guide covers each phase from data export through go-live.

What a rollback means in practice

A rollback is not erasing the VICIdial work — it is returning agents to the old platform while the VICIdial issue is diagnosed and fixed. That means the old platform must still be accessible. Do not cancel your existing subscription until VICIdial has been running stably for at least 30 days after cutover. Keep at least one admin account active on the old system and verify that logins still work the week before cutover. If the old platform bills by active seat, downgrade to a minimum seat count rather than cancelling, so the fallback stays available at low cost.

Define the rollback trigger before cutover day

The decision to roll back should be made on pre-agreed criteria, not in the heat of a problem. Write these down before cutover and share them with the team lead and technical contact:

• VICIdial is unreachable by agents for more than 15 minutes with no ETA on resolution
• Call recording is confirmed broken and compliance requires it
• Predictive dialing is producing errors that cannot be diagnosed within 30 minutes
• SIP trunk is not passing calls and the carrier confirms VICIdial-side misconfiguration

If none of these are met, work through VICIdial issues without rolling back. Minor problems on cutover day — one agent can not log in, one Campaign was misconfigured — do not justify reverting the whole floor. Name one person as the decision owner ahead of time. When a problem hits, debate over whether to roll back wastes the very minutes you are trying to protect, so the owner calls it against the written criteria and the team executes.

Rollback decision flow

flowchart TD
    A[Problem detected on cutover day] --> B{Meets pre-agreed rollback threshold?}
    B -->|No| C[Diagnose and fix in VICIdial]
    B -->|Yes| D{Old platform still accessible?}
    D -->|No| E[Escalate to managed hosting support immediately]
    D -->|Yes| F[Redirect agents to old platform]
    F --> G[Notify team lead and document the issue]
    G --> H[Fix VICIdial in staging environment]
    H --> I[Re-run parallel test before second cutover attempt]

Keeping lead data in sync during a rollback

If agents worked leads in VICIdial before the rollback, those Disposition updates exist only in VICIdial. Before redirecting agents to the old platform, export the VICIdial disposition data for the calls completed during the cutover window. Import those updates into the old platform's lead records so agents are not re-dialing already-contacted leads.

Similarly, any DNC list numbers added during the VICIdial window must be synced back. A number that opted out during the brief VICIdial period is still a legal DNC entry regardless of which platform called them. Treat this DNC sync as the highest-priority step of any rollback — re-dialing an opted-out number is the one mistake that turns an operational hiccup into a compliance problem.

Running parallel to reduce rollback risk

The single most effective way to reduce rollback probability is a parallel run before hard cutover. Running VICIdial alongside the old platform for several days lets you find configuration problems under real conditions without full exposure. See the parallel run migration guide for a day-by-day schedule.

For managed VICIdial hosting that includes support access if you hit issues on cutover day, see VICIfast managed plans. A dedicated server is ready in under 40 seconds, and having the environment built well before cutover gives you time to validate the configuration without pressure.