Ansible & AWX Upgrades and Support

Ansible and AWX Upgrades and Support for Production Automation

Last reviewed by Tyler Eastridge

AceMQ upgrades, runs and supports the automation platform under your playbooks: ansible-core upgrades on the project's three-version calendar, AWX and Red Hat Ansible Automation Platform controllers, and 24/7 cover with a 15-minute emergency response. AWX releases are paused upstream (the last was on 2 July 2024) and ansible-core 2.19 leaves maintenance in November 2026. AceMQ engineers lead each engagement with partner automation specialists, and AceMQ does not write playbooks or give Red Hat licensing advice.

A senior engineer, not an SDR. No sales sequence attached.

P1 emergency response
15 min
On-call cover
24/7
AceMQ customers
160+
Years in business
10+

Without a controller migration you did not chooseFor production incident cover, see AceMQ Ansible 24/7 support.

Customers

  • Microsoft
  • Henry Schein
  • Enbridge
  • Gojek

Partners

  • Broadcom
  • Redis
  • VMware Tanzu
  • OSSeva

The Problem

Why teams call us about Ansible

Eight Ansible problems that platform teams bring to AceMQ, from a controller on an ansible-core line that is leaving maintenance to an AWX install with no new upstream release to move to. If one describes your week, that is where the review starts.

  1. 01

    ansible-core 2.19 leaves maintenance in November 2026 and the controller still runs it

  2. 02

    The controller runs ansible-core 2.18 or older, which the project no longer maintains

  3. 03

    AWX is the controller, its upstream releases are paused, and nobody has written down what happens next

  4. 04

    Moving to ansible-core 2.19 or later turns playbooks that relied on truthy conditionals into errors, and nobody has run them in staging

  5. 05

    Managed hosts run a Python version that the next ansible-core no longer supports as a target

  6. 06

    Collections and execution environment images are rebuilt without pinned versions, so two runs of the same job template differ

  7. 07

    The controller database, credentials and job history have a backup that has never been restored

  8. 08

    One engineer knows the inventories, credentials and job templates, and a failing production run wakes nobody who can fix it

A good fit if you run AWX or Ansible Automation Platform in production, have a controller on an ansible-core line that is leaving maintenance, or want a written view of versions, backups and access before the next change.

Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Ansible.

Running Ansible in production? Get a quote from a senior engineer, answered within one hour.

Contact Us

How it breaks, and the fix

What happens when the controller moves to ansible-core 2.19 and a playbook relies on a truthy conditional?

ansible-core 2.19 overhauled the templating system. A conditional that relied on a non-boolean value being treated as true or false now raises an error by default, so a job template that ran for years can fail on its first run after the upgrade.

Controller upgraded, two job templates failing

One playbook run, the controller's ansible-core and three job templates

Illustrative

  1. The controller runs an older ansible-core and all three job templates pass, including two that use a bare variable as a condition.

  2. The controller moves to ansible-core 2.19. Templates A and B stop on broken conditionals, which now raise an error by default. Template C has none and passes. The failures appear in production, on the schedule, at night.

  3. The target version is run against every job template in staging first. The findings list each conditional that needs an explicit test, fixed by your team or as scoped work, and the setting that downgrades the error to a warning is used only as a labelled stopgap.

The ansible-core 2.19 porting guide describes the change and recommends testing playbooks and roles in a staging environment with the release. That is the point of the control plane review: the project maintains only three ansible-core versions, so 2.19 leaves maintenance in November 2026 and anything on 2.18 or older has already lost it, which makes the move to 2.19 or later a fact of the calendar, not a choice. The upgrade also changes supported Python versions on the control node and on managed hosts, and execution environment images and collections are rebuilt on top of it. A written rehearsal on your real job templates, with the findings ranked, is the first AceMQ deliverable.

Our Services

Ansible Consulting & Services

