Case study
Enterprise Ansible Automation Platform Modernization
Taking a multi-environment automation platform from AAP 2.4 to 2.6, including an OS migration from RHEL 8 to RHEL 9, with no business interruption.
- Result
- AAP 2.4 → 2.6 and RHEL 8 → 9 across multiple AWS accounts with no business interruption
- Role
- Led end-to-end
- Where
- Capital One · 2025 – Present
- Key stack
- Ansible Automation Platform 2.4 / 2.6 · AAP Gateway · AAP Controller · PostgreSQL
Sanitized case study based on professional experience. Internal names, accounts, hostnames and configurations are intentionally omitted.
01Problem
The enterprise automation platform had to move to a supported release, AAP 2.6, with a new gateway-centric topology. It spans Development, Production and Restricted Production across multiple AWS accounts, and application teams depend on it every day, so an extended outage or a broken authentication mapping was not acceptable.
02Context
The platform had already been through a 2.3 → 2.4 upgrade. Version 2.6 changes how authentication and routing reach the controllers through the platform gateway, and the underlying hosts first had to move from RHEL 8 to RHEL 9. The environments are private, with no direct internet access, so every image and package has to come from internal registries.
03Architecture
How it works
- Engineers authenticate through SAML single sign-on. Identity-provider groups map to AAP teams and organizations, so access is managed centrally instead of per user.
- The AAP Gateway is the single entry point and routes to multiple controller nodes for availability.
- Controllers share state through an external PostgreSQL database, which keeps the data tier separate from the application tier and makes upgrades and recovery more predictable.
- Jobs run inside custom execution environments pulled from JFrog Artifactory, because the environments have no direct internet access.
- The same topology is repeated for Development, Production and Restricted Production.
04Engineering approach
- Validated the target architecture: gateway and controller topology, external database connectivity, and how 2.6 changes authentication flow.
- Migrated the host OS from RHEL 8 to RHEL 9 first, so the platform upgrade ran on a supported, known-good base.
- Rehearsed the upgrade in Development, then promoted the same procedure to Production and Restricted Production.
- Integrated the external PostgreSQL tier and confirmed data migration and controller connectivity before cutover.
- Rebuilt SAML team and organization mappings for the gateway model and verified access for representative teams.
- Planned the production cutover with a defined sequence, validation checks and a rollback path. Issues found in lower environments were resolved before promotion.
05Security
- Centralized authentication through SAML SSO, with access driven by group-to-team mapping.
- Environment separation, with a Restricted Production tier held to tighter controls.
- No direct internet access: images and collections come only from the internal artifact registry.
- Moving to RHEL 9 and a supported AAP release reduces exposure to unsupported components.
06Automation
- Repeatable upgrade runbook applied identically across environments.
- Versioned execution environments, so job runtimes are consistent before and after the upgrade.
- Post-upgrade validation of job templates, credentials and inventories.
07Results
- Completed the AAP 2.4 → 2.6 upgrade across multiple AWS accounts with no business interruption.
- Completed the RHEL 8 → RHEL 9 migration of the platform hosts.
- Integrated external PostgreSQL and restored SAML mappings, and completed production cutover.
- This continues the platform’s 2.3 → 2.4 → 2.6 modernization path.
08Lessons learned
- Separate OS upgrades from platform upgrades, so that one change at a time is under test.
- Authentication mapping is the riskiest part of a gateway migration and needs its own validation pass with real teams.
- Rehearsing in lower environments with the exact production procedure finds issues cheaply.