F5 BIG-IP to VMware Avi Load Balancer Migration: Mapping Virtual Servers, iRules, Profiles and Health Monitors

Load balancer migration guide

Migrating from F5 BIG-IP Local Traffic Manager (LTM) to VMware Avi Load Balancer means mapping each BIG-IP virtual server, pool, monitor, profile and iRule onto an Avi virtual service, pool, health monitor, application or network profile, and HTTP policy or DataScript, then moving traffic one application at a time. Broadcom's Avi Load Balancer Conversion Tool automates most of the object translation from bigip.conf, but iRules, ASM/WAF, APM-style authentication, SNAT pools and certificates still need a person to review and rework them.

We plan and run load balancer migrations as part of VMware Cloud Foundation (VCF) programmes, so this guide is written for the engineer who has to do the work: what the Avi architecture changes, how each F5 object maps across, what the conversion tooling actually produces, and how to cut traffic over without a long outage. Product behaviour comes from Broadcom TechDocs, Broadcom's conversion tool documentation and F5's own manuals. Where we give an opinion, we say so.

What changes when you move from F5 BIG-IP to Avi?

An F5 BIG-IP LTM pair is two appliances (physical or virtual) that each hold the full configuration, the management plane and the data plane. One unit is active, the other waits, and config sync keeps them aligned. BIG-IQ Centralized Management can sit above many pairs; F5 describes it as a tool that helps you manage BIG-IP devices and their services from one place. It does not carry application traffic.

VMware Avi Load Balancer separates those roles. The Avi Controller holds configuration, analytics and placement decisions. Broadcom documents Controller clusters as either one node (standalone) or three nodes, and a three-node cluster needs a quorum of two to stay operational. Service Engines (SEs) carry the traffic. If the whole Controller cluster goes down, the SEs keep forwarding traffic for configured virtual services, which Broadcom calls headless mode.

SEs live in SE groups, and the high availability mode is a property of the SE group. Broadcom documents three modes:

• Legacy HA (active/standby): exactly two SEs, built to mimic a hardware pair and make migration from appliances easier. The surviving SE takes over VIPs and SNAT IPs on failure.
• Elastic HA N+M (the default): each virtual service runs on one SE, and the Controller keeps M spare SEs of buffer capacity.
• Elastic HA active/active: each virtual service is placed on more than one SE, with a default minimum of two.

Two practical consequences follow. First, the migration becomes a set of placement decisions: which applications land in which SE group, with which HA mode, in which tenant. Second, Legacy HA exists so an F5 estate can land on familiar active/standby behaviour first. Some designs need it: Broadcom documents that Preserve Client IP requires an active/standby SE group, because without source NAT the network cannot tell which SE should receive reply traffic.

How do F5 objects map to Avi objects?

F5 describes a virtual server as a traffic-management object represented by a virtual IP address and a service, with a default pool, profiles, and resources such as iRules, persistence and SNAT attached to it. Avi spreads the same ideas over more, smaller objects. The biggest structural change is that persistence and health monitors attach to the Avi pool, while the virtual service carries the application profile, TCP/UDP profile, SSL settings and policies.

Table 1. F5 BIG-IP LTM to Avi object mapping. Attachment points from Broadcom TechDocs; "watch for" items from the VMware migration white paper and our project experience.

Virtual servers, pools and health monitors

These are the cleanest part of the move. In the VMware migration white paper's sample conversion of a real bigip.conf, virtual servers, pools, health monitors and profiles appear under both "Successful" and "Partial" status. Partial means some settings inside the object had no equivalent and the converter lists what it skipped. Read that list for every partial object; it is where behavioural differences hide.

Avi health monitors attach to the pool, and Broadcom documents that all active monitors on a pool must succeed for a server to be marked up. That matches F5's default "all" availability rule, but if you used F5's "at least N of" monitor rules, check the result by hand. Avi also supports external monitors that run a shell, Python or Perl script, where any output on stdout counts as success. F5 external monitor scripts do not come across on their own; the converter reports them as "Missing File" or "External Monitor".

Profiles and connection reuse

