Welcome to part 3 of the F5 to Avi migration series. Part 1 of this series discussed use cases of Avi migration, and part 2 dived into the migration framework that you should follow for a successful error-free migration. 

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: F5 to Avi – Migration Strategy Framework

Overview

Not all F5 virtual services and configurations are equally suited for immediate migration to Avi. A strategic assessment helps prioritize migrations, manage risks, and allocate resources effectively. In this post I will try to provide a comprehensive framework for evaluating F5 objects and determining migration candidacy.

Step 1: Understand the Goal of Migration

Before identifying good candidates, clarify the purpose:

• Are you moving to reduce licensing costs (F5 → NSX ALB built into NSX or vSphere+ licensing)?
• Or are you modernizing to automation, elasticity, and analytics?
• Or is this part of a cloud or NSX-T network transformation?
• Is your organization on the F5 exit strategy?

The answer influences which F5 workloads make sense to migrate first.

If your organization is on the F5 exit strategy, then all F5 objects will be migrated to Avi. In this case, migrating the load balancers should be done in waves. 

Step 2: Discover Existing F5 Configuration and Create Inventory

Discover all objects currently deployed on F5:

• Virtual servers (VIPs)
• Pools and pool members
• Monitors
• Profiles (TCP, HTTP, SSL, persistence)
• iRules
• Data groups
• SNAT / NAT configurations
• Certificates
• Logging/Analytics setup

The below image shows a sample inventory for storing F5 configuration.

Step 3: Candidate Evaluation Criteria

The table below provides a general rule of thumb to help you decide which F5 VIPs are good candidates for early migration.

Category	Criteria	Why it matters
Simplicity	Virtual service using standard L4/L7 features (no complex iRules, no multiple chained profiles)	Avi migration tools easily convert these automatically.
Traffic Volume	Moderate traffic workloads (not mission-critical yet).	Easier to test performance and rollback if needed.
Protocol	HTTP/HTTPS, TCP — not exotic protocols (SIP, FIX, RTSP, etc.)	Avi supports most common ones natively.
iRules Complexity	Minimal or no custom iRules.	iRules → Avi DataScripts conversion is manual; avoid early.
Dependencies	Isolated pools with minimal shared objects.	Easier to migrate without breaking others.
SSL/TLS	Simple SSL termination or pass-through.	Easier to map to Avi SSL profiles and certificates.
Persistence & Monitors	Standard monitors (HTTP, TCP).	Avi supports 1:1 mapping for these.
Routing/Networking	Within the same VLANs or subnets.	No complex routing changes needed.
Change Tolerance	Apps with flexible change windows.	Easier to coordinate downtime or cutover.

Based on the above, the applications can be characterized into three main categories.

Low Complexity (Good Candidates)

• Web applications using HTTP/HTTPS protocols.
• Simple L4 applications (TCP/UDP) with straightforward load balancing needs (round-robin, least connections, weighted).
• Standard SSL/TLS termination without custom certificate logic.
• Basic pool configurations with no advanced session persistence.
• HTTP request/response manipulation is simple and rule-based.

Moderate Complexity (Requires Planning)

• Some custom iRules with moderate logic (10-50 lines)
• Advanced pool configuration (priority group, ratio-based load balancing).
• Custom health monitors or complex health check logic.
• Session persistence requirements (cookie-based, source IP affinity).
• Multiple SSL certificates with SNI.
• Rate limiting or basic traffic management.
• Custom header manipulation.

High Complexity (Challenging Candidates)

• Complex iRules with significant business logic (100+ lines, multiple conditions). When migrating such load balancers, you need to convert the iRules to Avi DataScripts or policies.
• Applications with extensive traffic management policies (custom packet manipulation or deep inspection logic, advanced compression or content transformation logic.)
• Legacy applications with complex SSL/TLS configurations.
• Extensive use of pools, profiles, and interdependencies. 
• Those using F5-specific features like APM (Access Policy Manager) or ASM (Application Security Manager).

Technical Factors

Apart from application characteristics, the following factors will help you decide on planning your migration waves:

• Protocol support—Avi excels with L7 (HTTP/HTTPS) but also handles L4 (TCP/UDP). Check if your apps use supported protocols.
• Health monitoring—Simpler health checks migrate more easily than complex custom monitors.
• Persistence methods—Common methods (source IP, cookie) migrate smoothly; evaluate custom persistence.
• SSL offloading—Standard SSL termination transitions well.
• Pool configurations—Straightforward pool setups are ideal first candidates.

Business Risk Profiling

Prioritize applications that:

• Are non-critical (dev/uat) for initial proof-of-concept migrations. Successful migration of non-prod load balancers gives more confidence to application owners to move forward with production migration.
• Have upcoming refresh cycles or planned changes. You can take advantage of the maintenance window to minimize downtime, as the apps will be down anyway for refresh or enhancements. 
• Have lower traffic volumes. Before migrating the load balancers, you can reset the counters on the LB in F5 and observe the traffic pattern.
• Are non-revenue-generating services. The risk factor is low with internal application. 
• Have easy rollback options.
• Need better analytics and visibility.

Step 4: Prioritize with a Scoring Matrix

Assign weights to these criteria to create a migration readiness score.

Factor	Weight	Example Scoring (1–5)
iRule Complexity	25%	1 = complex, 5 = none
Dependency	20%	1 = shared pools, 5 = isolated
Traffic Criticality	15%	1 = critical, 5 = test app
Protocol Simplicity	15%	1 = non-HTTP, 5 = HTTP/S
Monitor Complexity	10%	1 = custom, 5 = standard
SSL Complexity	10%	1 = mutual TLS, 5 = simple
Networking Impact	5%	1 = routing change needed, 5 = none

Anything scoring >70% is a “good early candidate.”

Step 5: Collect and Analyze F5 Configuration

Collect the F5 configuration using the Avi Conversion Tool. The tool provides:

• Parses exported F5 configuration.
• Maps objects to Avi constructs.
• Identifies unsupported or partially supported configurations.
• Generates a Migration Readiness Report.

This report clearly shows which F5 objects can be:

• ✅ Auto-migrated

• ⚠️ Partially converted (needs tweaking)

• ❌ Not supported

This is your data-driven confirmation of good candidates.

The below image summarizes steps 1-5 in a graphical format.

Migration Timeline

This is roughly what a migration timeline should look like. The timelines can vary based on your environment. 

This comprehensive framework will help you build a prioritized migration roadmap based on technical feasibility, business risk, and organizational readiness. The key is starting simple, learning continuously, and building momentum as your team gains Avi expertise.

And that’s it for this post. In the next post of this series, I will demonstrate the actual migration process. Stay tuned!!!

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