If you run Asterisk 20 in production, your calendar has a hard deadline coming up. On October 19, 2026, Asterisk 20 transitions to security-fix-only status. Standard bug fixes, stability patches, and core telephony updates stop completely. From that point on, you get critical security patches for exactly twelve months until the official Asterisk 20 end-of-life date on October 19, 2027.
For ITSPs, enterprise contact centers, and UCaaS operators, this means the comfortable maintenance window is closing. You are now at a fork in the road: do you ride out the security-only year, jump directly to Asterisk 22 LTS, or wait for Asterisk 24 LTS to drop?
Let’s look at the lifecycle timelines, breaking technical changes, and operational trade-offs so you can make the right architectural call.
When Is the Official Asterisk 20 End of Life and Support Milestones?
The official Asterisk 20 end-of-life date is October 19, 2027, but standard bug-fix support ends earlier, on October 19, 2026.
To choose a target version, look at how Sangoma and the Asterisk community stagger Long Term Support (LTS) releases. LTS releases get four years of standard bug fixes and one final year of security maintenance. Standard releases (odd numbers) only get one year of bug fixes and one year of security patches.
What Are Your Migration Paths from Asterisk 20 Before Asterisk 20 Loses Support?
There are three viable migration paths before reaching Asterisk EOL: holding on to version 20 during the security-fix-only year, upgrading immediately to Asterisk 22 LTS, or skipping ahead to Asterisk 24 LTS in mid-2027.
There is no one-size-fits-all Asterisk version upgrade strategy. The best Asterisk migration path for you depends on your regulatory constraints, custom dialplan complexity, and engineering bandwidth.
Option 1: Stay on Asterisk 20 Through the Security-Only Window (Until Oct 2027)
What it means:
You keep running Asterisk 20 across your production fleet. The community will patch critical CVEs and remote exploits, but if you hit a weird race condition in res_pjsip or a memory leak in an obscure module, you won’t get an official upstream bug fix.
When to use it:
If your system is heavily integrated with legacy, custom-compiled C modules, or if you are locked into a certified operating system freeze (such as Debian 11 or RHEL 8) that requires a prolonged qualification cycle.
The risk:
You buy time, but you are kicking the technical debt down the road. Come October 2027, the Asterisk 20 end-of-life deadline is absolute.
Option 2: Migrate to Asterisk 22 LTS (The Recommended Move)
What it means:
You upgrade your clusters to Asterisk 22, the current stable LTS release. It has already seen multiple minor point releases, meaning early regressions have been resolved.
When to use it:
This is the most practical path for over 90% of production voice platforms. You gain active upstream bug fixes through late 2028, cleaner modern WebRTC/PJSIP handling, and a rock-solid platform that won’t require another major architectural overhaul for years.
The engineering cost:
Low to moderate. If you already run PJSIP and have removed legacy macro calls, the code adjustments are minimal.
Option 3: Wait for Asterisk 24 LTS and Migrate in Mid-2027
What it means:
Asterisk 24 LTS releases in late 2026. Instead of adopting version 24.0.0 on day one, you prepare your testbed over the winter, wait for point releases (24.2 or 24.3) to stabilize the codebase, and cut over in mid-2027 before the Asterisk EOL hits version 20.
When to use it:
High-throughput wholesale carriers and large UCaaS platforms that want to maximize their operational runway all the way to 2031.
The risk:
You must be disciplined. If your team delays testing, you risk bumping against the October 2027 cutoff with an unvalidated version 24 build.
What Breaks Between Asterisk 20 and 22 (Critical Changes Ahead of Asterisk EOL)
Upgrading Asterisk major versions is less about configuration syntax and more about removed modules and deprecated APIs. If you are jumping from 20 to 22 to avoid the Asterisk EOL crunch, here is what your engineering team needs to audit.
- The Removal of app_macro
If you still use Macro() in your dialplans (e.g., extensions.conf), your calls will fail on Asterisk 21 and 22. app_macro was deprecated long ago and was officially removed from the codebase in Asterisk 21.
The fix? Replace all Macro() invocations with GoSub() and Return(). If you generate dialplans dynamically via database backends, your generators must be refactored to emit GoSub subroutines.
- Complete Reliance on PJSIP
If you have legacy nodes still relying on chan_sip, Asterisk 22 will not run them. chan_sip was removed entirely in Asterisk 21. If your Asterisk 20 instances are already 100% on chan_pjsip, this is a non-issue. If not, converting your SIP profiles, NAT traversal flags, and trunk definitions to pjsip.conf is mandatory.
- Operating System and Dependency Upgrades
Running modern Asterisk versions on aging Linux distributions creates toolchain friction.
- Recommended OS Targets: Debian 12 (Bookworm) or Ubuntu 24.04 LTS.
- PJSIP Library (pjproject): Always build Asterisk using the bundled pjproject library (–with-pjproject-bundled). Relying on distro-packaged PJSIP shared objects often leads to dynamic linking mismatches and RTP packet-handling panics under heavy concurrency.
- Compiler & OpenSSL: Asterisk 22 expects modern OpenSSL 3.x libraries. If you are upgrading an older CentOS or Debian 10 box in place, you will run into build failures. Spin up fresh compute instances instead.
💡 Our Experts Tip
If your telephony platform uses custom, in-house C modules (such as custom billing hooks or proprietary RTP filters), do not simply recompile them against Asterisk 22 headers. Recent core updates tightened channel locking semantics and internal data structure locks (ast_channel_lock).
You need to run thread sanitizer builds (--enable-dev-mode with AddressSanitizer) in staging under high call volume to catch potential deadlocks before putting code in front of customers.
Dialplan, AGI, AMI, and ARI: How to Test Integrations Before Asterisk 20 End of Life?
Before the Asterisk 20 end-of-life deadline forces an emergency cutover, map out how your control planes and external integrations interact with the new Asterisk core.
Asterisk Manager Interface (AMI)
AMI remains backward-compatible for standard commands (Originate, Hangup, Redirect), but new point versions introduce subtle changes in event headers and channel variable formatting.
- Audit your event parsers for strict JSON/string matching.
- Ensure your middleware gracefully ignores unmapped event fields rather than crashing its TCP receiver thread.
FastAGI and Script Execution
FastAGI scripts running over persistent TCP sockets generally execute smoothly between versions 20 and 22. However, verify that environment variables (like agi_channel or agi_uniqueid) and channel variable returns behave as expected when channels transition through call setup.
Asterisk REST Interface (ARI) and Stasis Applications
For modern voice platforms running WebSocket-driven ARI applications, Asterisk 22 adds enhanced real-time tone detection events (ChannelToneDetected) and millisecond-accurate recording durations (RECORD_TIME).
Validate your WebSocket reconnection logic and verify that channel destruction events (ChannelDestroyed) clean up memory states predictably.
How to Switch Versions Before the Deadline (Zero-Downtime Migration)
To avoid service interruptions before your Asterisk EOL deadline, execute a side-by-side canary cutover using an upstream SIP proxy (like Kamailio or OpenSIPS) rather than upgrading in place.
Here’s the 5-step canary migration plan:
- Build Identical Green Infrastructure
Spin up a parallel cluster running Asterisk 22 on fresh OS images (e.g., Debian 12 / Ubuntu 24.04). Replicate dial plans, RTP port ranges, and database connectors.
- Automated SIP Stress Testing
Use tools like SIPp to simulate peak call concurrency, running synthetic calls through your IVRs, queue distributions, and recording engines. Measure CPU load, memory utilization, and RTCP jitter.
- Route 5%–10% Canary Traffic
Configure your upstream Kamailio load balancer to shift a small percentage of inbound customer traffic to the Asterisk 22 cluster.
- Monitor Error Rates and MOS
Watch your time-series metrics. Track SIP error response codes (503 Service Unavailable, 488 Not Acceptable Here), one-way audio anomalies, and Mean Opinion Scores (MOS).
- Progressive Rollout with Instant Rollback
Over 48 to 72 hours, scale traffic to 25%, 50%, and finally 100%. If unexpected deadlocks or memory spikes occur, your upstream proxy can divert traffic back to the Asterisk 20 cluster in under two seconds.
Relying on the Asterisk 20 end-of-life security year is a valid stopgap if your engineering backlog is pinned down, but it is not a long-term operational strategy.
Asterisk 22 LTS is mature, stable, and widely supported across modern Linux distributions. Upgrading to version 22 now gives your infrastructure team a stable, supported foundation through late 2028 (protecting your uptime, your call quality, and your security posture before the final Asterisk EOL cutoff).
If your team is managing a complex Asterisk fleet, running custom C code, or preparing a zero-downtime migration, you don’t have to carry that confusing load alone. Talk to an Asterisk migration specialist today!
FAQs
When is the official Asterisk 20 end-of-life date?
The final Asterisk 20 end-of-life date is October 19, 2027. However, standard bug-fix support ends on October 19, 2026, after which Asterisk 20 only receives critical security patches for 12 months.
What happens after a release reaches Asterisk EOL?
When a version reaches Asterisk EOL, it stops receiving all updates, including security patches and vulnerability fixes. Running an end-of-life version in production exposes your infrastructure to unpatched CVEs and compliance violations.
What major modules were removed between Asterisk 20 and Asterisk 22?
The two most significant removals are app_macro and chan_sip, both of which were completely removed in Asterisk 21. Dialplans using Macro() must be updated to GoSub(), and all SIP configurations must use chan_pjsip.
Should we upgrade directly to Asterisk 22 LTS or wait for Asterisk 24 LTS?
For most production systems, upgrading to Asterisk 22 LTS is the safest choice. It has already been stabilized through point releases and provides active bug support through October 2028. Waiting for Asterisk 24 LTS means delaying your migration until stable point releases arrive in mid-2027.
How long does an Asterisk 20 to 22 migration typically take?
For standard setups on chan_pjsip, a clean migration typically takes 2 to 4 weeks. For complex multi-tenant environments with custom C modules, legacy dialplans, or custom billing engines, plan for 6 to 10 weeks to complete automated load testing and zero-downtime canary rollouts.