AAP 2.4 reached the end of maintenance support on 30 June 2026, according to Red Hat's announcement. Your automation keeps running, but coverage changes: bug fixes and security patches are no longer applied to 2.4, and the operational risk grows every month. You have two paths: upgrade to AAP 2.6 or, if you cannot make it in time, talk to your account team about Extended Lifecycle Support (ELS). This post explains what changes, how to plan the upgrade and what to check first.
What "end of maintenance" means
According to Red Hat's announcement, once maintenance support ends:
- The usual bug fixes and security patches (CVEs) are no longer applied to 2.4.
- You can still open support cases, but the resolution for most of them will be to recommend upgrading to a supported version.
- There are no new enhancements; those ended when full support ended.
The AAP lifecycle policy splits a version's life into full support, Maintenance 1 and Maintenance 2, with an Extended Lifecycle Support (ELS) add-on separate from those.
For operations teams, this forces a decision on how long production automation can stay on an ageing version. Security has to assess the exposure, and service owners have to know which business processes depend on it. If you cannot upgrade now, confirm with Red Hat whether you have access to ELS, what it covers and for how long, as its upgrade page recommends: do not assume your current subscription includes it.
The options, in a table
| Option | What it involves | When it fits |
|---|---|---|
| Upgrade to AAP 2.6 | Path documented by Red Hat from 2.4 | You have a change window and a test environment |
| Extend with ELS | Extended coverage through your Red Hat account team | The upgrade will not fit before your next window |
| Do nothing | No new fixes for 2.4 | Only as a conscious decision with a date |
ELS terms and price depend on your contract: Red Hat points to your account team, so this post cites no figures.
How to plan the upgrade from 2.4 to 2.6
Start by finding out what you really have: versions of each component, operating system, database, installation method, topology, integrations and execution environments. According to the AAP 2.6 upgrade guide, you must first be on the latest 2.4 release. A direct upgrade to 2.6 is supported for RPM installations on RHEL 9 and for OpenShift deployments. An RPM installation on RHEL 8 must first be backed up and restored onto new RHEL 9 hosts, because upgrading the operating system to a new major version on the same host is not supported. Upgrading from the containerised 2.4 deployment that shipped as a Technology Preview is not supported either.
The plan has to include the platform gateway: infrastructure capacity, network access, certificates, authentication and permissions. According to the same guide:
- Review SAML configurations: encrypted private keys prevent the authenticators from being migrated.
- Event-Driven Ansible 2.4 needs separate handling: its database cannot be migrated to 2.6 and must be deleted before upgrading.
- Some APIs become deprecated in 2.6: review your integrations and token usage against the target version.
Rehearse in a representative environment, test the restore and validate critical jobs, schedules, credentials, project sync and user access. Measure preparation, migration, downtime and recovery separately, and define the acceptance criteria and the reasons to roll back beforehand.
After 2.6
Think now about the next upgrade: according to Red Hat's guide, 2.6 is the last release for RPM installations, and moving to 2.7 or later requires migrating first to a containerised or OpenShift deployment. The upgrade page adds that there is no direct path from 2.4 to 2.7.
What I would check first in your environment
What a lifecycle review usually finds
A lifecycle review looks beyond the platform version. These are patterns worth investigating, not findings from any particular organisation: outdated execution environments, unsupported dependencies, undocumented integrations and procedures that no longer match the deployed configuration.
Each component's support can differ from the platform's. For example, Red Hat's lifecycle page states that ansible-core 2.15 is no longer supported after June 2026, including for anyone extending AAP 2.4 coverage, and recommends moving to at least 2.16. Collections also have their own lifecycle.
It is also worth looking for backups without a tested restore, excessive permissions, service accounts without an owner and critical jobs without regression tests. The useful outcome is a prioritised remediation register: each dependency with its support status, business impact, owner and deadline. That turns the end-of-maintenance date into a transition plan you can execute.
If you do not know which version you run, or nobody on your team has done an AAP upgrade, the RHEL and AAP lifecycle review covers versions, support dates, patching and playbooks in three days.