Asterisk LTS upgrade planning

Why Asterisk LTS upgrade planning is a compliance question, not only a version choice

For a regulated organization, an Asterisk or FreePBX server running on an end-of-life release is a compliance gap as well as a maintenance problem. The upgrade has to leave call routing, 911 behavior, call recordings and logs working as they did before, and auditors will expect evidence that they do. A version change touches the dial plan, SIP trunk configuration, recording hooks and logging pipeline at the same time, so each of those needs a documented before and after state. Treat the upgrade as a change to a regulated system, with the same approval, testing and rollback records you would keep for any change that affects emergency calling or retained communications.

The short answer is to set the target around the published lifecycle first, then choose between Asterisk 22 and 24 on three tests: how long each release stays supported, whether the FreePBX version you run or plan to run supports it, and whether the features your queues, recording and integrations depend on are present in that release. Asterisk 18 and 21 are already end of life, and Asterisk 20 has moved to security fixes only, so staying on any of them means carrying a known support gap into your change window. Confirm the exact end-of-life dates for each release on Asterisk's published lifecycle page before you set a cutover window, because the support horizon determines how soon you will need to upgrade again.

Compliance evidence follows from the same decisions. If call recordings or voicemail are kept as business records, retention settings must survive the upgrade unchanged. For broker-dealers, 17 CFR 240.17a-4 requires preserving communications relating to the business for not less than three years, so confirm with your compliance team whether recorded calls fall under that rule before you test retention on the new release. Under the HIPAA Security Rule, 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI, which means call detail records and system logs must still be written and readable after cutover. Ask your partner to document the pre-upgrade baseline and the post-upgrade test results side by side.

What an Asterisk upgrade must preserve in a regulated environment

This table lists the requirements an Asterisk or FreePBX upgrade must leave intact, with the source of each requirement and what it means for the build. Read it as a checklist for the upgrade plan: each row should map to a test, a configuration check or an evidence artifact before cutover. The main takeaway is that a version change is a compliance event as well as a software event, so the same controls must be shown to work on the new release.

Requirement	Source	What it means for the build
Continued security patching within a supported lifecycle	Asterisk published lifecycle and your own risk policy	Confirm the target release's support window before you pick it. Plan the upgrade so the platform never runs an end-of-life release in production, and record the lifecycle decision in your change file.
Transmission security for SIP signaling and media where ePHI may cross the network	45 CFR 164.312(e)(1), HIPAA Security Rule	Verify that TLS for signaling and SRTP for media still work after the upgrade and after any FreePBX module changes. Test with captures from the new release, and confirm that voicemail and call notifications carrying PHI stay encrypted in transit.
Audit controls for call detail records, voicemail access and admin changes	45 CFR 164.312(b), HIPAA Security Rule	Confirm that CDR logging, voicemail access logs and admin change logs still record the same fields after the upgrade. Compare sample records from old and new systems, and retain them as evidence that activity is recorded and can be examined.
Retention of business call records for broker-dealers	17 CFR 240.17a-4(b)(4), SEC Rule 17a-4	Confirm that CDR and any archived communications are exported and retained for the required period on the new platform, including during migration of historical data. Ask counsel whether call recordings fall within scope for your business.
Unchanged 911 routing and dispatchable location	Kari's Law and RAY BAUM's Act requirements, covered on the 911 compliance page	Retest direct 911 dialing, central notification and location data for every site and remote endpoint on the target release. Treat any dial plan or trunk change as a 911 change requiring documented test calls before cutover.
Dial plan and trunk behavior unchanged for production traffic	Your internal acceptance criteria	Run a test matrix covering internal, outbound, inbound and emergency routes on a staging system with the same dial plan. Record pass or fail for each route before scheduling the production change.
Change control and rollback path	Your change management policy and audit expectations	Keep a tested backup of the database, configuration and FreePBX state, with a documented rollback procedure and a named decision owner. Retain change tickets as evidence of who approved the upgrade and when.

How the current release changes the upgrade path

