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.

1. Assess your current environment

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. 

2. Identify technical barriers

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.

3. Prepare your team

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.

4. Get your automation content ready to move

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.

5. Integrate into existing workflows

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.

Learn from the experts

Learn how Red Hat Consulting can help you adopt automation faster, including migration services.

Try it today

Explore how Red Hat Ansible Automation Platform can help your organization automate with a free 60-day trial.

Get self-paced labs on demand

Check out the Ansible Automation Platform training page for technical, hands-on, self-paced labs for automation controller, content navigator, and execution environments.

Visit the Red Hat Customer Portal

Read this Ansible Automation Platform 2 Knowledgebase article for the latest migration information.