Planning your upgrade path to Ansible Automation Platform 2.6

The release of Red Hat Ansible Automation Platform 2.6 marks a pivotal milestone. Before you begin your upgrade, there are 3 key things you need to know to make your transition smoother:

• This is the last version with an RPM-based installer. Red Hat Ansible Automation Platform 2.6 using the RPM method is only available for Red Hat Enterprise Linux (RHEL) 9, and the RPM installer will be retired after this release. Ansible Automation Platform 2.7 will only support a containerized install method, the Red Hat OpenShift operator, or our cloud services, so now is the time to begin the transition.
• Ansible Automation Platform 2.6 is a cornerstone release. Every upgrade path to future versions of the platform must pass through 2.6. There's no getting around it.
• RHEL 8 is no longer supported. If you're still on RHEL 8, you'll need to migrate to RHEL 9 (or RHEL 10) before upgrading to Ansible Automation Platform 2.6.

Planning your upgrade

As you plan your transition to Ansible Automation Platform 2.6, two important considerations should shape your upgrade plan:

Only one thing can change at a time. Whether it's the underlying operating system (OS), the installation method, or the product version, the installer only handles one change per run. That means you may need to run it multiple times. Check the official documentation for details on how this works.

In most cases, you'll need a fresh install. Outside of a few specific scenarios, such as upgrading from 2.5 to 2.6 on the same architecture or certain Red Hat OpenShift operator deployments, you'll need to deploy a new Ansible Automation Platform 2.6 instance and then migrate your configuration to it.

This raises the key question: How do you bring your existing configuration into the new instance?The answer starts with understanding that your Ansible Automation Platform configuration lives in a PostgreSQL database. Your upgrade strategy is about how you move that data forward.

Approaches to upgrading

There are two paths to Ansible Automation Platform 2.6: a database-centric migration or an API-centric migration. The right choice depends on your environment, your requirements, and what you're willing to trade off.

A database-centric approach treats Ansible Automation Platform as a stateful system where the data is the source of truth. An API-centric approach treats the platform as Configuration as Code (CaC), where the source of truth is in the configuration files. See the table below to evaluate the technical considerations for each approach:

Database-centric migrations

Database-centric migrations are the documented, fully supported path which preserves and migrates your entire database through the upgrade process. The challenge? The "upgrade dance." You may be moving from RHEL 8 to RHEL 9, from RPM to containerized, and from Ansible Automation Platform 2.4/2.5 to 2.6—and each of those is a separate step requiring its own infrastructure. 

That's potentially a lot of intermediate environments to provision and manage, and depending on the starting point and end goal of the migration efforts, as well as the scale of the environment (and thus, the size of the database), it may be a time-consuming task.

One important caveat: If this complexity is pushing you toward managed cloud service offerings from Ansible Automation Platform, be aware that uploading a database to managed services will require a support ticket. You can find this process documented here. To do this yourself, you’ll need to use the API-centric approach.

API-centric migration

This approach is not formally supported by Red Hat (although the individual components enabling this migration technique are supported). That said, it can be significantly faster, especially for large environments. Since it's a single move to the target platform, there's no need for intermediate installations.

In this method, you’d export the configuration of your Ansible Automation Platform using API calls to store it locally, such as in configuration files or a temporary database. These files can then be modified as needed, and then restored through another platform through the API, as well. This method also has a nice side benefit: It introduces Configuration as Code (CaC) into your workflow, giving you a foundation for managing the platform using CaC methods going forward.

The trade-offs? You'll lose job history (mitigated by an external log aggregator) and you'll need to handle secrets carefully (mitigated by an external secrets manager). You may also need to edit the exported configuration files to get them formatted correctly for import, particularly for private automation hub and Event-Driven Ansible objects.

A note on secrets

Credential and notification secrets are stored in the configuration database and encrypted by the database SECRET_KEY. Because these are encrypted, their values aren’t exported through the API at all. Thus, to gain access to the secrets for your configuration, root access to the database server is required. Since this would expose your secrets in plain text, you’ll need to handle them with extreme care, such as re-encrypting the secrets into an Ansible vault. 

