AAP 2.7 Upgrade Path: RPM Installer Removed, Containerized-Only, and the Mandatory 2.6 Stepping Stone

Ansible Automation Platform 2.7 makes two breaking changes to how the platform is installed and upgraded: the RPM installation method is removed, and upgrades require AAP 2.6 as an intermediate step. If you are running AAP 2.4 or 2.5 with the RPM installer, you need to plan a two-phase migration before reaching 2.7.

What Changed in AAP 2.7 Installation

RPM Installer Removed

The RPM-based installation method — which installed automation controller, Automation Hub, and EDA directly as system packages on RHEL — is removed in AAP 2.7.

Supported installation methods in AAP 2.7:

Mandatory Stepping Stone: AAP 2.6

You cannot upgrade directly from AAP 2.4 or 2.5 to AAP 2.7. The upgrade path is:

AAP 2.4 ──► AAP 2.6 ──► AAP 2.7
AAP 2.5 ──► AAP 2.6 ──► AAP 2.7
AAP 2.6 ──────────────► AAP 2.7   ✓ direct

This stepping stone applies regardless of installation method.

Install Method Migration Rules

If you want to change installation method (e.g., from RPM to containerized), the migration must happen while on the same AAP version:

AAP 2.6 RPM ──► AAP 2.6 Containerized ──► AAP 2.7 Containerized   ✓
AAP 2.6 RPM ──► AAP 2.7 Containerized                              ✗ (must migrate method first)

You cannot combine a version upgrade with an install method change in a single step.

See also: AAP 2.6 Upgrade Guide: RHEL 8 to 9 and RPM to Containerized Migration

Upgrade Path Decision Tree

Where are you now?
│
├─ AAP 2.6 Containerized ──► Upgrade to 2.7 Containerized (single step, see below)
│
├─ AAP 2.6 Operator (OCP) ──► Upgrade to 2.7 Operator (single step, see below)
│
├─ AAP 2.6 RPM
│   └─ Migrate to 2.6 Containerized first, then upgrade to 2.7
│
├─ AAP 2.5 (any method)
│   └─ Upgrade to 2.6 → then follow 2.6 path above
│
└─ AAP 2.4 (any method)
    └─ Upgrade to 2.6 → then follow 2.6 path above
        (See: AAP 2.4/2.5 to 2.6 upgrade guide)

Pre-Upgrade Checklist

Before upgrading from AAP 2.6 to 2.7:

• ☐ Confirm current version: automation-controller-manage --version
• ☐ Back up the AAP database and configuration
• ☐ Run aap-detect-direct-component-access to find scripts using direct component APIs — these break in 2.7
• ☐ Audit scripts using controller/Hub PATs — replace with gateway tokens before upgrading
• ☐ Verify no external auth providers are configured directly in controller or Hub — migrate to gateway level
• ☐ Review collections in ee-supported: ansible-lint, cloud.common, cloud.terraform, redhat.rhv, trendmicro.deepsec, junipernetworks.junos are removed
• ☐ Update Execution Environment definitions that use ee-minimal:latest — the :latest tag is removed; use a version-pinned tag

Upgrading AAP 2.6 Containerized to 2.7

# Download the 2.7 containerized installer bundle
curl -O https://registry.redhat.io/ansible-automation-platform/aap-setup-bundle-rhel9:2.7

# Verify your existing inventory is compatible
./setup.sh --check-upgrade --inventory /etc/ansible-automation-platform/inventory

# Run the upgrade
./setup.sh --upgrade --inventory /etc/ansible-automation-platform/inventory

The containerized installer performs an in-place upgrade: it replaces container images, runs database migrations, and restarts services. The upgrade is non-destructive — if it fails mid-way, the installer rolls back to the previous state.

Inventory Changes for 2.7

Review your AAP 2.6 inventory for deprecated options:

# /etc/ansible-automation-platform/inventory

[automationcontroller]
controller.corp.example.com

[automationhub]
hub.corp.example.com

[automationeda]
eda.corp.example.com

[all:vars]
admin_password='{{ vault_admin_password }}'
pg_host='db.corp.example.com'
pg_username='aap'
pg_password='{{ vault_pg_password }}'
pg_database='aap'
pg_port=5432

# 2.7: direct component routes are removed — gateway_fqdn is the single entry point
gateway_fqdn=aap.corp.example.com

# Removed in 2.7 — do not set these
# controller_external_route=true    (deprecated)
# hub_external_route=true           (deprecated)
# eda_external_route=true           (deprecated)

See also: How to Upgrade from AAP 2.4 to AAP 2.6 — Step-by-Step Guide

