Migrate from Ansible Automation Platform to AWX: what the move involves
Most teams start this move after a subscription renewal, a licensing change or a data residency requirement that makes running AAP in a particular place difficult. The good news is that AWX is the upstream of automation controller, so most of the objects you manage in controller (job templates, inventories, credentials and schedules) have a direct counterpart in AWX. What does not carry over is the support contract, the certified content collections and the private automation hub, which are the parts Red Hat adds on top of the community project. Plan the migration around those gaps, not around the object export. The work usually belongs to a platform engineering team, often with an implementation partner who handles the install and the object migration. Expect the effort to be concentrated in three places: standing up AWX on Kubernetes with the AWX Operator, rebuilding the content sources that came from certified collections and automation hub, and re-validating every job template against the collection versions you actually run. Ask any partner to state in writing which objects they will export, which they will recreate by hand and how they will verify parity before cutover. The main planning risk is that AWX releases are paused while the project is refactored. The most recent release listed on the project's releases page is 24.6.1, from July 2, 2024, and Red Hat does not provide paid support for AWX. Before committing, decide who will patch the Operator, the AWX images and the Kubernetes layer, who owns security fixes and what your fallback is if upstream stays quiet. Confirm the current release status in the AWX releases page on the day you make the decision.
Which AAP capabilities map to AWX, and which need rework
This table maps the main automation controller and Ansible Automation Platform capabilities to their AWX equivalents and marks each as clean, needs rework or gap. Treat the labels as a starting point, since AWX's feature set changes and its releases are paused, so confirm each item against the AWX version you plan to deploy in the AWX repository before scheduling cutover.
| Capability | AWX position | Migration status |
|---|---|---|
| Job templates | Present in AWX as the same core object, so definitions can be exported and recreated through the awx CLI or API | Clean, verify extra vars and execution settings after import |
| Inventories and inventory sources | Static and dynamic inventories exist, but source credentials and sync schedules must be re-attached manually | Needs rework |
| Credentials and credential types | Custom credential types are supported, but secret values are not exported and must be re-entered in the target instance | Needs rework |
| Schedules | Schedules attach to job templates and workflows, but times and time zones should be checked after re-creation | Needs rework |
| RBAC and teams | Organizations, teams and roles exist, but role mappings from AAP directories must be rebuilt and tested | Needs rework |
| Workflow job templates | Workflows are available, but node approvals and convergence settings should be compared against your AAP definitions | Needs rework |
| Surveys | Survey specs can be exported and re-imported, so confirm field types and defaults behave the same way | Clean, verify after import |
| Event-Driven Ansible | Not part of AWX. Event rulebooks and event sources have no direct equivalent and need a separate design | Gap |
| Private automation hub and certified collections | AWX pulls collections from public sources. Red Hat's FAQ describes AWX as the upstream of AAP, with Red Hat not providing paid support for it | Gap, plan your own collection source |
| Red Hat enterprise support | Community support only. Red Hat's FAQ states it does not provide paid support for AWX | Gap, replace with internal or contracted support |
Which objects export and re-import with the awx CLI
The awx CLI talks to the AWX HTTP API, so it can drive most of the rebuild, but it does not carry every object across unchanged. Each card below covers one class of object, what you rebuild by hand or through the API, and what to verify before cutover.
The awx CLI and its scope
The awx CLI is the official command-line client for AWX. It is installed from PyPI as awxkit and works through the AWX HTTP API to configure and launch jobs, check job status, and manage organizations, users and teams. Treat it as the scripted rebuild path, not as a full backup tool. Confirm the exact subcommands and output format against the AWX version you deploy, since the install guide documents the capability rather than a complete export workflow. Run it against a non-production AWX first.
Inventories, projects and job templates
Inventories, projects and job templates are recreated through the AWX API, typically from a script that reads your inventory of AAP objects and posts equivalent objects to AWX. Keep a written map from each source object ID to its AWX counterpart so that schedules and workflow nodes can reference the new IDs. Check that project SCM URLs, branches and inventory sources resolve from the new cluster's network, because a rebuilt job template that points at an unreachable repository fails only at its first run.
Credentials need secrets re-entered
Credentials should be recreated, not copied. AAP does not hand back secret values in a form you should move as plaintext, and the migration should not create a plaintext export of SSH keys, vault passwords or cloud tokens. Each credential type is recreated in AWX, and the secret is re-entered from your existing secrets manager or key custody process. Record which owner rotates each secret after cutover, since reusing old values across two live platforms widens the blast radius.
Schedules, notifications and workflows
Schedules attach to job templates and workflow templates, so they should be recreated after the templates they call exist and their IDs are known. Notification targets, such as email, chat or webhook destinations, are configured separately and need the endpoints, tokens and recipient lists confirmed by their owners. Workflow graphs are a common source of error when rebuilt by hand, so compare node counts and failure paths between the two platforms during a parallel run.
Hub collections, LDAP and SSO
Integrations sit outside the object model and need separate work. Collections sourced from private automation hub must be replaced, as covered in the collections section of this guide, and their requirements files updated. LDAP directory bindings, SSO providers, RBAC team mappings and external log or secrets backends are configured in AWX settings and must be reconfigured and tested with real test accounts. Ask your identity team to confirm group names and attribute mappings before you assume they carried over.
Verify with job output, not object counts
A matching count of job templates proves little on its own. Run representative jobs from each template in AWX and compare changed tasks, host coverage and check-mode results with the output from AAP. Store the comparison as migration evidence, since it shows what changed in behavior rather than in object totals. Plan to keep AAP read-only for an agreed period so you can re-run any job whose output differs.
Migration sequence from inventory to decommission
The sequence moves job templates, inventories, credentials and schedules from automation controller to AWX in a controlled order, so each phase ends with a verified object register, a tested pilot and a parity checklist before AAP is switched off. Teams that skip the inventory and parity steps usually find missing credentials or silent schedule gaps after cutover.
Build the object register from AAP
Export a complete list of organizations, inventories, projects, credentials, job templates, workflow templates, schedules, RBAC assignments and the collections each project depends on. Record the owner, the target hosts and whether each job template is still in use. The register is the working document for every later phase, and it is done when the platform team and the owning application teams have signed off on it. Credential secret values are not exported, so note which secrets must be re-entered by hand.
Classify collections and content dependencies
Compare every collection and execution environment dependency against what the AAP private automation hub and certified content provide. Certified collections from Red Hat may not be available from the community sources AWX uses, so each one needs a replacement, a community equivalent or a mirrored copy under your control. Confirm the exact collection versions with the owning teams and record the decision for each. The output is a dependency table that shows which playbooks run unchanged and which need rework.
Stand up a pilot AWX on a test cluster
Install AWX with the AWX Operator on a non-production Kubernetes cluster, following the install guide. The Operator has been the preferred install method since version 18.0, while running AWX in Docker is recommended only for development and test work and has no official release, so avoid it for the pilot if the pilot is meant to predict production. Connect the pilot to a test inventory, create one project and run a simple job to confirm the task engine works. The output is a working pilot instance with a documented install and a short list of platform choices, such as storage class and ingress, that production will need to match.
Export and re-import objects with the awx CLI
Use the awx command-line client, installed from PyPI as awxkit, to recreate organizations, teams, inventories, projects, credentials and job templates in the pilot through the AWX HTTP API. Script the creation from the register so the process can be repeated, and reapply secret values from your vault rather than from AAP exports. Confirm that each job template launches, reads its inventory and reports status correctly. The output is a re-imported pilot whose object counts match the register, with a list of anything that failed and why.
Run AWX in parallel against non-production hosts
Point the re-created job templates at non-production hosts while AAP keeps running the production schedules. Compare job output, changed-task counts, failure handling and host limits between the two platforms for the same playbook and inputs. Check RBAC, survey prompts and notification settings, because these often differ after an import. The output is a parity checklist that marks each job template as matching, matching with a known difference, or blocked, and a named owner for every open item.
Cut over schedules and production job templates
Move production schedules and job templates to AWX in small groups, starting with the lowest-impact automation and keeping AAP schedules disabled rather than deleted for each group once it is confirmed. Verify that each scheduled run completes, that notifications reach the right teams and that credentials reach only the intended hosts. Keep a documented rollback path, which is to re-enable the AAP schedule for the affected group. The output is a cutover log that records each group, the time it moved, the first successful run and any rollback.
Decommission AAP after a confirmed run period
Once every group has run cleanly on AWX through a period you have agreed with the owners, export a final AAP backup for your records, revoke AAP credentials, remove its access to managed hosts and retire the subscription according to your contract terms. Confirm the terms and retention rules with your legal and compliance teams before deleting anything. Record in the runbook who now supports AWX, because Red Hat does not provide paid support for it. The output is a decommission record, an archived AAP backup and an updated support ownership document.
What drives migration cost and duration
This table lists the factors that change how much work a move from automation controller to AWX involves, why each one matters, and how to keep it manageable. Use it to shape a written scope before asking for a quote, since the largest effort usually sits in the objects you must recreate and the content you must replace.
| Driver | Why it changes effort | How to reduce it |
|---|---|---|
| Number of job templates and workflows | Each template, survey and workflow must be recreated or rebuilt in AWX, and the count sets the size of the test matrix. | Retire unused templates before export, group similar ones, and confirm which workflows are actually scheduled. |
| Inventories and dynamic inventory sources | Dynamic sources, host variables and group variables often depend on credentials and plugins that need re-validation in AWX. | Document each source, test sync on a copy, and replace hand-edited static inventories with source-controlled ones. |
| Certified or hub-sourced collections | Content pulled from automation hub or certified sources must be replaced with community or self-maintained equivalents, and playbooks may need changes where module names or behavior differ. | List every collection and module used, map each to a community source or internal copy, and pin versions in requirements files. |
| Credential types and secret handling | Custom credential types, vault passwords and cloud keys must be recreated and tested, and secret values may need a new store. | Inventory credential types, remove unused ones, and decide early where secrets will live before recreating them. |
| RBAC and organization structure | Teams, roles and object-level permissions rarely map one to one, so access design becomes a decision rather than a copy step. | Simplify roles before the move, and write down which team owns which template, inventory and credential. |
| Event-Driven Ansible use | Rulebooks and event sources do not move to AWX as part of the controller export, so any event-driven flow needs its own design and testing. | Count active rulebooks and decide whether each one is kept, rebuilt on another engine or retired. |
| Private automation hub dependency | Playbooks and execution environments that pull from a private hub must be pointed at a new registry or Galaxy source. | Mirror required content to an internal location and update execution environment definitions in one pass. |
| Kubernetes platform readiness | AWX runs through the AWX Operator, so the cluster, storage class, ingress, backups and upgrade process must exist before data is imported. | Confirm the target cluster, storage and backup approach in writing, and test a clean install before migrating objects. |
| In-house Ansible and Kubernetes skills | Gaps in either area shift time into learning and troubleshooting, and no paid vendor support is available for AWX itself. | Name owners for the operator, the playbooks and on-call response, and ask any implementation partner to document its handover. |
| Parallel running and cutover | Running both platforms during cutover doubles the schedule checks and requires agreed rules for which system triggers each job. | Freeze changes to schedules during the window and agree a single owner for the switch-over decision. |
What usually goes wrong and how to prevent it
Most failed AWX migrations come from decisions made before the first job template is recreated: which release to run, who supports it, and how credentials and schedules cross over. The cards below cover the risks that recur on this path and the checks that prevent them.
Building on a paused release
AWX has published no release since 24.6.1, released on July 2, 2024, while the project is paused for a large scale refactoring. Pinning production to that version means accepting a fixed codebase with no upstream fixes in the release stream. Before cutover, confirm the version you will run, check the releases page for any newer tag, and write down who applies security patches and how often.
Assuming Red Hat support continues
Red Hat states that it hardens selected AWX releases for Ansible Automation Platform, that AWX is community supported, and that Red Hat provides no paid support for it. Teams that move off AAP often keep the same escalation path in their runbooks by habit. Replace that path with a named internal owner, a community escalation route you have tested, and a written statement of what your organization now supports itself.
Losing collection versions with automation hub
Private automation hub typically serves certified and validated collections that job templates depend on. When the hub is removed, playbooks can silently pull whatever version Galaxy or a Git source provides on the next run. Pin each collection to an exact version in a requirements file, mirror the artifacts you use into your own storage, and diff the installed versions on the controller before and after cutover.
Credentials not re-entered correctly
Automation controller stores machine, cloud and vault credentials as encrypted objects, and the awx CLI exports their definitions without the secret values. Jobs that reference a credential with a blank or wrong secret fail late, often in the middle of a production change. Re-enter every secret from your vault, then run a read-only test job per credential against a non-production inventory before any scheduled job points at it.
Schedules firing twice during parallel run
Running AAP and AWX in parallel is useful for cutover, but a schedule copied to both systems will launch the same playbook twice against the same hosts. This is most dangerous for jobs that restart services, rotate keys or change network devices. Keep each schedule enabled in one system only, disable it in the source before enabling it in AWX, and record the switch date in your change log.
Installing outside the operator path
The AWX install guide recommends the AWX Operator since version 18.0 and describes Docker installs as suitable only for development and test, with no official published release. A hand-built container host is harder to upgrade, back up and restore than an operator-managed deployment on Kubernetes. Choose the operator install from the start, document the cluster, storage class and database that back it, and test a restore before you rely on the instance.
How the migration differs by starting point
A small team with a handful of job templates can usually treat the move as a short, object-by-object rebuild. The main question is whether AWX will run the playbooks as they are, which is a matter of testing rather than redesign. Because the object count is low, the export and re-import work is modest, and most of the effort goes into verifying credentials and schedules after install.
- Inventory first: List every job template, inventory, credential and schedule in automation controller so nothing is missed during recreation.
- Test on one template: Run a representative playbook in a fresh AWX instance before moving the rest, which surfaces collection or Python dependency gaps early.
- Credentials by hand: For a small estate, re-entering credentials manually is often simpler than scripting an export, but secret values must come from your vault, not the old controller.
- Schedules last: Recreate schedules only after the job templates they call are proven, so a bad run does not fire on a live system.
- Keep the old controller read-only: Retain the source instance until every template has a successful run in AWX.
Before you start, confirm with your own team how many objects exist and whether any of them rely on AAP-only features such as surveys or RBAC roles that need redesign.
A large estate with many projects and collections depends heavily on automation hub content, and that is where the sequence changes most. Certified and validated collections from Red Hat's hub do not come with AWX, so each collection the playbooks use must be sourced, pinned and tested before any job template can move. Effort scales with the number of distinct collections and their version pins rather than with the number of templates alone.
- Collection inventory: Map every collection and version each project requires, and note which ones came from certified or private hub content.
- Source replacements: Decide which community or upstream sources will replace certified content, and confirm each one is licensed for your use.
- Version pinning: Pin collection versions in a requirements file so AWX runs match the behavior you tested.
- Batch by project: Move projects in groups that share collections, so a shared dependency is validated once.
- Automate the export: For hundreds of objects, scripting the export and import with the awx CLI is worth the setup time.
Ask your platform team to quantify how many collections are certified, how many are private to your hub, and how many projects depend on each.
In air-gapped or regulated environments, the install and the content supply chain become the critical path. AWX pulls container images, Python packages and collections from external sources by default, so an offline mirror must exist before the operator is deployed. The move also has to satisfy change control and evidence requirements, which adds review steps that a connected team can skip.
- Offline mirrors first: Build internal mirrors for container images, Python packages and collections before any AWX install, and document each source and checksum.
- Operator install from mirror: Follow the AWX Operator install path with image references pointed at your registry, and confirm each reference in the deployment manifests.
- Change records: Record each imported object and its approver, since regulators and auditors will ask how credentials and templates were approved.
- Secrets handling: Keep credential material in your approved secrets store and confirm how AWX retrieves it in your environment.
- Support boundary: Note that Red Hat provides no paid support for AWX, so your internal team owns patching and incident response.
Confirm with your security and compliance leads which change-management and evidence standards apply, because these set the sequence more than the tooling does.
Teams that use Event-Driven Ansible have a component that AWX does not replace as a supported product. Event-driven rulebooks trigger job templates from external events, so the move must account for the event sources, rule logic and the job templates they launch. Event-Driven Ansible is part of Red Hat's integrated tooling in Ansible Automation Platform, so its open-source counterpart and its operating model need separate evaluation before cutover.
- Rulebook inventory: List every rulebook, its event source and the job templates it launches, since each link must be rebuilt or rerouted.
- Decide the trigger path: Choose whether events call AWX through its REST API or whether a separate event engine stays in place, and test that path end to end.
- Duplicate-run checks: During parallel running, confirm that events do not launch the same action in both systems.
- Ownership of the event layer: Assign an owner for event-driven automation, because it sits outside AWX's support model.
- Test with replayed events: Replay recorded events in a test environment to confirm the outcomes match the old system.
Ask your team whether the event layer is in active production use, since an unused rulebook changes the plan far less than a live one.
Questions buyers ask before moving from AAP to AWX
What does a move from Ansible Automation Platform to AWX cost?
The cost is mostly labor and hosting, because AWX itself is free under the Apache 2.0 license. The one-time work covers exporting job templates, inventories, credentials and schedules, rebuilding them in AWX, reworking content that depended on certified collections, and testing. The recurring costs are the Kubernetes cluster that runs AWX through the AWX Operator, storage, backups, monitoring, and the internal or external people who patch and upgrade it. Your AAP subscription and its support level are the costs you give up, so compare them with your own staffing. Ask any implementation partner for a fixed-scope quote that lists the objects in scope, the collections to replace, and who maintains the platform after handover.
How long does an AWX migration take?
Duration depends on what you have to move, not on a fixed number. The main drivers are how many job templates, inventories, credentials and schedules exist, how many of them depend on Red Hat certified collections or private automation hub content, how much RBAC and survey logic must be redesigned, and how many environments need parallel runs before cutover. The AWX Operator install and cluster readiness also add time if your Kubernetes platform is not already in place. Ask for a scope inventory first, because an accurate count of objects is what turns an estimate into a plan. Your vendor or internal team should state the timeline in the written scope, with the phases and acceptance tests.
Can our team migrate from AAP to AWX without outside help?
Yes, many teams can, provided they have Kubernetes operations skills and an engineer who knows the existing automation well. The AWX install guide makes the AWX Operator the preferred installation method since version 18.0, so the platform team needs to be comfortable with Kubernetes deployments, persistent storage, ingress and secrets. The awx command-line client, which is installed from PyPI as awxkit, can export and re-import many objects through the AWX HTTP API, but you will still review each object by hand and rebuild what the CLI cannot carry across. Decide who owns the platform after cutover, because AWX has no paid support from Red Hat. An outside partner can take the work on under a fixed-scope agreement, which DeployOpen offers for planning, implementation, hardening, backup and documentation.
What does the work require from our own staff?
The work needs named owners for four areas. Automation owners must confirm which job templates are live, which are retired, and which depend on credentials or surveys. Platform engineers must provide the Kubernetes cluster, storage, DNS, certificates and network paths to inventories. Security owners must approve how credentials are stored and who can run which templates. Operations owners must agree on backups, upgrades, monitoring and a cutover window with rollback steps. Expect the automation owners to spend the most time, since they validate that each migrated job produces the same result. Before work starts, write down these owners and their hours, so the schedule does not depend on people who have other priorities.
Does AWX have vendor support?
AWX has community support only. Red Hat's FAQ states that it takes selected AWX releases and hardens them for long-term supportability as part of Ansible Automation Platform, that AWX is supported by the community, and that Red Hat does not provide any paid support for it. Support for AWX therefore comes from your own team, the upstream community, or a third party you contract for it. For regulated environments, decide before migrating who will handle security patches, failed upgrades and incidents, and how those responsibilities appear in your change process and risk register. Confirm any third-party support terms in writing before you rely on them.
Are AWX releases paused, and what does that mean for us?
The AWX GitHub repository states that releases of the project are paused during a large scale refactoring. The most recent release listed on the releases page is AWX 24.6.1, released on July 2, 2024. This means you should not assume new fixes, feature work or security updates will arrive on a predictable schedule. Before choosing AWX, review the open issues and commit activity in the repository, test the version you plan to deploy against your own job workloads, and decide how you will handle security advisories. Plan an exit path as well, such as keeping exported job definitions in version control, so a later move to another platform does not repeat the whole inventory exercise. Our companion page on paused AWX releases weighs these options in more detail.
Can we keep our certified collections and automation hub content in AWX?
Not as Red Hat certified content, because certified collections and private automation hub are part of the Ansible Automation Platform subscription. Red Hat's product comparison states that AAP adds certified content collections and a private automation hub on top of the community projects. In AWX you can install collections from Ansible Galaxy or from your own Git repositories and private content sources, but you must verify their origin, version pinning and vulnerability status yourself. Make an inventory of every collection your playbooks call, record the version and source of each, and replace or re-validate them before cutover. Confirm with your security and compliance owners which content sources they accept, because that decision will shape the supply chain controls you document.
Which AAP features will we lose or have to rebuild in AWX?
The core job engine, inventories, job templates, credentials and schedules map closely to AWX, since AWX is the upstream of automation controller, formerly Ansible Tower. Features that sit in the Ansible Automation Platform layer need separate planning. These include certified collections, the private automation hub, Event-Driven Ansible and any support entitlements. Review your workflows, surveys, RBAC mappings and notifications one by one, because AWX configuration may differ in small but important ways. Keep in mind that the Red Hat FAQ describes AAP as hardened releases of AWX with added tooling, so a feature present in AAP may need a community alternative or a custom build. Confirm each gap with a written list before you choose a target.
How DeployOpen scopes and runs the AWX migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, and an AWX migration follows the same pattern. DeployOpen is a Chainscore Labs company. Work is delivered in your cloud accounts, data centers or air-gapped networks, so the AWX Operator deployment, its database, credential storage and the execution environments stay under your control. DeployOpen does not hold partner status with Red Hat or any vendor, and it does not issue audit reports or certifications. Compliance evidence it prepares is assessed by your own auditors.
Most engagements are fixed-scope. Before any work starts, the written scope should name the inventory of job templates, inventories, credentials and schedules to move, the decisions on RBAC and surveys, the collection and automation hub replacements, the cutover window and the acceptance tests for each deliverable. A quote follows from that scope, so the more precisely you list the AAP objects and the collections they call, the more reliable the quote. Ask the vendor for a written statement of what each deliverable includes and what remains with your team. Ongoing support, upgrades and continuous testing are available as retainers, which matters here because AWX has no published release since 24.6.1 and you will need someone to track upstream changes and apply them.
Before requesting a quote, confirm three things in your own environment: which AAP support tier you currently hold and whether you need its documented exports from the controller, which secrets must be re-entered rather than exported, and whether any content depends on certified collections you will replace from public sources. Those answers determine the effort, and they should appear in the scope document as named assumptions. Any timeline in the scope should be stated as agreed dates, not estimates taken from this page.
