AAP 2.6 Upgrade Guide: RHEL 8→9, RPM→Containerized Migration Paths

Ansible Automation Platform 2.6 is a cornerstone release — every upgrade path to future versions must pass through 2.6. This guide covers every upgrade and migration scenario, from AAP 2.4/2.5 on RHEL 8 through to AAP 2.6 on containers or OpenShift.

Three Critical Things to Know

Last RPM installer: AAP 2.6 is the final version with RPM-based installation. AAP 2.7 removes it entirely. Migrate to containerized or OpenShift now. Cornerstone release: Every future upgrade must go through 2.6. You cannot skip it. RHEL 8 is gone: No direct upgrade from RHEL 8. You must migrate to RHEL 9 (or 10) first.

See also: AAP 2.6 Migration from AWX: Complete Upgrade and Data Migration Guide

Upgrade vs Migration

| Term | What Changes | Method | |------|-------------|--------| | Upgrade | AAP version (e.g., 2.5 → 2.6) | Run installer | | Migration | Install type (RPM → container) or OS (RHEL 8 → 9) | Backup + restore |

Only one thing changes at a time. You cannot upgrade AAP version AND change install method in the same step. Multiple steps may be required.

Upgrade Matrix: AAP 2.4 → 2.6

| From | To RPM (RHEL 9) | To Container (RHEL 9/10) | To OCP Operator | |------|-----------------|--------------------------|-----------------| | AAP 2.4 RPM on RHEL 8 | Migrate | Migrate | Migrate | | AAP 2.4 RPM on RHEL 9 | Upgrade | Migrate | Migrate | | AAP 2.4 OCP Operator | N/A | N/A | Upgrade |

See also: Ansible Automation Platform Upgrade Guide: Migration Path from AAP 2.4 and 2.5 to 2.6

Upgrade Matrix: AAP 2.5 → 2.6

| From | To RPM (RHEL 9) | To Container (RHEL 9) | To Container (RHEL 10) | To OCP Operator | |------|-----------------|----------------------|----------------------|-----------------| | AAP 2.5 RPM on RHEL 8 | Migrate | Migrate | Migrate | Migrate | | AAP 2.5 RPM on RHEL 9 | Upgrade | Migrate | Migrate | Migrate | | AAP 2.5 Container on RHEL 9 | N/A | Upgrade | Migrate | Migrate | | AAP 2.5 Container on RHEL 10 | N/A | N/A | Upgrade | Migrate | | AAP 2.5 OCP Operator | N/A | N/A | N/A | Upgrade |

"Upgrade" = direct, in-place upgrade. "Migrate" = backup, install fresh, restore.

Two Migration Approaches

Database-Centric Migration (Officially Supported)

The database is the source of truth. Everything migrates — job history, users, passwords, logs.

Pros: • Fully supported by Red Hat • Preserves all data including job history and secrets • SECRET_KEY migrates automatically

Cons: • May require intermediate environments (the "upgrade dance") • Carries over technical debt (orphaned objects, old logs) • Time-consuming for large databases

Example workflow (AAP 2.5 on RHEL 8 → AAP 2.6 containerized on RHEL 9):

1. Backup AAP 2.5 data on RHEL 8
2. Install fresh RHEL 9 server + AAP 2.5 RPM
3. Restore backup to RHEL 9 server
4. Upgrade AAP 2.5 → 2.6 RPM on RHEL 9
5. Migrate AAP 2.6 RPM → 2.6 containerized on RHEL 9

API-Centric Migration (Community Approach)

Configuration as Code is the source of truth. Export via API, modify, import to new instance.

Pros: • Significantly faster for large environments • Single move to target — no intermediate installations • Introduces Configuration as Code (CaC) workflow • Clean slate — no technical debt

Cons: • Not formally supported by Red Hat • Loses job history (mitigate with external log aggregator) • Secrets need manual handling • Export format may need editing for hub and EDA objects

Tools: ansible.controller collection, REST API

Handling Secrets

Credentials and notification secrets are encrypted by the database SECRET_KEY. They are NOT exported through the API. To migrate secrets: • External secrets manager (HashiCorp Vault, etc.): No issue — secrets don't live in AAP • Few secrets: Manually re-enter in the new platform • Many secrets: Extract from database with root access, re-encrypt into Ansible Vault