Avi application profiles come in DNS, HTTP, L4, L4 SSL/TLS, SIP and Syslog types, and the TCP/UDP profile sits beside them. An HTTP application profile only works with a TCP Proxy network profile. F5 OneConnect has no separate object in Avi: it becomes the connection multiplex setting inside the HTTP application profile. Because of that, the white paper explains, two F5 virtual servers that share an HTTP profile but differ on OneConnect produce two Avi application profiles, one of them with a "-cmd" (connection multiplex disabled) suffix.

Persistence

Avi persistence profile types are HTTP Cookie, App Cookie, Custom HTTP Header, Client IP Address, TLS and GSLB Site, and they attach to pools. F5 cookie insert and source address affinity have obvious targets. Universal persistence driven by an iRule does not, so treat it as part of the iRule work.

SSL profiles and certificates

Certificates and keys are not in bigip.conf. If the conversion tool cannot reach them, it creates placeholder objects named with "auto_created" and binds them to the virtual services, and you replace them after import. The white paper also notes that the converter applies Avi's default cipher suite rather than the ciphers configured on F5. For most applications that is fine. For anything with old clients, payment terminals or a compliance cipher list, compare the accepted ciphers before cutover.

SNAT and client IP visibility

On F5, SNAT is something you add to a virtual server. On Avi it is the default: Broadcom documents that SEs source NAT connections to pool members so replies return to the SE that owns the flow, which is what lets a virtual service scale out. Servers therefore see SE addresses. If an application logs client IPs, use X-Forwarded-For on HTTP, PROXY protocol on TCP where the application supports it, or Preserve Client IP, which needs an active/standby SE group and the SEs acting as the servers' default gateway.

What does the F5 to Avi conversion tool do?

There are two generations of tooling, and the naming is confusing enough that it is worth setting out.

Both work the same way at heart. Input is either an offline bigip.conf file or an online connection to the BIG-IP that downloads the configuration, certificates and keys. Broadcom KB 407620 notes that online mode in ACT 2.8.1 and earlier fails with a remote authentication account, and the workaround is a local F5 account or offline mode with an exported config file. Broadcom does not publish a public download page for ACT that we could find, so ask your Broadcom account team how you get access.

What the converter produces

The white paper lists the open-source converter's output directory:

• avi_config_create_object.yml and avi_config_delete_object.yml: Ansible playbooks that create and delete the converted objects
• ConversionStatus.xlsx: one row per F5 object with its migration status and the Avi configuration it became, plus a pivot summary
• Output.json: the converted configuration in Avi JSON format
• converter.log: the run log, with WARNING and ERROR lines to investigate

The basic offline conversion from the white paper looks like this. The Controller version and cloud name are examples from that document.

python3 /usr/local/bin/f5_converter.py -f bigip_v11.conf --ansible --controller_version 21.1.3 --cloud_name Default-cloud --no_object_merge --not_in_use

The flags that matter most in practice are --not_in_use (skip unreferenced and stale objects), --vs_filter (convert only named virtual servers), --partition_config (add partition config files on top of Common), --tenant, --segroup, --cloud_name and --vrf (place objects), --prefix (prefix object names), --convertsnat, and -l (a local folder of certificates and keys). The resulting playbook is pushed with ansible-playbook against the Controller.

Reading the ConversionStatus report

The report is the single most useful artefact in the project. The white paper defines its statuses: Successful, Partial, Skipped, Missing File, Not Applicable, Not Supported, Indirect and External Monitor. In its sample run against one bigip.conf, the counts were 79 successful, 76 partial, 24 skipped and 59 not applicable, with 38 warnings. That was a single lab config, but the ratio of partial to successful objects is close to what we see on real estates. Plan for someone to read every partial row.

Which F5 features convert cleanly and which need rework?

The white paper's planning table lists what the open-source converter did not support: WAF/ASM, GTM, iRules, external health monitors, authentication (SAML, LDAP, SSO), virtual servers with multiple certificates, SNAT pool and NAT policy, and system-level settings such as routing, DNS, NTP, SNMP and backup. Broadcom's later ACT datasheet claims automated conversion of custom rules and objects, and a March 2025 Avi blog says ACT converts F5 objects including iRules. Use that output as a first draft of the rewrite and test every converted rule.

