Plan your Ansible Automation Platform upgrade

Before you upgrade Ansible Automation Platform, review the changes that affect your upgrade path and any actions you must take before and after the upgrade.

Note

You must be on the latest patch release of your current minor version before you upgrade to the next supported version.

 Warning
To upgrade to Ansible Automation Platform 2.7, you must be running a containerized or OpenShift Container Platform deployment. RPM-based deployments are not supported as an upgrade path to 2.7. If you are running an RPM-based deployment, migrate to a containerized or OpenShift Container Platform deployment before you upgrade.
Upgrading from the previous minor release

Upgrading from the immediately previous minor release does not involve changes to the platform infrastructure requirements, architecture, or services. The platform gateway service is already in place.

Note the following:

  • If you previously upgraded from a pre-gateway version, you must have completed the migration of your authentication methods and users before upgrading further, as legacy authenticator functionality has been removed.
  • During the upgrade, the system removes any users that were not fully migrated during the previous upgrade to the platform gateway. Users who have previously merged their user records continue to function as expected.
  • Users from a pre-gateway installation who never successfully logged in through the platform gateway cannot log in after the upgrade. These users retain backward compatibility for direct automation execution access but cannot access the full platform. Ensure all users have successfully logged in through the platform gateway before upgrading.
  • Unified RBAC management across Ansible Automation Platform components: All Ansible Automation Platform collections, which support the Configuration-as-Code (CaC) approach, use a standard global environment variable name and module variable name across Ansible Automation Platform components. For more details, see the Release notes.

For more information about upgrading, see the upgrade document for your deployment type:

  • Containerized
  • RPM
  • OpenShift Container Platform
Note

Upgrades from the immediately previous minor release are supported with all deployment types: RPM, containerized, and OpenShift Container Platform.
Upgrading from a pre-gateway version

If you are upgrading from a version of Ansible Automation Platform that predates the platform gateway, note the following:

  • Supported deployment types: You can upgrade directly from RPM and OpenShift Container Platform deployments. Upgrading from a containerized deployment that was Technology Preview is not supported. Upgrading Event-Driven Ansible from a version where it was Technology Preview is also not supported.

    For more information, see the upgrade document for your deployment type: RPM or OpenShift Container Platform.

  • Infrastructure changes: RPM deployments require additional infrastructure compared with pre-gateway versions, due to the addition of the platform gateway service. Infrastructure needs vary depending on factors such as whether you implement a growth or an enterprise deployment.
  • Authentication changes: Enterprise authentication configuration and mappings (for example, SAML, LDAP, OIDC) move from automation controller to the platform gateway as part of the upgrade process. You do not need to manually reconfigure these authentication methods after you upgrade.

    See Access management and authentication for information about authentication options.

    Note

    Authentication upgrade improvements apply to RPM and OpenShift Container Platform deployments. Upgrading from a containerized deployment that was Technology Preview is not supported. Upgrading Event-Driven Ansible from a version where it was Technology Preview is also not supported.
  • Identity and access management changes: All automation controller identity and access management (IAM) data moves from automation controller to the platform gateway as part of the upgrade process. With automation controller as the default source of IAM data, users retain their memberships and are assigned appropriate platform-level roles.

    As part of the upgrade process:

    • Users, teams, organizations, their memberships, and common roles move from automation controller to the platform gateway.
    • Automation controller administrators become platform gateway administrators.

    The more organizations, teams, and users being migrated during an upgrade, the longer the upgrade takes. For example, upgrading and migrating 4,000 users, 400 teams, and 40 organizations can take close to two hours.

    Note

    Identity and access management changes apply to RPM and OpenShift Container Platform deployments. Upgrading from a containerized deployment that was Technology Preview is not supported.

    See Identity and access management data migration for more information.

  • API changes: Some APIs have been deprecated. See API changes for platform gateway for more information.
  • Unified RBAC management across Ansible Automation Platform components: All Ansible Automation Platform collections, which support the Configuration-as-Code (CaC) approach, use a standard global environment variable name and module variable name across Ansible Automation Platform components. For more details, see the Release notes.

FAQs on upgrading to 2.6
Copy link

Find concise answers to frequently asked questions about upgrading your system to quickly troubleshoot common issues and plan your migration effectively.

What are the supported installation topologies and operating systems for Ansible Automation Platform 2.6?

Red Hat has adopted a more definitive approach to installation topologies, categorizing them as "growth" or "enterprise" for production-ready setups:

  • Growth topology: is intended for organizations that are getting started with Ansible Automation Platform and do not require redundancy or higher compute for large volumes of automation.
  • Enterprise topology: is intended for organizations that require Ansible Automation Platform to be deployed with redundancy or higher compute for large volumes of automation.

For more information, see Tested deployment models.

Why did my authentication settings that were present in automation controller 2.4 not get imported?
If an authentication method is missing in Ansible Automation Platform 2.6, review the setup_log for migration warnings. These warnings indicate the reason authentication settings were not successfully created during the upgrade to version 2.6.
Why did my upgrade from Ansible Automation Platform 2.4 to 2.6 fail or encounter an error during the SAML authenticator migration?

