Ansible Automation Platform 2.7 upgrades start with architecture, not installers

Red Hat is telling Ansible Automation Platform teams to settle six architectural questions before treating a 2.7 upgrade as an installation exercise. Its September 22 guidance says the work can range from an afternoon task to a multi-week platform migration, with RPM-based 2.4 and 2.5 environments needing particular scrutiny.

What the framework changes

The first decision is the deployment model: self-managed on Red Hat Enterprise Linux virtual machines, operator-managed on OpenShift or Kubernetes, or a managed service on Microsoft Azure or Amazon Web Services. Red Hat says execution environments allow development and production to use different platform models while keeping automation content portable.

That choice feeds the next two decisions. Teams must decide whether they need one multi-tenant production platform or distributed environments, and how non-production testing fits into the software-development lifecycle. They must then define high availability and disaster recovery in terms of failover, upgrade strategy and recovery objectives rather than assuming the automation platform is still a non-critical utility.

The result is less a migration checklist than a platform-design review. Moving to the operator does not by itself answer where state lives, how many environments the organization can operate, or what recovery promise the automation service must meet.

Secrets and access are part of the topology

Red Hat’s fourth and fifth decisions cover secrets and user access. The guidance asks teams to choose between native Ansible encryption and an external provider, and to evaluate that choice across development, production and recovery—not only at runtime. It specifically points to HashiCorp Vault integration through OpenID Connect in 2.7.

Access design is similarly upstream of implementation. A team that exposes direct platform access has a different control boundary from one that routes requests through tickets or a self-service portal. The source frames that boundary as a balance between governance and developer velocity.

Job launch is the maturity test

The sixth decision is how jobs begin. Red Hat describes a progression from manual launches, through ticket-driven self-service and event-driven automation, to AI-augmented execution. Ansible Automation Platform 2.7’s Model Context Protocol server and automation orchestrator let agents discover and invoke automation, but that capability raises the stakes of the earlier access, secrets and resilience choices.

Platform teams should therefore document the desired launch modes before migration, map each mode to an identity and approval path, and test recovery for the dependencies that make those paths work. The practical takeaway is straightforward: choose the operating model first, then make the 2.7 upgrade implement it.