With support for Red Hat Ansible Automation Platform 1.2 (also known as Red Hat Ansible Tower) going end-of-life in September 2023, many IT organizations are migrating to Red Hat Ansible Automation Platform 2, including Red Hat's own IT department. As early adopters of IT automation and longtime Ansible users, we want to share our authentic insights from the migration process so that other organizations can use them to enhance their own migrations and use of Ansible Automation Platform.

[ Learn 5 reasons to migrate to Red Hat Ansible Automation Platform 2 ]

This two-part blog series explores our journey migrating from Ansible Tower to Ansible Automation Platform. Part 1 will discuss our history with Ansible, our thought process and design methodology for migrating from Ansible Tower, and our provisioning and deployment strategy at a high level. In part 2, we'll share what we actually implemented, how it went from both our perspective and that of our end users, and how we're leveraging Ansible Automation Platform 2 features to plan for scalability.

Our Ansible background

Our IT department has come a long way on our automation journey. Before deploying Ansible Tower in 2016 and upgrading to Ansible Automation Platform in 2022, our IT team spent tens of thousands of hours updating, patching, and decommissioning the resources in our network.

With the stability Ansible provided, we created procedures and playbooks to automate manual processes, including:

• Decommissioning IT network resources
• Infrastructure patching
• Systems on-call alert automation
• Email and mailing list management
• Device deployment and configuration compliance
• Access control list (ACL) validation and firewall configuration
• Package repository management
• Cloud services management and deployment of services to AWS
• Resource management for product labs

Because of our success with Ansible Tower, planning an effective migration to Ansible Automation Platform was critical.

Red Hat IT officially went into production and started migrating workloads to Ansible Automation Platform in January 2022, when the product was at version 2.1. As of the writing of this article, we're running version 2.2.1 (a straightforward upgrade that took only a few hours).

Here are a few architectural factors and overall goals that informed our automation strategy.

[ Get the checklist: 5 ways to prepare for migration to Red Hat Ansible Automation Platform 2. ]

Creating a seamless transition for end users

Our first priority in transitioning from Ansible Tower to Ansible Automation Platform 2 was making the migration process as seamless and transparent as possible for our infrastructure team's end users (associates running automation playbooks both in and outside of IT). Rather than compel customers to move all their data on a strict timeline, we decided early that our infrastructure teams would take on all of the "grunt work" of the migration for them, including:

• Backing up, merging, and restoring data
• Shifting from virtual environments to automation execution environments
• Updating our network topology to include automation mesh

Merging two Ansible Tower instances

Before migrating to Ansible Automation Platform, Red Hat IT had two successful Ansible Tower deployments. Between them, they handled around 4,000 jobs per day, with approximately 800 users and more than 30,000 unique hosts. We needed to merge those two instances to move to Ansible Automation Platform.

Ideally, an organization would back up its data from its Ansible Tower, then be able to restore it easily on Ansible Automation Platform. Since we had two separate deployments to merge, this wasn't possible. Instead, we used Python and the Ansible Tower API to create custom tooling to pull all of the data (except for credentials—more on that later) from both of our historic instances, merge it, then add it to the new platform. It took us one month to build this solution.

As we did not follow the official database backup and restore process, our internal customers had to update their continuous integration (CI) pipelines to point to the new job template identifiers in the new Ansible Automation Platform deployment. To make this as easy as possible, we encouraged our customers to use the named URLs provided by the Ansible Automation Platform API.

[ Download now: A system administrator's guide to IT automation. ]

Prioritizing self-service automation for IT teams

We also manage automation differently from many other enterprise IT organizations. Rather than fully controlling automation for our end users, we focus on providing a self-service experience for teams running automation playbooks. Through the role-based access control (RBAC) system in Ansible Tower, we made our end users system administrators in their environments, allowing them to define their own jobs and inventories. This approach gives the teams the most context about their automation requirements and the flexibility they need to make changes while also improving our infrastructure team's ability to scale their services.

We want to continue prioritizing self-service on the new platform. Therefore leveraging RBAC is a priority. Ansible Tower previously worked as a control plane for us where we could manage RBAC, workflows, and continuous integration and continuous delivery (CI/CD). Ansible Tower becomes an automation controller in Ansible Automation Platform, a component of the larger overall platform. From here, we could manage permissions in a way that matched our previous process.

[ Get started with automation controller in a hands-on interactive lab. ]

Wrap up

Our next article will share our biggest migration challenges, lessons learned along the way, and our experience using Ansible Automation Platform 2.

[ Learn more about how to simplify network automation management. ]