A SAML authenticator migration fails if the configuration has an encrypted private key. While automation controller in Ansible Automation Platform 2.4 allowed input of an encrypted private key without error, Ansible Automation Platform 2.6 does not support this feature for authenticators and prevents the migration of any SAML configuration containing one.

To prevent migration failure and service disruption for SSO users, you must:

  • Before upgrading: Replace the encrypted private key with an unencrypted one in the SAML authenticator settings on your Ansible Automation Platform 2.4 environment.
  • If the upgrade already failed: Platform gateway did not migrate the authenticator. A local administrator must manually re-create the SAML authenticator in the new Ansible Automation Platform 2.6 environment to restore SSO functionality.
Which Red Hat Enterprise Linux versions are supported for RPM and containerized installations?
RPM installations will continue to be supported exclusively on Red Hat Enterprise Linux 9. Containerized installations support both Red Hat Enterprise Linux 9.4 or later versions of Red Hat Enterprise Linux 9 and Red Hat Enterprise Linux 10 or later versions of Red Hat Enterprise Linux 10 for enterprise topologies.
What is the difference between "upgrade" and "migration" in Ansible Automation Platform 2.6?
An upgrade is an application action, such as updating Ansible Automation Platform 2.5 to 2.6. A migration involves moving data, such as from an RPM-based 2.6 installation to a container-based 2.6 installation. New service components are not explicitly required between versions 2.5 and 2.6.
Can I upgrade from 2.4 to 2.6 or must I upgrade to 2.5 first?
Yes you can upgrade directly to 2.6. However note that there might be new system requirements you must update before upgrading.
How will managed cloud customers be upgraded to Ansible Automation Platform 2.6?
All managed cloud customers on Microsoft Azure and Amazon Web Services will be upgraded to 2.6. Two upgrade window options will be available following the platform upgrade: non-production or production environments. Communications will be ongoing from mid-July until late September.
Will migrations be fully supported in Ansible Automation Platform 2.6?
Yes, migrations are fully supported, enabling customers to move from RPM installations to containerized or OpenShift Container Platform environments, or to the managed offering. Customers must be on the latest version of Ansible Automation Platform for their current installation before migrating. The installation program manages new components introduced in version 2.5 for direct 2.4 to 2.6 upgrades.
When upgrading from 2.4 to 2.6 (applies only to RPM or OpenShift Container Platform), what is different about the upgrade process compared with the 2.4 to 2.5 process?
See the Overview of upgrade improvements section.
I’m using Event-Driven Ansible in 2.4, can I upgrade Event-Driven Ansible to 2.6?
If you are using Ansible Automation Platform 2.4 with the technical preview of Event-Driven Ansible controller but want to upgrade to the Ansible Automation Platform 2.6 with Event-Driven Ansible, you must install a new instance of Ansible Automation Platform 2.6 and manually re-create your Event-Driven Ansible configurations in the new, fully integrated environment.
Will my existing 2.4 or 2.5 OAuth Applications/Tokens, Credentials/Customer Credentials, and Personal Access Tokens still work after upgrading to 2.6?

For upgrades from Ansible Automation Platform 2.4 or 2.5 to Ansible Automation Platform 2.6, some manual configuration is required:

  • OAuth applications:
    • Automation controller: You can view and edit existing automation controller applications, but you cannot create new ones. They still function, but they might be removed in a future release. You should plan to migrate to platform OAuth applications.
    • Ansible Automation Platform: Platform OAuth applications provide an updated interface and are the standard for future use. You will move to these applications.
  • Tokens:
    • Automation controller: Automation controller personal access tokens (PATs) are deprecated. You will move to platform gateway PATs.
    • Ansible Automation Platform: Platform tokens provide an updated interface and are the standard for future use. You will move to these tokens.
  • Authenticator configurations:
    • Ansible Automation Platform 2.4 to Ansible Automation Platform 2.6: The migration of all authenticator configurations from the automation controller to the platform gateway is automated. This includes third-party authentication configurations and sensitive data such as SAML private keys or OAuth secret keys. If you use custom LDAP certificates, you must manually migrate them.
    • Ansible Automation Platform 2.5 to Ansible Automation Platform 2.6: Authenticator configurations are not automatically migrated. LDAP settings configured in Ansible Automation Platform 2.5 remain as they were after upgrading to 2.6.
What RBAC (platform gateway and/or automation controller) control permissions will be missing in version 2.6?
  • For 2.4 to 2.6 upgrades: During the upgrade, authenticators and their mappings from the controller are imported into the gateway; therefore, you don’t need to manually migrate authenticators.
  • For 2.5 to 2.6 upgrades: Authenticators and their mappings in the platform gateway continue to function as is, because no changes are imported.
Which version of PostgreSQL does Ansible Automation Platform 2.6 support?
Ansible Automation Platform 2.6 supports PostgreSQL 15 for its managed databases and additionally supports PostgreSQL 15, 16, and 17 for external databases.