However, If you're using an external secrets manager, such as HashiCorp Vault, this won’t be an issue since those secrets don't live in Ansible Automation Platform. Alternatively, if there’s only a few secrets to manage, it may be just as straightforward to populate the secrets in the new platform.

Considerations for both methods

Regardless of which path you choose, keep this in mind: External integrations and API tokens will likely need attention. 

Ansible Automation Platform 2.5 introduced the automation gateway, a unified front end that connects the automation controller, Ansible automation hub, and the Event-Driven Ansible controller into a single interface. This shifted many API endpoints to new paths. While backwards compatibility for these integration endpoints has been maintained for version 2.6, these will need to be updated for future releases. In addition, most tokens issued by the platform will need to be regenerated and redistributed, additional servers may need to be provisioned, and load balancers will need to be updated to the new gateway service.

Externally managed databases

For customers with externally managed databases, there are additional considerations.  First, Ansible Automation Platform 2.4 uses Postgres 13. This is upgraded to Postgres 15 for 2.5 and PostgreSQL 15 for 2.6. There is also support for PostgreSQL 16 and 17 customer-provided databases in Ansible Automation Platform 2.6. This database upgrade procedure is a key consideration in the migration and “update dance,” and is a key to why customers cannot reuse their existing database without going through this update process.  Specifically for Ansible Automation Platform 2.5+, International Components for Unicode (ICU) must be enabled in customer-provided databases, which is available, but not enabled by default, on most major database providers such as EDB, Amazon Web Services Relational Database Service (AWS RDS), and Azure SQL Database. This database compatibility is why we can’t just update the schema in an existing database.

Playbook compatibility

When you upgrade Ansible Automation Platform, the version of ansible-core shipped in the default execution environment upgrades too. The good news is that you can always run older execution environments on newer versions of the platform, so backward compatibility is maintained, but upgrading is strongly encouraged to take advantage of new functionality and security fixes.

If you upgrade your execution environments, you’re upgrading to a new version of Ansible core, which can bring some changes.  Here's what you can expect:

Ansible Automation Platform 2.4 moving to 2.6 (ansible-core 2.15 moving to 2.16)

This is a minor upgrade. The most notable change is that some warnings in conditional statements are now treated as errors. Beyond that, the impact is minimal.

Moving to ansible-core 2.18 (optional execution environment in Ansible Automation Platform 2.6) An optional supported execution environment for Ansible Automation Platform 2.6, this upgrade brings significantly more change. Specifically:

• Python 2.7 and 3.6 on target nodes are no longer supported versions. This means you can no longer target RHEL 6 hosts with this execution environment. RHEL 7 hosts will need Python 3.8 (available via Red Hat Software Collections) to be automated with Ansible Automation Platform.
• Python 3.11  is now the included Python version in your execution environment. Custom and third-party Python libraries need to be updated to compatible libraries with 3.11.
• Python's "dead batteries" cleanup is underway. PEP 594 is removing unmaintained, insecure, and obsolete libraries from the standard library over the next several Python releases. Deprecation warnings begin with Python 3.11; some libraries are removed in version 3.12, and the mass removal happens in version 3.13.

For the vast majority of customers, this isn't an immediate concern—but it's worth paying attention to deprecation warnings now so you can prepare.

For the full details on supported ansible-core versions, see Red Hat's official support policy.

The transition to Ansible Automation Platform 2.6 is more than just a version update—it’s a strategic move that sets the stage for the next generation of automation. By choosing the migration path that best fits your infrastructure today, you can keep your automation resilient, security-focused, and ready for whatever comes next.

Additional resources

• Article: Automating Ansible Automation Platform 2.6 Upgrades with Python, AsyncIO, and Bulk Operations
• Ansible Automation Platform release notes and documentation.
• What's new with Ansible Automation Platform