In the first post of this series, I discussed the top reasons why an organization wants to move from F5 to Avi load balancer. In this post, I will discuss the migration strategy for a successful migration.

To migrate from F5 to Avi Load Balancer, VMware provides a free Avi Load Balancer Conversion Tool (ALBCT) that automates the translation of F5 BIG-IP configurations. The migration process involves using this tool to convert the F5 load balancer configuration and then cutting over traffic to the Avi-based environment.

Migration Strategy: An Eight-Stage Approach

The key to successful migration is meticulous planning, comprehensive testing, and leveraging Avi’s conversion tool to automate complex configuration transformations. With proper execution, organizations emerge with a modern, scalable, and easier-to-manage load balancing platform that supports their digital transformation initiatives.

The image below lists the various stages involved in the strategic planning for a successful migration.

Stage 1: Planning and Assessment

Before any technical work begins, thorough planning is essential. This stage involves the following key activities:

1. Scope Definition: Determine the number of virtual services, pools, policies, and iRules to be migrated. Document the scope clearly—a small pilot migration differs drastically from migrating 1,000+ virtual services across multiple data centers.
2. Infrastructure Readiness Assessment: Evaluate your target infrastructure. Ensure Avi Controllers and Service Engine compute resources are available. Plan cloud, tenant, VRF (Virtual Routing and Forwarding), and service engine group configurations on the destination Avi cluster.
3. Application Owner Engagement: Partner with application teams to understand dependencies, traffic patterns, security requirements, and acceptable maintenance windows. This collaboration is critical for planning cutover strategies.
4. Configuration Cleanup: Review your F5 configuration and remove unused or decommissioned objects. Tens of thousands of lines of legacy configuration can hide unused objects that will complicate migration.
5. Cutover Strategy Definition: Determine your migration approach: big bang (all applications at once), phased (applications in waves), or staggered (minimal groups over an extended period). Consider VIP reachability, IP address retention, rollback capabilities, and downtime tolerance.
6. Migration Tool and Resource Planning: Decide whether to use the Avi Conversion Tool Appliance (UI-based) or the Python-based converter for your environment. Not all types of load balancers can be converted using the ACT UI (I will discuss this in a later post). Allocate resources and timelines, and identify who will perform the conversion.

Stage 2: Design the Target Avi Architecture

A well-designed target architecture serves as the roadmap for the entire migration. It defines what the end state should look like, preventing ad hoc decisions and ensuring key stakeholders understands the destination.

The key decisions involved in the design phase are: 

1. Right-Sizing Infrastructure: Proper architecture design ensures you provision the right amount of resources, controller clusters, service engines, and compute capacity based on your actual traffic patterns and requirements. This prevents both overprovisioning (wasted costs) and underprovisioning (performance issues).
2. Alignment with Business Goals: The target architecture should align with your organization’s strategic objectives: cloud-native adoption, multi-cloud strategy, cost optimization, or DevOps enablement. Without this alignment, you risk migrating to a setup that doesn’t serve your long-term goals.
3. Cloud-Native Optimization: Unlike F5’s on-premises monolithic model, Avi thrives in distributed environments. The target architecture should be designed to leverage Avi’s cloud-native capabilities—containerization, Kubernetes integration, elastic autoscaling, and geographic distribution across regions.
4. High Availability and Disaster Recovery: Designing the target architecture upfront lets you plan for redundancy, failover mechanisms, and disaster recovery strategies across multiple availability zones or regions. This prevents single points of failure.
5. Simplified Operations: A thoughtfully designed architecture reduces operational complexity. For example, deciding on centralized vs. distributed controller management, service engine placement, and policy consolidation directly impacts day-2 operations and team workload.
6. Scalability for Future Growth: A well-designed architecture accommodates future growth. It should support adding new applications, expanding to additional clouds, or scaling to handle increased traffic without major redesigns.

The target architecture complements your migration strategy. Understanding what you’re building helps you decide: Do you migrate applications in waves? Can you run both F5 and Avi in parallel during transition? What’s the cutover sequence?

Stage 3: Proof of Concept (PoC)

To start the migration process, migrate a subset of non-critical applications to validate functionality, performance, and automation workflows. The best approach for this kind of testing is to build an isolated PoC environment and use the offline migration method. Export the F5 BIG-IP.conf file and import it into the ACT tool in your PoC environment to get comfortable with the migration steps. Try to have a production-like Avi architecture in the PoC environment. 

For successfully converted objects, login to the ACT tool over SSH and analyze the converted config to get a better understanding of the behind-the-scenes working of the tool. This will help in understanding mapping the F5 objects to Avi objects (VIPs → Virtual Services, Pools → Pools, Profiles → Application Profiles).

Stage 4: Configuration Discovery and Conversion