AceMQ runs five Ansible service lines: ansible-core and collection upgrades, AWX operations and support, controller migration, a fixed-scope health check, and a credential, inventory and access review. Any of them can roll into 24/7 on-call with a 15-minute emergency SLA. Writing playbooks is not one of them.

  • 01

    ansible-core and Collection Upgrades

    Moving the controller and execution environments to a maintained ansible-core version, with your existing job templates rehearsed on it first.

    • Current ansible-core version recorded for the controller and every execution environment
    • Target version chosen against the three maintained ansible-core versions
    • Control-node and managed-host Python versions checked per release
    • Existing playbooks and job templates run on the target in staging, with breaking changes reported
    • Collection and execution environment version pinning plan
  • 02

    AWX Operations and Support

    Support for the AWX deployment you keep running while upstream releases are paused, and a clear date for when to move.

    • Health, capacity and job-queue review of the deployment
    • Install method read against the project's announcements, including changes to AWX Operator installation
    • Database, credential and job-history backup and restore tested
    • Runbook for failed and stuck jobs
  • 03

    Controller Migration

    Planning and running a move from AWX to Red Hat Ansible Automation Platform, or between controllers, without losing inventories, credentials or schedules.

    • Inventory of job templates, schedules, credentials and RBAC
    • Cut-over in waves with the old controller kept as the rollback
    • Execution environments rebuilt and checked on the new controller
    • Subscription terms stay between you and Red Hat: AceMQ gives no licensing advice
  • 04

    Automation Health Check

    The fixed-scope entry engagement: a written report on the automation platform that your own team can act on, with or without AceMQ afterwards.

    • ansible-core, collection and controller versions against the project's dates
    • Controller capacity, job queue and database
    • Backup status and a restore test
    • Ranked remediation list with owners
  • 05

    Credential, Inventory and Access Review

    Who can run what, against which hosts, with whose credentials, reviewed on the controller as it stands.

    • Credential storage and external secret use
    • Roles and who can run which job templates
    • Dynamic inventory sources and their credentials
    • Audit trail and log retention for job runs
  • 15 MIN SLA

    24/7 Ansible Support

    Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.

    • 15-minute emergency response SLA
    • Senior engineers, no first-line triage layer
    • Proactive CVE & health monitoring
    • Quarterly deployment reviews
    Compare the four Ansible support tiers

Want AceMQ to take this off your team's plate? Tell us about your Ansible estate.

Contact Us

24/7 Support

Ansible Support When It Matters Most

AceMQ Ansible support gives you an AceMQ engineer and a 15-minute first response when the controller is down or production jobs are failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Red Hat support and subscriptions stay with Red Hat: AceMQ does not provide them.

  1. 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
  2. 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
  3. 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
  4. Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements

P1 escalation path

A replay of one P1, from the first page to the written root-cause analysis

SLA 15:00
T+Elapsed15:00
Engineer on your bridge

15-minute P1 response, 24/7.
A response time, not a resolution time.

  1. T+00:00

    P1 opened, on-call engineer paged

    Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.

    Paged
  2. T+15:00

    Senior engineer on your bridge

    A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.

    Live
  3. T+30:00

    Specialists across the stack join

    When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.

    If needed
  4. After

    Written root-cause analysis

    Root cause, the fix applied and the prevention steps, delivered after every P1.

    Every P1

How Our Support Actually Works

Beyond SLAs — the model behind senior-only, zero-cold-start expert access.

  • Engineers Who Know Your Environment

    Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.

  • Live Escalation on Any Ticket

    Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.

  • Proactive Risk Mitigation

    Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.

  • Critical Bug & CVE Intelligence

    Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.

How It Works

What actually happens next

An AceMQ Ansible engagement runs in four stages: a scoping call with a quote within 1 hour, a written control plane and version review, an upgrade or migration plan you approve, then change windows and on-call. Each stage ends in writing.

Quote within 1 hour

Scoping call and quote

A senior AceMQ engineer asks what you run: AWX or Red Hat Ansible Automation Platform, how it is installed, which ansible-core versions the controller and execution environments use, how many hosts and who is on call today. A quote request is answered within 1 hour.

Scoped per estate

Control plane and version review

