Asterisk vs 3CX: choosing a phone platform

A business outgrows its phone system and asks which platform to move to. Two names come back almost every time: Asterisk, usually via FreePBX, and 3CX. What follows is a feature comparison — does it do call recording, does it do queues, does it do mobile apps, does it integrate with the CRM.

Both do all of that. The feature grid comes out nearly even, the decision gets made on whichever demo was more polished, and the real difference only surfaces two years later when the bill or the maintenance burden turns out not to be what anyone expected.

The two platforms differ in two ways that matter and both are structural. They charge for different things, and they place the maintenance obligation on different people. Everything worth deciding follows from those two facts.

The business problem underneath the question

A phone system is not a product a business buys once. It is an operational dependency that has to keep working every working hour for the next five to ten years, through carrier changes, staff growth, office moves and security patches.

So the decision is not which platform has more features today. It is which platform's cost curve and maintenance model fits the shape of your business as it grows. A platform that is cheap at your current size and punitive at double your size is not cheap; it is a decision you will have to make again, under time pressure, with a live phone system in the way.

Getting this wrong is expensive in a specific way. Migrating a phone platform means renumbering extensions, re-provisioning every handset, re-cutting the SIP trunks, rebuilding every queue and IVR, and retraining everyone who answers a phone. It is one of the few IT migrations where a bad hour is immediately visible to customers.

How each one charges, and why it decides the outcome

3CX prices per system, per year, on the number of simultaneous calls the system supports — internal and external calls happening at the same time. Its published editions are SMB Free, Basic, PRO and AI, with the paid tiers sized by simultaneous call count rather than by user count. There is a free tier for up to ten users.

Asterisk is open source and has no licence fee at any scale. Its cost is engineering time: someone has to build the dialplan, keep the operating system patched, follow the project's security advisories, and be available when something breaks.

That difference sounds like a straightforward free-versus-paid comparison. It is not, because the two costs scale against completely different variables.

Read that table against your own numbers and the decision usually makes itself.

The office case

An accountancy firm with sixty staff might have sixty extensions and, at its busiest, eight calls in progress. Concurrency is roughly an eighth of headcount, because most people are not on the phone most of the time.

3CX is priced extremely well for this shape. You are buying eight simultaneous calls to serve sixty people, and you get a supported product, a vendor to escalate to, and no server to maintain. Choosing Asterisk here to avoid a licence fee means taking on a permanent maintenance obligation to save a cost that was already small relative to what the maintenance will cost you.

The contact centre case

A forty-seat outbound operation is different in kind. Every seat is on a call for most of the shift by design — that is what the seats are for. Concurrency approaches headcount, and with any predictive dialling, outbound attempts exceed it.

Now the per-system pricing tracks your headcount almost one-for-one, and it does so every year, and it grows exactly when the business grows. This is the shape where the Asterisk economics start to win, and it is also the shape where the dialplan complexity — queues, dispositions, dialler integration, per-campaign routing — is high enough that you need engineering capability regardless of which platform you pick.

The second difference: who is obliged to maintain it

A phone platform is exposed to the internet by definition — it terminates SIP from a carrier, and usually registers remote handsets or softphones. That makes it a target, and it makes patching non-optional. The two platforms distribute that obligation differently.

With a commercial product, the vendor produces the patch and you apply it. With Asterisk, the project produces the patch and you apply it — but you also have to be watching. The Asterisk project maintains several major version branches concurrently and issues security advisories against them; as of writing, the 20, 21, 22 and 23 branches were all receiving releases. Nobody will phone you when an advisory affects your branch.

This is the part of the comparison that gets skipped, and it is the part that produces the bad outcomes. An unpatched Asterisk box with a weak SIP secret is how toll fraud happens, and toll fraud is billed to you at international rates before anyone notices.

• Who watches the project's security advisories, and how often?
• Who applies the patch, and inside what window after an advisory?
• Who is called at 2am when the trunk deregisters, and what is their escalation path?
• If that person leaves, who has the dialplan documented well enough to take over?

If those four questions do not have names against them, Asterisk is not free. It is deferred, and the deferral is usually settled by an incident.

FreePBX: the option the comparison usually omits

Presenting this as Asterisk versus 3CX sets up a false contrast between a raw engine and a finished product. Almost nobody deploys bare Asterisk for a business phone system. FreePBX is the open-source management layer over Asterisk, and it is what most real Asterisk deployments actually are.

That changes the comparison meaningfully. FreePBX gives you a web interface, extension and trunk management, queues, IVR and call recording without writing dialplan by hand — much of what the 3CX interface provides — while keeping the licence-free cost model and the underlying Asterisk flexibility for the cases the interface does not cover.

It does not remove the maintenance obligation. It sits on a Linux server you still own and patch, and its own modules need updating too. But it substantially lowers the engineering skill needed for day-to-day administration, which is often the real barrier rather than the licence fee.

What does not differentiate them, despite being argued about

Several points come up in these comparisons that do not survive examination, and time spent on them is time not spent on the two that decide it.

• Call quality. Both terminate the same SIP and carry the same RTP. Quality is decided by your network, your carrier and your codec choice, not by the PBX.
• Codec support. Both handle the codecs a business carrier will actually offer.
• Mobile and softphone clients. Both have them. Whether the client is pleasant to use is a real question, but it is a user-experience question, not an architectural one.
• CRM integration. Both can do it, and in both cases the difficulty is in number normalisation and the CRM's own API, not in the PBX.
• Cloud versus on-premises. Both run either way. This is an infrastructure decision made separately.

That last one is worth being explicit about. Where the PBX runs is a question about latency, control and failure domains, and it is answered the same way for both platforms.

How to actually decide

1. 1

   Measure concurrency, not headcount

   Pull the peak simultaneous call count from your existing system's CDR for the busiest month you have data for. If you have no data, count the people whose job is being on the phone. This single number moves the answer more than anything else.

2. 2

   Add the growth you actually expect

   Size against where the business will be in three years, not today. Crossing a concurrency tier mid-year is a budget surprise; crossing it during a hiring push is a budget surprise at the worst moment.

3. 3

   Name the person who patches it

   Not a team, a person, with a named backup. If you cannot, either buy a supported product or buy a support contract for the open-source one. Both are legitimate; leaving it unnamed is not.

4. 4

   List the integrations that must work

   CRM screen pop, click to call, ticketing, reporting into a warehouse. Check each against both platforms' actual APIs rather than their feature lists. This is where genuine differences appear.

5. 5

   Price five years, not one

   Licence renewals against engineering hours, including the migration cost at the end if the platform will not carry you that far. A cheaper year one that forces a migration in year three is the most expensive option on the table.

6. 6

   Check the routing you already depend on

   Every business has one or two pieces of call handling nobody documented — an after-hours rule, a specific escalation, a legacy DID. Find them before migration, not during.

The honest summary

If your concurrency is low relative to headcount, you have no in-house Linux capability, and your routing needs are ordinary, a commercial product is the right answer and the licence fee is buying you something real. Trying to save it by self-hosting is how businesses end up with an unpatched PBX and a toll fraud bill.

If your concurrency tracks your headcount, or your routing is genuinely unusual, or you are running multiple tenants, the open-source path wins — but it wins on the condition that the maintenance obligation is staffed. It is not free; it is unbundled, and you are buying the parts separately.

Most businesses can answer this in an afternoon with one number from their own CDR. Very few pull it.