From Tower to AAP, counted once.

Ansible Tower, in its 3.x lineage, was the commercial product Red Hat shipped as the web interface, the role based access control plane, and the job scheduler for upstream Ansible. Tower was metered, in commercial circulation through 2020, in two main shapes: a node based agreement against managed hosts and, in some legacy estates, a per seat agreement against named operators. Both shapes carried support and certified content as part of the subscription.1 The product worked. The agreement worked. The complication arrived when Red Hat consolidated the wider Ansible commercial line into the Ansible Automation Platform.

Ansible Automation Platform, in its 1.x line, bundled Tower with the Red Hat Insights service, with certified content collections, and with an explicit managed node entitlement model. The 2.x line, which is the platform shape in commercial circulation in 2026, refactored the runtime: Tower became the automation controller, the runtime detached into execution environments, and the optional private automation hub joined as a registry for collections and images. The meter remained the managed node. For the meter itself, see the managed node counting article.

The buyer side reading at renewal in 2026 turns on whether the existing agreement is a Tower era paper that still describes a Tower era shape, or a platform era paper that describes the managed node. Where the paper still reads Tower, the renewal is the moment to bring the language onto the platform shape, not the moment to renew a shape that no longer matches the product.

Three things changed at the architectural layer in the Tower to platform transition. First, the controller stopped being the default in process executor in modern deployments; jobs dispatch to execution nodes that pull execution environment images. Second, certified content moved out of generic bundling and into formally curated collections, with the private automation hub as the optional internal registry. Third, the Red Hat Insights surface integrated with platform telemetry rather than living adjacent to it. None of these architectural changes by itself moved the meter. The meter remained the managed node.

Three things changed at the commercial layer. First, the Tower era node tier translated to the platform managed node tier with a defined mapping that, in most estates, was a one for one carry forward at the existing entitlement count. Second, the per seat agreements in scope at the time were converted to node based agreements at the next renewal in most estates the practice has reviewed. Third, the support tier nomenclature aligned to the standard Red Hat tiering rather than the legacy Tower specific tiers.2

The commercial result is that a buyer holding a 2019 era Tower agreement should expect the 2026 renewal to read in platform terms: managed nodes, optional Lightspeed seats, standard or premium support, and the Ansible Automation Platform tier name on the order line. A renewal that still surfaces Tower era line items, that mixes node count and seat count, or that prices an optional product like Lightspeed as if it were a platform increment, has not finished the transition on paper even if it finished it in practice.

The first renewal trap in the Tower to platform transition is the double count. A proposal surfaces both a Tower era line and a platform era line, often because the seller side internal record migration was incomplete. The buyer that signs both pays twice for one entitlement. The buyer side discipline is to reconcile the proposed lines against the buyer's actual entitlement record and to insist on a single platform line that covers the deployment.

The second trap is the seat to node inflation. A proposal converts a legacy per seat agreement into a managed node tier at a count that does not match the deployment. The seller side typically sizes the conversion against the broader operations roster rather than the actual inventoried managed nodes. The buyer side reading sources the node count from a reconciled inventory ledger, not from the operations directory. For the reconciliation engagement, see subscription assessment.

The third trap is the transition era discount sunset. The 2019 to 2021 Tower to platform migrations carried, in some estates, a transition discount on the platform line that was structured as a multi year ramp into list. The 2026 renewal in many of those estates is the first renewal after the ramp completes. The proposal lands at list, the buyer reads the proposal as standard, and the increase from the prior year is absorbed without negotiation. The defensible reading is to negotiate at the post transition concession band rather than against the prior year's transitional rate.3

The timing of the transition on paper matters as much as the timing of the transition in the runtime. A buyer that completed the platform 2.x technical migration in 2022 but never bedded the change into the order form is a buyer that holds a 2026 renewal proposal with five years of accumulated mismatch to unwind. The unwind is not adversarial. It is a paperwork exercise that the seller side typically supports, because aligning the paper to the platform shape clears the way for clean multi year structuring on either side.

The unwind reads as a three step exercise. First, take the current platform deployment as the ground truth: count the controllers, count the execution nodes, count the inventoried managed nodes, and count any Lightspeed seats. Second, lay the existing entitlement against that deployment, line by line, and identify the lines that no longer describe a thing in the deployment. Third, propose a clean renewal that replaces the legacy lines with platform lines at the deployment shape.4 The seller side rarely refuses this exercise. The buyer side rarely runs it without prompting.

For the broader pre renewal posture work, see the ninety day subscription assessment; for the underlying counting work, see the managed node counting article.

The buyer side reading of a Tower to platform transition renewal in 2026 proceeds in four steps. First, audit the existing order form for any line that reads in Tower era terms and flag each. Second, lay the existing entitlement against the current platform deployment and identify the legacy lines that no longer describe a thing. Third, source the proposed renewal lines from the platform shape: managed nodes, optional Lightspeed seats, support tier. Fourth, sign the platform tier at the managed node count and treat any topology or seat line as separately governed.5

Across recent practice engagements, the recoverable correction on transition era renewals has typically come from one of three places: removing a duplicate legacy line, resizing a per seat conversion at a defensible node count, or renegotiating the post transition base rate rather than accepting the post ramp list rate. Where all three apply, the correction has run to the high teens or beyond as a percent of the renewal proposal in line. Where none applies, the correction is smaller and the conversation moves to multi year structuring.

The corollary on the audit side is that a Red Hat compliance inquiry that cites the Tower to platform mapping as the basis for the finding is reading the paperwork rather than the deployment. The defensible reading reconciles to the deployment shape. For the audit engagement, see audit defense; for the renewal engagement, see renewal negotiation; for direct contact, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.