Table 2. Conversion outcomes by F5 feature, from the VMware migration white paper's unsupported list and status examples. Approaches are our recommendation.

iRules to HTTP policies and DataScripts

The white paper's guidance is that most iRules can become Avi policies, and advanced iRules move to DataScripts, Avi's scripting engine. Broadcom's DataScript guide describes it as Lua-based scripting, with events such as HTTP_REQ, HTTP_RESP, HTTP_LB_DONE, SSL_HANDSHAKE_DONE, L4_REQUEST and DNS_REQUEST that roughly line up with iRule events like HTTP_REQUEST and HTTP_RESPONSE. The documented workflow for the open-source tool is to build the HTTP policy once in the Controller, export it as YAML into a file that starts with irule_custom_config:, and re-run the converter with --custom_config so the policy is attached to every virtual server that used that iRule.

In our experience, the iRule inventory decides the length of the project. Before anything else, export the list of iRules that are attached to a virtual server, group duplicates, and sort them into three buckets: replaceable by a native setting (HTTP to HTTPS redirect, X-Forwarded-For), replaceable by an HTTP policy, or needing a DataScript. The third bucket is the one to estimate carefully.

iApps and AS3-deployed applications

Broadcom's documentation does not describe special handling for iApps. In our experience, iApp-generated objects appear in bigip.conf as ordinary virtual servers, pools and profiles, so they convert like anything else, but the template that owned them does not come across. If BIG-IQ or AS3 declarations deploy your applications, keep those declarations: they are a clean inventory of intent and make it easier to rebuild the application as Avi automation (Ansible or Terraform) once it has moved.

How does a BIG-IQ managed estate change the plan?

BIG-IQ manages BIG-IP devices; it does not process traffic. The converter's input is still the configuration of each BIG-IP, including every partition. For a large BIG-IQ estate we work device group by device group, exporting Common plus each partition, and mapping each F5 partition to an Avi tenant with its own SE group where isolation matters. The white paper shows the pattern with --partition_config, --tenant and --segroup, and it warns that consolidating several ADCs onto one Avi deployment causes problems where IP addresses or object names overlap. Run --prefix per source device if you consolidate.

BIG-IQ also tends to own certificate lifecycle and licensing in those estates, so plan who renews certificates once they live on the Avi Controller. If you are scoping that kind of estate, our BIG-IQ to Avi migration estimator counts managed devices and partitions as separate effort drivers.

How to cut traffic over from F5 to Avi

The white paper reduces cutover to three questions: how the legacy VIP is reached, how the Avi VIP will be reached, and whether the VIP address changes. That gives five documented scenarios, which collapse into the decision flow below.

Testing before and after cutover

The white paper's trick for pre-cutover testing is worth copying. Import virtual services with enabled set to false and traffic_enabled set to true (its config_patch.py example patches every virtual service this way). The SEs then run health monitors against the real pool members, so you can see backend reachability and monitor results on Avi before any client traffic arrives. For a DNS cutover you can go further and test the application end to end on the new VIP with a hosts file entry.

1. Freeze and export

   Agree a change freeze on the F5 pair, export bigip.conf for Common and every partition, and collect certificates and keys (or use online mode with a local account).

2. Convert one wave

   Run the conversion with --not_in_use and a --vs_filter for the applications in this wave. Read converter.log and every partial row in ConversionStatus.

3. Rebuild what did not convert

   Replace auto_created certificates, rebuild iRules as policies or DataScripts, and recreate external monitors and SNAT behaviour.

4. Import disabled

   Push the playbook with virtual services disabled but traffic enabled, and confirm every pool shows healthy servers.

5. Functional test

   Application owners test against the Avi VIP (new IP) or a hosts file entry, including persistence, redirects, headers and client certificates.

6. Cut over and watch

   Swap the VIP, move the route or change DNS. Keep the F5 virtual server configured but disabled until the application owner signs off.

Rollback

Rollback should be the reverse of the cutover action and nothing more: re-enable the F5 virtual server and ARP, withdraw the Avi route, or repoint DNS. Do not delete F5 objects or decommission the pair until every application in the wave has run a full business cycle on Avi. For monthly batch jobs and quarter-end traffic, that can mean weeks. The converter's delete playbook (avi_config_delete_object.yml) is useful for clearing a bad import on the Avi side before you try again.