Systems on Asterisk 18 or Asterisk 21 no longer receive upstream fixes, so each new vulnerability in the SIP stack, codec handling or management interfaces stays open until the platform moves. Exposed SIP trunks are the most common target for toll fraud, which means the cost of waiting shows up on the carrier bill as well as in the security review. Treat this as an urgent project that starts with an inventory and a bridge to a supported release.

Inventory first: record exact Asterisk and FreePBX versions, loaded modules, custom AGI scripts and any hand-patched packages, because end-of-life systems often carry changes that no one documented.
Contain while you wait: restrict SIP signaling to known carrier addresses, disable unused management interfaces, and review call-limit and outbound fraud rules until cutover.
Expect a stepped path: if the FreePBX major version on the server cannot run your target Asterisk directly, plan an intermediate upgrade first and test each hop.
Build the target in parallel: stand up the new release beside production and replay dial plans there, so cutover is limited to moving trunks and extensions.

Before committing a date, confirm the end-of-life date for your branch on the Asterisk lifecycle page and check the FreePBX release notes for the Asterisk versions your FreePBX release supports.

Choosing Asterisk 22 or 24 as the target release

Asterisk 22 and 24 are the candidate targets for most upgrades planned now, and the right pick depends on how long your organization needs the platform to stay supported. The four drivers below connect the lifecycle question to the FreePBX, add-on and feature checks that decide whether a target release is safe to run.

Support horizon against your replacement cycle

Start with the date the release leaves support, not the release number. Compare that date with how long your organization expects this PBX to run before its next major replacement, including any planned move to a hosted or contact center platform. Ask the partner to confirm the published end-of-life date for each candidate in the Asterisk lifecycle documentation at the time of decision, and record who approved the horizon. A release that expires before your next planned change forces a second upgrade within a short window.

FreePBX compatibility for the chosen GUI

Confirm which FreePBX release series supports your target Asterisk version before you commit. Check the FreePBX compatibility matrix, then build a lab with the exact combination you plan to run, including the OS, database and PHP versions the GUI requires. Test module installs, updates and backups on that stack. The network engineer and the PBX administrator should sign off together, since a GUI mismatch can block changes even when the Asterisk core is healthy.

Installed add-ons and commercial components

List every custom dial plan include, AGI script, third-party module and commercial contact center or call recording component on the current system. For each, get written confirmation from its vendor that it supports the target Asterisk release and FreePBX combination. Recording and CRM screen pop integrations often fail first because they depend on internal APIs or database schemas. Assign the application owner to sign off on the lab results, and keep a rollback path for any component without a confirmed build.

Feature needs for SIP and TLS

Identify the SIP and security features your sites depend on, such as TLS transport, SRTP, codec choices, registration behavior for remote endpoints and any changes to peer or trunk configuration. Do not assume a target release supports a feature until the release notes and your own test confirm it. Build test calls from each trunk provider and from a sample of handsets and softphones, then record results per feature. The security owner and the telephony lead should approve the final configuration before cutover.

How the upgrade runs from inventory to post-cutover review

The sequence turns an Asterisk upgrade into a set of recorded decisions, from what is running today to a signed record that the new release is live and stable. Each phase hands a named artifact to the next, so the cutover decision rests on evidence rather than memory.