A fixed-scope read-only review: ansible-core and collection versions, Python on the controller and on managed hosts, the controller install and its database, backups, credentials and job history. Findings are written and ranked by production risk before anything changes.

Scoped per estate

Upgrade or migration plan

A written plan: the target ansible-core version, a rehearsal of your existing job templates on it in staging, the order of changes and a rollback boundary. For a controller move, the order in which inventories, credentials and templates cut over. You approve it before the first window.

Ongoing

Run, review, report

Change windows run with your team, on-call response with a 15-minute P1 SLA, and a written review after each window or incident.

  • Written findings before any change
  • Changes staged and reversible, with a rollback plan
  • Your engineers in the room
  • Ad hoc engagements or an annual partnership

A senior engineer, not an SDR. No sales sequence attached.

Typical engagements

How Ansible engagements run

Typical engagements from AceMQ on the platforms around Ansible, with the environment, what AceMQ assesses or changes and what the engagement delivers. Each card links to the full write-up.

  • Assessment

    ansible-core Upgrade and AWX Control Plane Assessment

    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.

    AnsibleAWXKubernetesPostgreSQL
    Read case study : ansible-core Upgrade and AWX Control Plane Assessment
  • Assessment

    OpenStack Control-Plane Review and SLURP Upgrade Plan

    Infrastructure Team

    A typical engagement for a team running OpenStack on its own hardware: a review of the RabbitMQ message bus and the database behind the control plane, and a written SLURP upgrade plan rehearsed on a copy.

    OpenStackRabbitMQMariaDBKolla-Ansible
    Read case study : OpenStack Control-Plane Review and SLURP Upgrade Plan
  • From our platform practice

    Java Estate Inventory and OpenJDK Distribution Selection

    Mid-Sized Distribution Company

    A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.

    JavaOpenJDKDockerKubernetes
    Read case study : Java Estate Inventory and OpenJDK Distribution Selection
All use cases

Solutions

Every way AceMQ works with Ansible.

AceMQ covers Ansible end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Ansible on your infrastructure and fully managed Ansible on AceMQ infrastructure, plus end-of-life versions.

Projects

Build, fix or move Ansible

Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.

Support and managed services

Keep Ansible running

Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Ansible for you.

Compare the four Ansible support tiers

Side by side

AWX, Ansible Automation Platform or ansible-core alone: what changes?

Three ways to run Ansible in production sit on different lifecycles. AWX is the upstream controller, with releases paused. Red Hat Ansible Automation Platform is Red Hat's commercial product. ansible-core from the command line or CI is the engine under both. AceMQ supports all three and sells none of them. Each row below answers one question about the choice.

AWX, Red Hat Ansible Automation Platform and ansible-core alone compared on release status, who supports it, what you upgrade, cost, where AceMQ helps and fit
QuestionAWX (upstream)Red Hat Ansible Automation Platformansible-core from the command line or CI
What is its release status?Releases are paused during a large-scale refactoring. The last release was on 2 July 2024, per the project README.Red Hat's product. AWX is one of its upstream projects, and Red Hat publishes support phases for each version on its policy page.ansible-core maintains three versions: 2.22 (released 2 November 2026, end of life May 2028), 2.21 (November 2027) and 2.20 (May 2027); 2.19 reaches end of life in November 2026.
Who supports it?The community, through the Ansible Forum and the project's issue tracker.Red Hat, under the subscription.The community project. AceMQ covers the automation around it.
What do you upgrade?The platform around AWX: Kubernetes, the database, execution environment images and ansible-core. AWX itself has no new release to move to.The platform version, on Red Hat's lifecycle.ansible-core and collections, on the project's three-version calendar.
What does it cost?No license fee (Apache license). You pay for the infrastructure and the people.A Red Hat subscription. The terms are between you and Red Hat, and AceMQ gives no licensing advice.No license fee. You pay for the control node and the people.
Where does AceMQ help?Runs and supports the deployment you keep, and plans the move when you choose it.Upgrade planning, migration from AWX, and engineers on call next to Red Hat support.ansible-core upgrades, collection pinning and rehearsals of existing playbooks.
When does it fit?A working install you can support yourselves for now, with a dated plan to move.You want a vendor on the hook for the controller.A small estate run from CI, with no controller to operate.

