Back to all use cases

AssessmentCross-Industry

AWX releases are paused and ansible-core 2.19 leaves maintenance in November 2026, so the control plane needs a dated plan

IT Operations Team

A typical engagement to check an AWX estate and its execution environments against ansible-core's maintained versions, find the job templates the 2.19 templating changes will break, and decide between staying on AWX with a plan and moving the control plane to Red Hat Ansible Automation Platform.

Overview

This is a typical engagement for an IT operations team that runs its automation from AWX on a Kubernetes cluster, with several execution environment images built over the years on different ansible-core versions. The AWX README says releases are paused and the last one was on 2 July 2024, and ansible-core 2.19 reaches the end of its maintenance in November 2026. AceMQ and a partner Ansible specialist assess the control plane and the execution environments and write the upgrade and platform plan.

Challenge

Two dates meet in the same estate. ansible-core only maintains three versions at a time, so execution environments built on older releases are already out of maintenance, and the move to 2.19 or later changes the templating system: conditionals that relied on truthy evaluation fail where they used to pass. At the same time the AWX operator and database have not moved since the last release, and the team has to decide whether to keep running AWX, with a plan for that, or move the control plane to Red Hat Ansible Automation Platform.

Environment

AWX deployed with the AWX operator on a Kubernetes cluster, an external PostgreSQL database, several custom execution environment images on mixed ansible-core versions, job templates and schedules owned by different teams, and credentials and inventories synced from source control and a CMDB.

Approach

The engagement starts read-only. AceMQ inventories the AWX instance, its operator, database and execution environments, records the ansible-core version inside each image, and runs the team's own job templates against a 2.19 or later execution environment in a staging AWX to see which fail and why. AceMQ writes no playbooks or roles: the findings name the failing tasks and the porting-guide change behind each, and the owning teams fix their content.

Solution

  1. Inventories the AWX instance, operator version, PostgreSQL database and every execution environment image with the ansible-core version it carries
  2. Maps each execution environment to ansible-core's maintained versions and their end-of-maintenance months
  3. Runs existing job templates against a 2.19 or later execution environment in staging and lists the tasks that fail, with the porting-guide change behind each
  4. Reviews AWX backup and restore, the operator upgrade path and the database before any change to the control plane
  5. Sets out the options for the control plane: stay on AWX with a support and upgrade plan, or move to Red Hat Ansible Automation Platform, with what each involves
  6. Writes the order of change: execution environments first, then job templates by owning team, then the control plane decision

Outcome

The engagement delivers an inventory of the control plane and every execution environment with its ansible-core version, a list of the job templates and tasks that fail on 2.19 or later with the reason for each, a tested AWX backup and restore, a written comparison of staying on AWX and moving to Ansible Automation Platform, and a dated upgrade order the operations team can schedule. AceMQ gives no Red Hat licensing advice.

Technologies

AnsibleAWXKubernetesPostgreSQL

Ready for an Ansible Health Check?

AceMQ's senior Ansible engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.