Inventory the running system and its dependencies
Map every dial plan context, SIP trunk, extension group, queue, IVR, custom AGI script, FreePBX module and integration that touches call flow, including CRM screen pops, paging and call recording. The team lists the installed Asterisk and FreePBX versions, the third-party or commercial modules in use and who owns each one. The output is a dependency inventory signed off by telephony and operations owners. The step is done when every call path in the inventory has a named owner and no integration is listed as unknown.
Select the target release and record compatibility
Compare the current release against the published Asterisk lifecycle and choose the target line, such as Asterisk 22 or 24, based on the support window the organization needs. Check FreePBX version compatibility, module support for the target, and any vendor or add-on support statements. Confirm these points with the project and vendors directly, since support status changes over time. The output is a compatibility record listing each component, its supported version and the open items. The step is done when the record is reviewed and every open item has an owner.
Build the lab and produce the configuration diff
Stand up an isolated lab that mirrors production dial plans, trunk definitions, queue settings and module versions, using sanitized numbers and test SIP endpoints. Install the target release, import the current configuration, and apply the required changes. Compare the old and new configuration files and database settings line by line so that deprecated options, renamed parameters and changed defaults are visible. The output is a configuration diff with a written reason for each change. The step is done when every diff line is accepted, rejected or flagged for a fix.
Execute dial plan and 911 test cases
Run a scripted test suite against the lab covering inbound and outbound calls, internal extensions, transfers, queues, IVR paths, voicemail, call recording, failover trunks and time-of-day routing. Include direct 911 dialing tests and central notification checks, and record the dispatchable location data the system sends for each test phone. Testers repeat the suite after each fix. The output is a test log with case IDs, expected results, actual results and retest references. The step is done when every case passes or has an approved exception with a documented workaround.
Stage the cutover with a rollback plan
Move a limited set of trunks, extensions or a single site to the new release first, and watch call completion and registration behavior before widening the change. Write the rollback steps in advance, including how to restore the prior Asterisk packages, configuration snapshot and database backup, and who can trigger the rollback. Rehearse the rollback in the lab. The output is a cutover runbook and a rollback plan approved by the change board. The step is done when the rollback has been rehearsed and the cutover window and decision owners are recorded.
Hold a post-cutover review and sign the go or no-go record
After the change, compare live call metrics, error logs, trunk status and 911 test results against the pre-cutover baseline. Review any incidents, user reports and open defects, and decide whether the stage is complete before moving to the next one. The output is a post-cutover review report and a signed go or no-go record for each stage. The record also updates the compatibility record and the configuration baseline so the next upgrade starts from current facts. The step is done when the review is signed and the baseline is stored under change control.

How to test dial plans and 911 routing before cutover

A dial plan that completes a basic test call can still fail after an Asterisk upgrade. Default values for options such as codec negotiation and SIP handling can change between major releases, modules that were loaded implicitly in the old build may not load in the new one, and FreePBX regenerates extensions_custom.conf, pjsip.conf and related files from its own settings, so a module upgrade can rewrite routing you never touched by hand. The test plan therefore has to exercise the routes, not just prove that the PBX answers. Before you start, confirm with your FreePBX version's release notes which Asterisk release it supports, and confirm which channel driver (chan_pjsip or the legacy driver) your configuration depends on.

Build a test matrix with one row per route class: inbound from each trunk and number range, outbound to local, long distance and international destinations, internal extension-to-extension and extension-to-queue, emergency calls, and failover when the primary trunk or a registration is down. For each row, record the expected caller ID, the selected trunk, the dial string after transformation, the codec negotiated and the final destination. Run the full matrix against the lab build first, using the same FreePBX backup you will restore in production. Then repeat the emergency and failover rows, plus a sample of inbound and outbound calls, against a canary trunk carrying a small share of live traffic. Log every result with a timestamp, the build identifier and the tester's name so that a later failure can be traced to a specific change.

For emergency routing, do not write your own test steps from this page. The location and notification requirements, and how to test and document them for fixed, non-fixed and remote phones, are covered in the 911 compliance guide for open source PBX deployments, which you should use as the checklist for emergency calls in the matrix. Treat the emergency rows as a go or no-go gate: if any emergency test fails on the lab build or the canary, the cutover waits. Keep the signed test record with the change ticket, since it is the evidence an auditor or a telecom regulator will ask for.

Which upgrade records auditors and regulators ask for

This table lists the records an assessor or regulator is likely to ask for when an Asterisk or FreePBX upgrade changes call routing, 911 handling or recordkeeping. Each row names the evidence, what it proves and the component or step that produces it. DeployOpen prepares this evidence for independent auditors, but it does not issue any audit report or attestation.