For the full story on the AWX pause, read AWX paused: supported paths for Ansible. For the support windows of the other open-source tools in your stack, read open-source support windows compared.

Not sure which option fits? A senior Ansible engineer will scope it with you.

Contact Us

One partner, not five

We Support Your Entire Tech Stack

Ansible rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Messaging & Streaming

Databases & Caching

Search & Analytics

Lakehouse & Compute

Observability & Monitoring

Data Integration

Cloud & Containers

API Management

VMware Tanzu

See all 70 technologies we supportShow fewer

Guides, articles and comparisons

Go deeper on Ansible.

Guides from AceMQ engineers on the AWX pause and on support windows across open-source tools, plus the AceMQ services around Ansible: Kubernetes, Docker and monitoring.

Guides

1

Comparisons

9
Show 3 moreShow fewer

Blog posts

1

Related services

Ready to talk Ansible? Get a quote or send us a message.

Contact Us

FAQs

Ansible Questions Answered

Five answers on Ansible from AceMQ: whether AWX can keep running, which ansible-core version to move to, what breaks in a newer version, what AceMQ does next to Red Hat support, and what is out of scope.

Still have questions about Ansible? Email an Expert

AWX releases are paused. Can we keep running it?

The AWX README says the last release was on 2 July 2024 and that releases are paused during a large-scale refactoring, and it describes AWX as one of the upstream projects for Red Hat Ansible Automation Platform. An existing install keeps running as installed. What stops is new upstream releases, so the decision is when to move, not whether it works today. The options are staying on AWX with AceMQ support and a dated plan, moving to Ansible Automation Platform under a Red Hat subscription, or another controller.

Which ansible-core version should we move to?

ansible-core maintains three versions at a time. As of 4 November 2026 those are 2.22 (released 2 November 2026, end of life May 2028), 2.21 (November 2027) and 2.20 (May 2027); 2.19 reaches end of life in November 2026, and 2.18 reached end of life in May 2026. Each release also changes supported Python: the control node needs 3.12 to 3.14 for 2.20 and 2.21 and 3.13 to 3.15 for 2.22, and managed hosts need 3.9 to 3.14 for 2.20 and 2.21 and 3.9 to 3.15 for 2.22. The target version is chosen after the control plane review.

Will our playbooks break on a newer ansible-core?

Some can. ansible-core 2.19 overhauled the templating system, and conditionals that relied on truthy evaluation of non-boolean values now raise an error by default, which a setting can reduce to a warning temporarily. Running your existing job templates on the target version in staging finds these before production does. AceMQ reports what breaks. Rewriting playbook content is your team's work or a separately scoped engagement.

Does AceMQ replace Red Hat support for Ansible Automation Platform?

No. Ansible Automation Platform support comes from Red Hat under your subscription, and AceMQ gives no Red Hat licensing advice. AceMQ supplies the engineers who plan upgrades and migrations, run the controller and answer at night, next to a subscription or on AWX and ansible-core.

Does AceMQ write Ansible playbooks, roles or collections?

No. AceMQ covers the platform they run on: the controller, ansible-core, collections and execution environments, their upgrades, capacity and recovery. Writing or modernizing playbook content and application code is outside this service.

Can we work with AceMQ on Ansible without a long contract?

Yes. AceMQ works on Ansible in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.

How much does AceMQ Ansible support or consulting cost?

Every AceMQ proposal is tailored to your requirements: your Ansible environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Ansible is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.

Let's talk

Tell Us What You Run. We Quote Within 1 Hour.

A senior AceMQ engineer reviews your Ansible estate, tells you what cover fits, and quotes it. Quote requests are answered within 1 hour.

A senior AceMQ engineer, not a sales queueAbout your automation platform, not a pitch deckQuote requests answered within 1 hour

Production incident right now?Email an Ansible Architect

Get in Touch

Talk to an Ansible Expert

Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 hour.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 hour.