Upgrading AAP 2.6 Operator (OCP) to 2.7

On OpenShift, the AAP operator handles the upgrade. Update the AnsibleAutomationPlatform CR to 2.7:

apiVersion: aap.ansible.com/v1alpha1
kind: AnsibleAutomationPlatform
metadata:
  name: aap
  namespace: ansible-automation-platform
spec:
  # Change from 2.6 to 2.7
  image_pull_policy: IfNotPresent

  controller:
    replicas: 2
    # ee-supported image updated to 2.7 — reference without :latest
    ee_images:
      - name: Default execution environment
        image: registry.redhat.io/ansible-automation-platform/ee-supported-rhel9:2.7.0

  hub:
    replicas: 1

  eda:
    replicas: 2

# Apply the updated CR
oc apply -f aap-platform-2.7.yaml -n ansible-automation-platform

# Watch the upgrade progress
oc get pods -n ansible-automation-platform -w

# Verify operator version
oc get csv -n ansible-automation-platform | grep ansible-automation-platform-operator

Migrating from RPM to Containerized (AAP 2.6 prerequisite step)

If you are still on an RPM-based AAP 2.6 install, you must migrate to containerized before upgrading to 2.7. The migration guide is documented in the AAP 2.6 RPM to Containerized Migration Guide.

High-level steps:

1. Back up the AAP database on the RPM install
2. Install a new RHEL 9 host for the containerized installer
3. Restore the database into the new containerized deployment
4. Validate functionality
5. Decommission the RPM-based hosts
6. Proceed with the 2.6 → 2.7 upgrade on the containerized install

Execution Environment Changes in 2.7

ee-minimal

• ansible-lint removed — migrate to the Ansible Development Tools (ADT) container
• :latest tag removed — pin to ee-minimal-rhel9:2.7.0 (or a specific patch tag)

ee-supported

• ansible-lint removed — same as ee-minimal
• microsoft.mecm and microsoft.hyperv collections added
• Removed collections:
• cloud.common
• cloud.terraform
• redhat.csp_download
• redhat.rhv
• trendmicro.deepsec
• junipernetworks.junos → use juniper.device instead

# execution-environment.yml — migrated for AAP 2.7
version: 3
build_arg_defaults:
  EE_BASE_IMAGE: registry.redhat.io/ansible-automation-platform/ee-supported-rhel9:2.7.0

dependencies:
  galaxy:
    collections:
      # junos users: migrate to juniper.device
      - name: juniper.device
        version: ">=3.0.0"
      # cloud.terraform users: install explicitly if still needed
      - name: cloud.terraform
        source: https://cloud.redhat.com/api/automation-hub/
        version: ">=2.0.0"

See also: Deploy and Configure the MCP Server for Ansible Automation Platform: Complete Guide (Containerized and OpenShift)

Post-Upgrade Validation

# Verify all AAP services are running
ansible-automation-platform-service-node --status

# Confirm gateway is the single external endpoint
curl -sk https://aap.corp.example.com/api/controller/v2/ping/ | python3 -m json.tool

# Verify direct component routes return 404 (expected after upgrade)
curl -sk https://controller.corp.example.com/api/v2/ping/ && echo "WARNING: direct route still active"

# Run the direct-access detector — should return no findings post-upgrade
aap-detect-direct-component-access --report-format table

FAQ

I'm on AAP 2.4 with the RPM installer. What's my full path to 2.7?

Your path: RPM 2.4 → RPM 2.6 → Containerized 2.6 (method migration) → Containerized 2.7.

That's three operations. Red Hat recommends planning a maintenance window for each.

Can I skip 2.6 if I'm on 2.5?

No. AAP 2.7 only upgrades from 2.6. Skip attempts are blocked by the installer.

Does ADT still work as RPM packages?

Yes. Ansible Development Tools (ansible-navigator, ansible-builder, ansible-lint, VS Code extension) continue to be packaged as RPMs for RHEL. Only the AAP platform components (controller, Hub, EDA) moved away from RPM.

What happens to my custom EEs after the upgrade?

Custom EEs you built on top of ee-minimal or ee-supported continue to work if they don't depend on the removed collections. Rebuild them with the 2.7 base images to pick up security updates. If they reference junipernetworks.junos, rebuild with juniper.device instead.

Is the upgrade reversible?

The upgrade is not reversible without restoring from a backup. Take a full database backup and snapshot the hosting VMs before upgrading.

Related Articles

• Install Containerized Ansible Automation Platform 2.7
• AAP 2.6 RPM to Containerized Migration Guide
• AAP 2.7: Removing Direct API Access — Migration Guide
• Red Hat Ansible Automation Platform 2.7: What's New