5 ways to prepare for migration to Red Hat Ansible Automation Platform 2

Red Hat® Ansible® Automation Platform 2 introduces an updated architecture, new tools, and an improved but familiar experience for automation teams. As you plan your migration strategy, review the considerations outlined in this checklist to prepare for a smooth transition to Ansible Automation Platform 2.

Your environment has unique configurations, and it is crucial to perform a thorough technical assessment before migration. 

• Analyze your current Ansible Automation Platform 1.x 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 stakeholder readiness to plan and execute the migration. 
• Ensure compliance, security policy enforcement, and auditing. 

Ansible Automation Platform 2 introduces new requirements that will influence your migration strategy. If meeting these requirements needs significant effort, we recommend a phased migration approach. 

• Automation controller 4 (which replaces Ansible Tower) exclusively supports PostgreSQL 12. PostgreSQL 10 is not supported. 
• Ansible Automation Platform 2 requires Red Hat Enterprise Linux® 8 (x86_64) for physical and virtual environment installations.
• Automation execution environments replace Python virtual environments. 
• Ansible Automation Platform 2 migration tools support the latest Ansible Automation Platform 1.x version. 
• Ansible Automation Platform 2 includes Ansible Core 2.9 for playbook compatibility purposes, as well as the latest versions via execution environments.

Your migration plan should consider the impact on the whole organization. We recommend the following: 

• Perform a cost-benefit analysis that outlines initial migration costs, ongoing savings, and increased revenue. 
• Identify external and internal stakeholders and establish their availability. 
• Perform a risk analysis to understand the effects on business processes and service delivery. 
• Decide on project time frames, milestones, and deliverables. 
• Assess the change management and training needed for stakeholders. 
• Establish migration success criteria and the needed measurement metrics.

Your migration plan should assess your current Ansible Automation Platform content, such as Ansible Roles, Ansible Content Collections, Ansible Playbooks, and modules, and test their compatibility with Ansible Automation Platform 2. This assessment, at a minimum, should: 

• Test and update automation content to support Ansible Core 2.9 or higher. 
• Consider technical requirements for running automation using Ansible Core 2.9 with bundled content versus Ansible Core and certified or supported collections in execution environments. 
  • Migrating to Ansible Content Collections is not necessary with Ansible Core 2.9, but we recommend migration as soon as possible.
• Plan, test, and port Python virtual environments (venvs) to execution environments. 
  • Determine if user-built execution environments are required based on the dependencies needed to execute your Ansible content successfully. 
  • Access tools provided by Ansible Automation Platform 2 to assist in the migration. 
  • Read more about migrating from Python virtual environments to automation execution environments.
•   Retain, refactor, or retire existing automation content, such as moving to a collection-only model or retiring content that is no longer used.

Your migration plan should include integration into existing systems. It should also assess the effects, if any, on your current operating model. Ask yourself these questions when planning your migration:

Content promotion workflows

• What automation execution environment versioning fits my model? (Such as test, stage, latest, and release number.) 
• What automation hub (container registry) repository structure works best for my organization? (Such as separate repositories for testing, development, and production for Ansible Content Collections.) 
• Should I use the hosted or private automation hub instance? Who will be managing this instance?

Platform adoption 

• What support do external stakeholders need to adopt and use the platform? 
• What training and enablement is needed to onboard all stakeholders?
• Who will be responsible for managing execution environments and content collections? Will this be managed centrally or per business unit?

Execution environment life cycle management 

• How should I manage and distribute ansible-builder definition files? 
• How will I update and provide security for my execution environments? What is the security response plan to patch Common Vulnerabilities and Exposures (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? What is my upgrade cadence? 
• What are the nonfunctional requirements, and how will this affect my design? (Examples include backups, configuration management, disaster recovery (DR), and high availability (HA).

For more information, read the new reference architecture: Deploying Red Hat Ansible Automation Platform 2.1.