Evidence item	What it proves	Component that produces it
Version inventory	The exact Asterisk, FreePBX, OS, database and module versions running before and after cutover, with the lifecycle status of each	Configuration management record and package manager output, checked against the Asterisk release lifecycle published by the project
Lifecycle decision record	Why the target release was chosen, including its support window and the planned date for the next upgrade	Written decision signed by the change owner, referencing the published end-of-life and security-only dates for each release
Configuration diff	Every change to dial plan, SIP settings, codecs, trunks and modules between the old and new builds, with no unreviewed edits	Version control diff of the configuration directory, exported before and after the change window
Dial plan test results	Each dial pattern, inbound route, outbound route and queue behaves as designed on the new release	Scripted test calls and result log, run against a staging system that mirrors production routing
911 test log	Emergency calls from each site and device type reach the correct PSAP and notification path after the upgrade	Dated test record from live or lab test calls, with the dispatchable location shown for each test; confirm the test method with your 911 provider and counsel
Change approval	Who reviewed the risk, approved the window and accepted the rollback plan before work began	Change ticket in the ITSM or helpdesk system, with approvals recorded before the change window opens
Rollback test	The team has restored the prior working state from backup within the window it committed to	Dated rollback drill record, including the backup restore steps and the time each step took
Post-cutover call detail records and audit log samples	Calls were logged, recorded where required and retained after go-live, and administrative changes were traceable	CDR export from Asterisk and FreePBX, plus system and admin audit log samples taken after cutover and retained under your retention policy

What to ask an implementation partner before signing an upgrade scope

Start with how the partner tracks the Asterisk and FreePBX lifecycle, because the answer sets your deadline. A good partner names each Asterisk release line in your estate, states which lines are already end of life and which receive security fixes only, and cites the project's published lifecycle information with the date it was checked. Ask for their written upgrade policy: how far ahead of end of life they start a migration, whether they target a long-term support line such as Asterisk 22 or 24, and what evidence they use to choose between them, including the FreePBX version that supports the target release. Ask who on your side owns that decision and how the partner will warn you when a FreePBX module or add-on lags behind a new Asterisk line.

Next, ask how the partner tests dial plans and 911 routing before cutover. The answer should describe a staging system built on the same Asterisk and FreePBX versions as production, with a written test matrix covering every inbound route, outbound route, extension context, time condition, queue and IVR branch, and direct 911 dialing from each site and from remote phones. Each case should record the expected result, the actual result, the tester and the date. Ask who signs the results: a good answer names the engineer who ran the tests, the telecom owner who accepts them, and the person responsible for emergency calling compliance in your organization. Request a sample signed test record before you commit to the scope.

Finally, ask how call detail records, recordings and voicemail stay under audit controls during the move and after it. Look for a plan that preserves existing records before cutover, verifies record counts and checksums after transfer, and keeps old and new storage under the same access logging and retention settings. Voicemail that may contain personal or health information needs encryption in transit, restricted access and documented retention, and the partner should show where each control is configured. After cutover, ask what support is included: who monitors Asterisk and FreePBX security advisories, how quickly patches go into a maintenance window, what response times appear in the contract, and whether security updates for the chosen line continue after the project closes.

What buyers ask about Asterisk upgrades before hiring help

How much effort does an Asterisk upgrade take?

The effort depends on the scope of your telephony, not on the version number alone. The main drivers are the number of dial plan contexts and call flows, how many add-ons and custom modules are loaded, how many integrations (CRM, paging, recording, SIP trunks, mobile clients) depend on the server, how many sites and trunk connections are involved, and whether you have a lab that mirrors production. A single-site server with a standard dial plan and no custom modules is a much smaller job than a multi-site deployment with queues, recording and CRM screen pops. Ask any partner to break the estimate into configuration review, module compatibility, test execution and cutover, so you can see which line items change if your scope changes.

Can our internal team upgrade Asterisk without outside help?

Some teams can, but the upgrade needs skills across several areas at once. Your engineers need working knowledge of Asterisk configuration and the dial plan, SIP signaling and NAT behavior, the specific FreePBX version if you use it, Linux server administration, and database backup and restore. Someone also needs to read the release notes for every version between your current release and the target, check custom code and third-party modules against those changes, and run structured test calls. Ask yourself whether at least two people can cover these skills, whether they have time during a change window, and whether they have performed a cutover on a live telephony system before. If the answer to any of these is no, a partner or a documented internal plan with an outside review is usually safer.