This is where the technical migration begins using Avi’s migration tool.

Online vs. Offline Mode:

• Online Mode: The Avi Conversion Tool connects directly to your F5 BIG-IP using admin credentials and automatically fetches all necessary configuration files, certificates, and keys. This approach is cleaner and less error-prone.
• Offline Mode: You manually export F5 configuration files, certificates, and keys and upload them to the conversion tool. This is useful if direct F5 access isn’t available or for security-sensitive environments.

Note: In my opinion, for a production migration, you should use online mode (if possible) to ensure there are no deltas in the F5 configuration after the BIG-IP.conf file is exported. 

The ACT tool performs the following tasks in the backend: 

1. F5 Discovery: The tool analyzes your F5 configuration and categorizes virtual services by type (L4, L7, DNS, UDP, SSL, WAF), counts pools and pool members, and identifies iRules and policies.
2. Configuration Conversion: F5 configuration objects are automatically converted to corresponding Avi objects. Virtual servers become virtual services, pools map to pools, profiles translate to application profiles, and policies are converted to Avi policies. The tool generates detailed reports showing conversion status for every object.
3. iRule Handling: The tool attempts to convert iRules to native Avi functionality or DataScript. Approximately 75% of iRules convert to native features requiring no scripting. Complex iRules are flagged for manual review and custom DataScript implementation.
4. Output Generation: The tool generates Ansible playbooks in YAML format, status reports showing object mapping, and a CSV file for migration continuation. These deliverables become your blueprint for deployment.

Step 5: Customization and Remediation

Not all configurations convert perfectly. Some of the converted objects need remediation and customizations. Common considerations for this phase are

1. Unsupported Features: Some F5 features may not have direct Avi equivalents. These require manual workarounds or alternative implementations using DataScript.
2. Policy Consolidation: Decide whether to consolidate duplicate policies across virtual services. Avi supports policy reuse through the reuse_http_policy option, reducing management overhead.
3. Certificate and Key Management: Ensure all certificates and keys are properly imported. If certificates are protected by passphrases, provide the passphrase file to the conversion tool.
4. Configuration Patching: Use the configuration patch utility to bulk-modify objects, filter specific virtual services, or apply custom changes to the converted configuration before playbook generation.

Stage 6: Validation and Functional Testing

Thorough testing prevents production incidents and builds confidence in the migration.

Testing Approach:

1. Lab Validation: Deploy the converted configuration on a staging Avi Controller in a non-production environment. Test each virtual service to ensure functionality matches the original F5 configuration. If a staging controller is not available, deploy the load balancers with traffic disabled on them. In my organization we follow this approach and call this activity Pre-Build. 
2. Virtual Service Testing: Migrated virtual services are created in a disabled state to avoid ARP conflicts. For each virtual service:
   • Enable it with a new test IP address (different from production).
   • Access it directly, use an alternate DNS name, or modify client hosts file.
   • Verify traffic flows correctly through the Service Engine.
   • Confirm SNAT is configured so return traffic routes through Avi (not the server’s default gateway).
   • Validate health checks, persistence, SSL offloading, and any application-specific behavior.
3. Rollback Procedure: Define and test rollback procedures for each application. Ensure you can quickly revert to F5 if issues arise, minimizing impact on users.
4. Security Validation: Confirm SSL/TLS configurations, WAF policies (if applicable), and security policies function as expected. 

Stage 7: Cutover and Go-Live

This is the controlled transition of production traffic from F5 to Avi. Push the generated Ansible playbook to your destination Avi Controller. The converted virtual services are initially in a disabled state to prevent duplicate IP conflicts. You can then begin the traffic cutover from F5 to Avi. This can be done gradually by migrating specific partitions or applications at a time. 

The key activities in this phase are:

• Traffic Cutover: For each application, disable the virtual service on F5 and enable it on Avi with the production IP address. 
• DNS cutover (change DNS records to point to Avi VIP).
• IP address retention (reuse the F5 VIP IP address on Avi after disabling on F5).
• Load balancer or appliance changes (update upstream routing/DNS to Avi).
• Load balancer Re-IP: In certain cases, its not possible to retain the load balancer VIP address or pool member address. In this case, you have to re-ip the VIP/pool in Avi. Ensure that after the Re-IP, DNS changes are made to reflect the new IP. 

Stage 8: Monitoring

Closely monitor application behavior, response times, error rates, and user experience immediately after cutover. Have rollback procedures ready if issues emerge. The common activities for this phase are: 

• Monitor the migrated load balancers for 24-48 hours post-cutover.
• Identify and address any performance variations.
• Fine-tune configurations based on real production data.
• Document any customizations or workarounds.

And that’s it for this post. In the next post of this series, I will discuss how to determine which F5 load balancers are good migration candidates. 

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.