See also: Install Ansible Automation Platform in Red Hat Ansible OpenShift Platform operator via Operator

RHEL 8 → RHEL 9 Migration

Since RHEL 8 is no longer supported, you must migrate to RHEL 9 before upgrading to AAP 2.6.

LEAPP in-place upgrade is NOT supported. You must: Backup AAP on RHEL 8 using the setup script Install fresh RHEL 9 server Install AAP (same version as RHEL 8) on RHEL 9 Restore backup on RHEL 9 Upgrade to AAP 2.6

PostgreSQL Requirements

AAP 2.6 requires PostgreSQL 15, 16, or 17. The installer automatically upgrades managed databases to PostgreSQL 15.

| AAP Version | Default PostgreSQL | |-------------|-------------------| | AAP 2.4 | PostgreSQL 13 | | AAP 2.5 | PostgreSQL 15 | | AAP 2.6 | PostgreSQL 15 |

External databases: Must be upgraded to PostgreSQL 15+ before attempting AAP 2.6 upgrade. ICU support must be enabled (available but not default on AWS RDS, Azure SQL, EDB).

Playbook Compatibility

When you upgrade AAP, the default execution environment's ansible-core version changes:

AAP 2.4 → 2.6 (ansible-core 2.15 → 2.16)

Minor upgrade. Main change: some conditional statement warnings are now errors. Impact is minimal.

Optional: ansible-core 2.18 Execution Environment

AAP 2.6 includes an optional execution environment with ansible-core 2.18. Significant changes: • Python 2.7 and 3.6 no longer supported on target nodes — cannot target RHEL 6; RHEL 7 needs Python 3.8 via Red Hat Software Collections • Python 3.11 is now included in the execution environment • PEP 594 "dead batteries": Deprecated libraries being removed from Python stdlib (deprecation warnings in 3.11, removals in 3.12-3.13)

You can always run older execution environments on newer AAP versions — backward compatibility is maintained.

External Integration Considerations

AAP 2.5 introduced the automation gateway — a unified front end connecting controller, hub, and EDA. This shifted many API endpoints to new paths.

After upgrading to 2.6: • API endpoint backward compatibility is maintained for 2.6 • Plan to update integrations for future releases • Most tokens need to be regenerated and redistributed • Load balancers need updating to the new gateway service

Pre-Upgrade Checklist

☐ Verify current AAP version and installation method ☐ Check RHEL version (RHEL 8 requires migration first) ☐ Verify PostgreSQL version (must be 15+ for external DBs) ☐ Backup current AAP data ☐ Test playbooks with target ansible-core version ☐ Document external integrations and API tokens ☐ Plan migration path from upgrade matrix ☐ Provision any intermediate environments needed ☐ Schedule maintenance window ☐ Test upgrade in non-production environment first

FAQ

Can I skip AAP 2.5 and go directly from 2.4 to 2.6?

Yes, if your current install is AAP 2.4 RPM on RHEL 9 or AAP 2.4 on OpenShift. Direct upgrade from 2.4 to 2.6 is supported in those scenarios. RHEL 8 installations must migrate to RHEL 9 first.

How long does the upgrade take?

Depends on database size and migration path. A direct upgrade (same method, same OS) takes 30-60 minutes. A full migration (RHEL 8 → RHEL 9 + RPM → containerized) with intermediate steps can take several hours.

Should I use database-centric or API-centric migration?

Use database-centric for the supported path with full data preservation. Use API-centric if you want a clean start, have a large environment, or plan to adopt Configuration as Code. Consider API-centric if migrating to managed cloud services.

What happens to my custom execution environments?

Custom execution environments are stored in your automation hub registry and are preserved during upgrade. After upgrading, you can continue using older execution environments on the new platform.

Conclusion

Start planning your AAP 2.6 upgrade now — it's the required gateway to all future versions. Check your current RHEL version and installation method against the upgrade matrix, verify PostgreSQL compatibility, and test playbooks with newer ansible-core. For RHEL 8 users, budget time for the OS migration step before the AAP upgrade.

Related Articles

• AAP 2.6 Install Guide • AAP 2.6 Tested Deployment Models • What's New in AAP 2.6 • Ansible 13 Upgrade Guide