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


저자 소개

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

UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Virtualization icon

가상화

온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래