Issabel in 2026: what changed, your options

If your call center runs on Issabel in 2026, three things have changed: the operating system under Issabel 4 reached end of life, Issabel 5 is the current release on a newer system, and Issabel has announced a cloud-focused model. Your calls still work today. What changed is how long an Issabel 4 server can stay as it is, and which paths are open. This guide sets out the facts, five options side by side, the questions to ask, and how to move without stopping your phones.

Where Issabel stands

Issabel is an active open-source project with a clear direction: a newer release and a move towards the cloud.

Issabel is open source under the GPL and grew out of Elastix. Source: en.wikipedia.org It bundles Asterisk, a web admin and modules such as the call center module, so one server can run a PBX and a small call center together.

The main events of the last two years:

Issabel 5. Released on 30 April 2024, based on Rocky Linux 8. Source: issabel.com
CentOS 7 end of life. Issabel 4 runs on CentOS 7, which reached end of life on 30 June 2024. Issabel recommends moving to Issabel 5 or another supported system. Source: issabel.com and redhat.com
A cloud model. In October 2025, Issabel announced a cloud-focused model and said it would stop offering on-premise servers and hardware. Source: issabel.com
The call center module. The community repository for the call center module (IssabelFoundation/callcenter) was archived in October 2026, and it now points to a community fork. Source: github.com

None of this switches anything off. It does mean that an Issabel server installed a few years ago now needs a plan.

What CentOS 7’s end of life means for an Issabel 4 server

An Issabel 4 server keeps running after CentOS 7’s end of life, but its operating system no longer gets security fixes from the CentOS project.

Issabel 4 is built on CentOS 7, and CentOS 7 reached end of life on 30 June 2024. Source: issabel.com and redhat.com In practice, for a server that takes your customers’ calls, this means:

Calls keep working. Nothing stops on a date. Your queues, extensions and trunks behave as they did the day before.
New security holes stay open. When a weakness is found in the operating system or its libraries, there is no update to install. This matters most for a server that can be reached from the internet.
New software gets harder to add. Newer tools and libraries are built for newer systems. Over time, small changes take more effort.
Replacing hardware gets harder. If the server fails, installing an old operating system on new hardware can bring driver problems.

None of these is an emergency on its own. Together they mean the server should be protected now and replaced on a schedule you choose, rather than on the day it fails.

If you stay on Issabel 4 for a while, harden the server:

Keep the web admin and SSH off the public internet. Reach them over a VPN or from the office network only.
Allow SIP traffic only from your trunk provider's addresses and your own offices.
Use long, unique passwords for every extension and admin account.
Block international calls unless you need them, and set a daily limit on outbound calls.
Take a full backup, copy it to another machine, and test that it restores.
Write down every setting you rely on: trunks, queues, voice menus, extensions and time rules.

Your options, side by side

There are five realistic paths, and the right one depends on your team’s skills, where you want the system to run and how central the call center is to your business.

Option	What it means	Fits when	Check before choosing
Stay on Issabel 4 and harden	Keep the current server, lock it down and plan a later move	You need time, and calls work well today	The operating system gets no security fixes; who watches the server; that backups restore
Move to Issabel 5	Issabel’s current release on Rocky Linux 8 Source: issabel.com	Your team knows Issabel and wants the same tools	Plan it as a new install on a new system; which modules you use, including the call center module Source: github.com
Issabel’s cloud	Issabel’s cloud-focused model Source: issabel.com	You prefer not to run a server yourself	Where calls and recordings are kept; how your SIP trunk connects; who supports you locally
FreePBX 17	A different Asterisk-based PBX, on Debian 12. FreePBX 16 runs on SNG7, whose operating system reached end of life in June 2024 Source: sangomakb.atlassian.net	Your team knows Asterisk or FreePBX and wants to run its own PBX	Which call center features come in the base product and which need add-ons
A call center product	Software built around queues, callbacks, wallboards and agent reports	The call center is the main reason you run the system	Where it runs; whether it supports your SIP trunk; who supports it locally; what happens to old call history

A few notes on reading the table:

Staying is a valid short-term choice. It buys time, but set an end date so it does not become the plan by default.
Issabel 5 and FreePBX 17 are both PBX platforms. They handle extensions, trunks and voice menus well. Call center work, such as callbacks, live wallboards and agent scoring, may need extra modules or setup.
The cloud and your own server are different decisions. Choose on where your data must live and who you want to call when something breaks, not only on cost.
A call center product is narrower than a PBX but goes deeper on the call floor. Check that it still covers the PBX features you use, such as extensions and transfers.

Questions to ask before moving

The best option for you depends on a few answers that only you have. Settle these before you speak to any supplier.

What do we actually use today? List your trunks, numbers, queues, voice menus, extensions, desk phones, recordings and reports. Many Issabel servers carry settings that nobody has looked at for years. Some can be dropped.

Who looks after the server? If one person set it up and has since left, that is a risk on its own. Choose an option your team, or a local partner, can support.

Where must calls and recordings be kept? Some businesses, such as banks, clinics and public offices, have internal rules about this. Ask your own legal or compliance team.

What happens to our call history? Decide whether you need old reports and recordings after the move. Many teams export what they need and keep the old server, switched off from calls, for reference.

How many calls do we handle at our busiest hour? This sizes the new server and tells you how many channels the trunk needs.

Does the new system work with our phone line? If you use an Ethio Telecom SIP trunk, ask the supplier to show it working on a trunk like yours.

Who do we call when something breaks? Get the hours, the languages and the names. A supplier who answers in your working hours and in your language is easier to reach at 08:00 on a busy Monday.

Can we go back? Any move should let you switch back to the old system until you are sure.

How a staged move works

A staged move runs the new system next to Issabel and moves one part of the traffic at a time, so you can stop or go back at any step.

A typical order:

Install the new system next to Issabel. Both run at the same time. Nothing changes for callers yet.
Set it up and test it. Rebuild queues, voice menus and time rules. Agents practise on test calls.
Move automatic or outbound calls first. These carry the least risk, because no caller is waiting in a queue.
Move one number or queue. Pick a small one. Watch it for a few days.
Move the main line. Do it on a quiet day, with the old setup ready.
Keep Issabel ready to switch back until you confirm everything works. Then retire it.

Plan call history separately. In most moves, old call records stay where they are, so export the reports and recordings you need before you retire the old server.

For a fuller checklist, with what to prepare at each stage, read our step-by-step plan for migrating from Issabel.

Whatever you choose, choose it while your current server still works. A move planned on your own schedule is calmer than one forced by a failed disk.