What does our side need to provide for an upgrade?

Telephony upgrades depend on decisions and access that sit outside the server. You will need named owners who can approve the test matrix, the change window and the go or no-go decision at cutover. Your SIP trunk provider must be involved early, because they may need to confirm supported codecs, registration behavior, IP allow lists and any changes to their side of the connection. Operations staff must agree on a change window that covers after-hours routing and queue coverage, and someone must confirm which users, phones, gateways and integrations will be tested. Ask the partner to produce a written list of these dependencies with an owner and a date for each, before work starts.

Can Asterisk be upgraded in place or does it need a parallel build?

Both approaches are used, and the choice depends on how far you are moving and how much risk you can accept. An in-place upgrade updates the existing server and is faster to execute, but it leaves less room to roll back if an incompatible module, configuration key or database change causes failures. A parallel build installs the target version on new hardware or a new virtual machine, copies and adapts the configuration, runs the full test matrix and then moves traffic at cutover. Parallel builds cost more in time and infrastructure but make rollback simpler, since the old system stays intact until you are satisfied. For a large dial plan or a multi-version jump, a parallel build is the common recommendation. Confirm the approach in writing and ask how rollback works in each case.

How long does the Asterisk upgrade process take?

The duration is set by the scope agreed in writing, not by a fixed figure. Timelines grow with the number of dial plan contexts to review, the number of add-ons and custom modules to verify, the number of integrations to retest, the number of sites and trunks involved, and whether a lab must be built before testing starts. Scheduling also matters: trunk provider coordination, change windows and sign-off reviews often take longer than the technical work. Before you compare proposals, ask each partner to show the phases (assessment, lab build, test matrix execution, cutover rehearsal, cutover and post-cutover monitoring) with the dependencies for each, so you can see where time is spent and where your own team's availability affects the schedule.

What should a written upgrade quote include?

A written quote should describe the work in enough detail that you can check it against your environment. At minimum, ask for the version path (current release, target release and each intermediate version reviewed), the inventory of dial plans, add-ons, custom modules and integrations in scope, and the test matrix. The test matrix should list each call type (internal, inbound, outbound, transfers, queues, voicemail, emergency calls, fax and paging), the expected result and the person who signs it off. The quote should also contain a rollback plan with the trigger conditions, the steps, the time needed to restore service and the backup and restore procedure. Confirm which items are one-time work and which are ongoing support, what is excluded, and how changes to scope are priced.

How DeployOpen scopes and runs an Asterisk upgrade

DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Asterisk or FreePBX upgrade is handled as a scoped project in your environment. We start from your current version, your dial plan and your lifecycle obligations, then agree the work in writing before any change reaches a production line.

How we scope

Inventory your current Asterisk and FreePBX versions, modules, trunks and custom dial plan logic
Map which lifecycle state applies to your version and what support obligations follow from it
Agree in writing whether the target is Asterisk 22 or 24 and which FreePBX release is compatible
Define the test matrix, cutover window and rollback criteria before fixed-scope work begins

How we build

Stand up a staging environment that mirrors production trunks, extensions, queues and call flows
Migrate and review configuration, then run scripted test calls against every dial plan path
Verify 911 routing, emergency call handling and call recording in the upgraded build where in scope
Document configuration changes, module compatibility results and known deviations for your change board

How we hand over

Deliver a cutover runbook with ordered steps, timing checkpoints and a tested rollback procedure
Provide test evidence showing which dial plan paths were exercised and their outcomes
Walk your operations team through the upgraded system, monitoring points and alert thresholds
Record ownership of each component so your staff know who acts on which fault

How we support

Offer post-cutover support for a defined period as agreed in the written scope
Available as a retainer for ongoing patching, the next lifecycle upgrade and regression testing
Re-run the dial plan test suite whenever trunks, modules or FreePBX are changed
Confirm support terms, response expectations and after-hours coverage with us before signing