Migrating from Issabel or Elastix

This is the hardest migration on this site, and the honest version of it starts by saying why: you are not moving a dialer between hosts. You are replacing one product with a different kind of product, and almost nothing carries over automatically.

Issabel describes itself as software for building business communication tools and says it functions as an IP PBX. It was created in 2017 as a continuation of Elastix after that project's open-source line was discontinued. VICIdial is an outbound dialer. Both are built on Asterisk, which is why they turn up in the same searches, but they are not substitutes for each other. The VICIfast vs Issabel comparison covers that ground in full, including what Issabel does better.

Read this first: you are probably changing dialing model

Issabel's own Contact Center documentation states that it "includes manual, preview, and progressive dialing", and that automated campaigns are built using progressive dialing against predefined contact lists. Their own feature comparison table lists progressive and preview and has no predictive row at all. There is a nuance worth knowing: the legacy community Call Center module inherited from the Elastix line does contain a predictive option, and its repository's last commit was in January 2023 - so if someone tells you Issabel does predictive, check which module they mean.

Why that matters for a migration rather than for a purchase decision: progressive dialing places roughly one call per available agent. Predictive places more, pacing against a forecast of when agents will free up. Moving from one to the other is not a setting you flip and forget. Your agents' idle time between calls drops, your connect rate changes, and abandoned-call rate becomes a number you now have to actively manage. The levers on the other side - dial level, drop-rate enforcement, lead recycle rules, answering-machine detection - are per-campaign settings you will spend real time tuning.

Budget for that tuning as part of the project. Teams that treat this as a hosting change and not a dialing-model change are the ones that get surprised in week two.

What transfers

Very little, automatically. Be clear-eyed about it:

• Your lead data, once you export it and reload it. It ends up in VICIdial's vicidial_list through VICIdial's own list-loading tools, mapped to VICIdial's field layout. This is an export-transform-load job, not a restore.
• Your DID numbers. They live with your carrier and always did. Repointing them is a carrier-side change.
• Your recordings, as files. You can copy them across, but VICIdial's reports read a recording_log table that will have no rows for them. Copied recordings are an archive you can browse on disk, not call history that shows up in the new box's reporting. Plan where they actually need to live.
• Your people. Agents and supervisors move with you. The screens they use do not.

What doesn't transfer

• The automated ViciBox migration does not apply here. It reads database credentials from /etc/astguiclient.conf and looks for a VICIdial install.pl, and a plain Issabel or Elastix box has neither. There is no dump to restore.
• Your campaigns, queues, agents, dispositions and reports. These live in Issabel's own tables in Issabel's own shape. They are rebuilt, not converted.
• Your dial plan. Asterisk logic is portable in principle and unportable in practice - VICIdial generates its own dial plan from its database, so hand-written contexts have to be re-expressed the VICIdial way rather than copied.
• The Issabel interface, and any staff familiarity with it.
• PBX features. Extensions, voicemail, IVR, fax, internal calling, video: VICIdial is not a replacement for a phone system. If your Issabel box is also your office PBX, you are not decommissioning it by doing this.
• Your existing box. Our installer only runs on a clean Ubuntu 22.04 server and explicitly refuses machines with Issabel, Elastix, FreePBX, Asterisk, Apache or MariaDB already present. This is always a new box.

Is any of it automatable?

One case: if VICIdial was already installed on or beside that box, the VICIdial half is a standard VICIdial move and the automated tooling handles it normally. You do not have to guess whether that is your situation - the read-only probe on the migration screen looks for /etc/astguiclient.conf and a VICIdial install.pl and reports exactly what it found, without writing anything to your box. Run it before you plan anything else. If it finds a VICIdial install, follow the ViciBox migration page, which is the same tooling. If it does not, this page is your path.

What you rebuild

Effectively the whole dialer:

1. Campaigns, with a dialing model you have not used before, and the pacing settings that go with it.
2. Lists and lead loading, including the field mapping from your export.
3. Statuses and dispositions, and the reporting categories built on them.
4. Agents, user groups and permissions.
5. Inbound groups, DIDs and IVR menus, if you are moving inbound too.
6. Carriers and trunks, and your carrier's IP allowlist for the new box.
7. Your DNC list, which you should export and reload deliberately rather than assume.
8. Reporting, because VICIdial's reports are its own and will not look like the ones your supervisors read today.

Order of operations

1. Decide the scope honestly. Is this outbound only, or are you also replacing a PBX? If you need the PBX, keep it and run the dialer alongside - do not plan a decommission you cannot deliver.
2. Run the read-only probe to find out whether there is a VICIdial install to migrate. This costs you nothing and changes the plan entirely if the answer is yes.
3. Export your leads and your DNC list from Issabel, and work out the field mapping before you provision anything.
4. Provision a server and build one campaign end to end. One list, one carrier, a handful of agents. Do not migrate the floor first.
5. Tune the dialing model on that pilot until the pacing and abandon rate are where you need them.
6. Load the rest of your lead data, rebuild remaining campaigns, and repoint DIDs at the carrier.
7. Move agents across in groups, not all at once, and keep Issabel available while you do.

About downtime

This one is different from the other migrations here, and in your favour: because there is no dump to restore, there is no single cutover moment where both systems have to be down. You can run the pilot alongside your existing Issabel setup and move campaigns across in stages.

What you cannot avoid is the carrier work. Repointing DIDs and changing an IP allowlist are carrier-side changes with the carrier's own turnaround, and inbound calls are the ones that break visibly when those are half-applied. Sequence them per campaign rather than all at once, and confirm each one before you move the next.

What to test before you point agents at it

• Loaded lead counts match what you exported, and spot-check that fields landed in the right columns
• One outbound call on every trunk, and one inbound call to every DID and IVR path
• Your DNC list actually blocks a number you know is on it
• A recording completes, lands in monitorDONE and plays back from the report
• An agent completes a full call and the disposition writes back to the right status
• Pacing under real load, with enough agents to be representative - a two-agent test tells you nothing about a dialing model
• Abandoned-call rate over a full shift, not a ten-minute sample
• Any PBX feature you assumed you were keeping still works on whatever is still providing it

When keeping Issabel is the right answer

If what you actually need is a phone system, Issabel is a phone system and VICIdial is not. If you need both, running both is a legitimate architecture and cheaper than pretending one covers the other. And if progressive dialing genuinely meets your volume, the migration cost here is real and the gain may not be. The comparison page sets out both sides, including their published per-agent contact-centre pricing against our per-server billing, so you can put a number on it before you commit.

Next steps

• VICIfast vs Issabel - the PBX-versus-dialer comparison, with sources.
• Migrating from a ViciBox install - the path to follow if the probe finds a VICIdial install on your box.
• VICIfast pricing - billed per server, not per agent.
• Start a trial - enough to build the pilot campaign this page recommends.