Common F5 to Avi migration mistakes

Most of the problems we are asked to fix come from treating the converter output as finished configuration.

• Converting stale objects. Without --not_in_use, years of disabled virtual servers and orphan pools come across and clutter the new platform.
• Ignoring partial rows. "Partial" can mean a lost timeout, a missing header insert or a different monitor receive string.
• Accepting the default cipher suite for applications with strict or legacy client requirements.
• Leaving auto_created placeholder certificates bound to virtual services after import.
• Choosing Elastic HA for applications that need the client IP without X-Forwarded-For, then finding Preserve Client IP needs active/standby.
• Consolidating several F5 pairs into one tenant without name prefixes, then hitting object name and IP overlaps.
• Underestimating iRules, WAF policies and authentication because the virtual server count looked small.

How is Avi Load Balancer licensed alongside VCF?

Broadcom's Specific Program Documentation for VMware Avi Load Balancer (August 2026) licenses it as subscription software measured in Service Units. When the Service Engine runs in a virtual environment, each Service Unit covers one core; bare metal SEs have different rules. The same document says Avi may count as an add-on when deployed with a VCF subscription bought after 13 December 2023. It also requires customers on version 32.1.1 or later to send Broadcom a compliance report within 180 days of registering the licence and every 180 days after, or features are degraded or blocked and support is suspended. Factor that reporting into the operational handover. For the wider VCF picture, see our guide to VCF 9.1 licensing by core.

F5 to Avi migration readiness checklist

• bigip.conf exported for Common and every partition, with device and partition owners recorded
• Certificates and keys collected, or online conversion tested with a local F5 account
• iRules attached to virtual servers inventoried and sorted into native, policy and DataScript buckets
• ASM/WAF, APM and GTM usage identified and scoped as separate workstreams
• SE group design agreed: HA mode, tenants, VRFs and which applications need client IP preservation
• Cutover method chosen per application: VIP swap, BGP route health injection or DNS
• DNS TTLs lowered in advance for any application changing VIP
• Rollback step written for each application and tested in the first wave
• Cipher requirements checked for regulated or legacy-client applications
• Compliance reporting for Avi 32.1.1 or later assigned to an owner

Load balancer migrations often run alongside other platform work. If you are also moving firewall policy into NSX, see our Cisco ASA to NSX Distributed Firewall migration guide, and if the target platform is new, our VCF 5.x versus VCF 9.x comparison and NSX-v to NSX in VCF 9 guide cover the surrounding design.

Frequently Asked Questions about F5 to Avi migration

Sources

• VMware: How to migrate from legacy load balancers to NSX Advanced Load Balancer (Avi), white paper, June 2022
• Broadcom: VMware Avi Load Balancer Conversion Tool datasheet, July 2025
• Broadcom KB 407620: Avi Conversion Tool migration from F5 fails with a remote authentication account
• GitHub: vmware/alb-sdk (Avi SDK and migration tools README)
• GitHub: avinetworks/avitools (archived)
• GitHub: nsx-advanced-load-balancer-tools (archived)
• Broadcom TechDocs: FAQs on Controller Cluster (Avi 30.2)
• Broadcom TechDocs: Legacy HA for Avi Load Balancer Service Engines
• Broadcom TechDocs: Elastic High Availability for Avi Load Balancer Service Engines
• Broadcom TechDocs: Application Profile
• Broadcom TechDocs: Persistence (Avi 31.1)
• Broadcom TechDocs: Health Monitoring (Avi 31.1)
• Broadcom TechDocs: Preserve Client IP (Avi 32.1)
• Broadcom TechDocs: DataScript Events
• Broadcom: VMware Avi Load Balancer Specific Program Documentation, 13 August 2026
• VMware blog: Stop iRules from weighing you down (March 2025)
• F5 TechDocs: About Virtual Servers (BIG-IP 21.0.0)
• F5 TechDocs: BIG-IQ Centralized Management Overview

Written by the Consult Circle VMware HCX migration team. Last reviewed 3 November 2026.