Red Hat Ansible Automation Platform 2: Migration strategy considerations

October 12, 2021 by Craig Brandt

Red Hat Ansible Automation Platform 2 introduces an updated architecture, new tools and an improved but familiar experience to automation teams. However, there are multiple considerations for your planning and strategy to migrate your current deployment to Ansible Automation Platform 2.

This document provides guidance to all of the stakeholders responsible for planning and executing an Ansible Automation Platform migration guidance with factors to address in your migration strategy.

This document does not provide a one-size-fits-all approach for migration. Various factors unique to your organization will impact the effort required, stakeholders involved and delivery plan.

What to consider before migrating

We understand that many factors specific to your needs affect your migration assessment and planning. This section highlights critical factors to determine your migration readiness and what approach will best suit your organization.

Assess your current environment

There will be configurations unique to your environment, and it’s crucial to perform a thorough technical assessment. We recommend including the following:

  • Analyze your current Ansible Automation Platform installation, including current deployment patterns, integrations and any complexities relevant to the migration.

  • Determine changes needed in your environment to meet the Ansible Automation Platform 2 technical requirements.

  • Assess stakeholders’ readiness to plan and execute the migration.

  • Check for compliance, security policy enforcement and auditing.

If you would like to dig into this deeper, you can check out some further reading:

Ansible Automation Platform installation guide
Ansible Automation upgrade and migration guide
Migration Technical Considerations Checklist

What if I can’t do a complete migration right now?

There may be scenarios where a complete migration isn’t currently feasible. Ansible Automation Platform 2 can be adopted in a phased approach. The method allows teams to become familiar with the new tools and reduce the number of tasks needed at migration time.

We recommend assessing the below tasks and, if it is feasible, implement them in preparation for the complete Ansible Automation Platform 2 deployment.

       Lower Risk Activities

    Medium Risk Activities

            Higher Risk Activities

  • Develop and test playbooks with the 2.9-based execution environment.

  • Create custom automation execution environments from current Python virtual environments.

  • Leverage ansible-navigator and ansible-builder in workflows.

  • Integrate Red Hat Insights for Ansible to identify & prioritize high-value automation. 

  • Create Ansible Automation Platform 2 test environments for developers and operators.

  • Update content to utilize Collections (FQCN)
  • Install and configure private automation hub, and use content from there

  • Update to latest Ansible Automation Platform 1.2. The risk varies based on the AAP 1.x version targeted for upgrade

  • Update AnsibleTower nodes to RHEL 8

  • Replace isolated nodes with container groups. If migrating from Ansible Automation Platform 1.2 directly to Ansible Automation Platform 2.1, this step is not necessary.

If you would like to dig into this deeper, you can check out some further reading:

Red Hat Ansible Platform Creator Guide
Ansible Builder Guide
Ansible Navigator Creator Guide

Migration strategy considerations

You’ve completed your assessments and determined that it’s feasible to migrate to Ansible Automation Platform 2. The next phase is to develop an architecture, low-level design and delivery plan. We recommend including the following considerations during this phase.

Migrating your Ansible content

Your migration plan should assess your current Ansible automation content, such as roles, collections, playbooks and modules, and test their compatibility with Ansible Automation Platform 2. This assessment, at a minimum, should include:

  • Test and update automation content to support Ansible 2.9 or higher.

  • Technical considerations for running automation using Ansible Engine 2.9 with bundled content vs. Ansible core and certified/supported Collections in execution environments.
    • Migrating to Ansible Content Collections is not necessary with Ansible Engine 2.9. The recommendation, however, is to migrate to Ansible Content Collections as soon as possible.

  • Plan, test and port Python virtual environments (venvs) to execution environments.
    • Determine if custom execution environments are required based on the dependencies needed to execute your Ansible content successfully.
    • Ansible Automation Platform 2 provides tools to assist in the migration.

  • Retain, refactor or retire existing automation content such as moving to a Collection-only model or retiring content that is no longer used.

Integration into your environment and operating model

Your migration plan should include integration into existing systems. It should also assess the effects, if any, on your current operating model. Here are recommendations to include in your planning.

Content promotion workflows
  • What execution environment container versioning fits my model? Such as test, stage., latest, and release number.

  • Decide on automation hub (container registry) repository structure, such as separate repositories for testing, development, and production for Ansible Content Collections.

  • Should I use the hosted or a private automation hub instance?

Platform adoption

  • What support do stakeholders need to adopt and use the platform and what is the onboarding process?

  • What training and enablement is needed?

  • Who will be responsible for managing execution environments and content collections? Will this be managed centrally, per business unit or per team?

Execution environment lifecycle management

  • How should I manage and distribute ansible-builder definition files?

  • How will I update and secure my execution environments? What is the security response plan to patch Common Vulnerabilities and Exposure (CVEs) and remain compliant?

Platform life-cycle management

  • How will I deploy new clusters and provide the minimum requirements?

  • How will I upgrade my clusters, and at what cadence can I do so?

  • What are the non-functional requirements, and how will this affect my design? Examples include backups, configuration management, disaster recovery (DR), and high availability (HA).

Content distribution model

  • What automation controller design is suitable, such as deciding on multiple or single cluster deployments

  • How will I distribute content in multi-geo scenarios?

Observability, logging, and metrics

  • What metrics should be measured to determine the platform’s success?

  • What changes, if any, need to be made to ensure the platform can be audited?

  • How will the platform integrate into my existing logging and reporting systems?

Further reading:

Ansible Core Documentation
Blog: What's new in Ansible Automation Platform 2: automation content navigator
Blog: What's new in Ansible Automation Platform 2:  private automation hub

Next steps


Red Hat Enterprise Linux, Ansible Automation Platform, Automation controller, Ansible Navigator, private automation hub, Ansible Builder, migration


Craig Brandt

Craig Brandt is a Principal Technical Marketing Manager for Ansible Automation Platform. Prior to this position, Craig served as a Solution Architect representing Red Hat at the IBM Services Integration Hub. He focused on large, complex deals that covered EMEA, LATAM and Canada regions. He brings over 16 years of experience in the IT field that covers automation, containerisation, management, operations, development and solution design

rss-icon  RSS Feed