Free planning tool
F5 BIG-IP to Avi Migration Estimator
How long it really takes to move a BIG-IP estate onto VMware Avi Load Balancer - how many virtual services you'll actually build, how much of your configuration converts on its own, how many waves it takes, and what sets your end date.
We don't ask for and won't accept load balancer configuration through this site. Everything below is calculated in your browser from the numbers you enter.
The virtual server count is not what decides your end date
Two estates with the same number of virtual servers can be twelve months apart. What separates them is how much of the configuration converts cleanly, and how many applications your owners can realistically test in a week.
~80%
Converts automatically
Virtual servers, pools, monitors, SSL profiles and persistence, read by the F5 configuration conversion tool.
~20%
Built by hand
iRules that hold state, unusual profiles, non-HTTP protocols - anything the converter cannot read.
APM
Does not move at all
Access policies have no Avi equivalent. They need an identity provider, ZTNA or a dedicated remote-access product.
Indicative figures for a clean LTM estate before your own answers adjust them.
Build your Avi migration estimate
Only the virtual server and application counts really matter. Everything else is pre-filled with the assumptions we use on a typical UK enterprise estate, so you can jump to the results and refine afterwards.
Step 1 of 5 - Your BIG-IP estate
Count each unit you'd have to log into, not each HA pair.
Older trains convert less cleanly.
1 if everything sits in Common.
iApps hide configuration behind templates and slow conversion.
How long does an F5 to Avi migration take?
A mid-size estate - around 300 virtual servers across 95 applications, mixed iRules, no APM - runs at roughly 43 to 47 weeks from discovery to BIG-IP decommission. The engineering is rarely the constraint. Application owners have to validate that their service still behaves the same on a new platform, and there are only so many of those conversations a week, which is why the estimator asks how many applications you can test concurrently before it asks anything about hardware.
A realistic programme runs in seven phases: discovery and configuration audit, Avi design, platform build, a pilot application, the migration waves themselves, hypercare, and BIG-IP decommission. The estimator models each separately, then applies uplifts for the things that reliably slow this work down - APM, ASM, heavy iRule use, GTM, HSM-held key material, regulated scope and missing application ownership.
Typical estate benchmarks
| Estate profile | Waves | Typical elapsed time |
|---|---|---|
| 120 virtual servers, 40 applications, light iRules | 12 waves | 24–28 weeks |
| 320 virtual servers, 95 applications, mixed iRules | 24 waves | 43–47 weeks |
| 600 virtual servers, 150 applications, ASM in scope | 38 waves | 60–70 weeks |
| 600 virtual servers, 150 applications, APM in scope | 38 waves | 70+ weeks, plus a separate access project |
What the conversion tool does and doesn't do
Avi ships a configuration converter that reads a BIG-IP configuration and produces Avi objects for virtual services, pools, health monitors, SSL profiles and persistence. On a clean LTM estate it covers around 80 per cent of the build. Everything outside that - iRules with state, APM policies, unusual profiles, non-HTTP protocols - is designed and built by an engineer, and that is where almost all the effort in these programmes actually sits.
The APM problem, stated plainly
Avi does not replace BIG-IP APM. There is no equivalent to access policies, the visual policy editor, or network access. If APM is in scope, you are running two programmes: a load balancing migration, and an access modernisation project that needs SAML or OIDC through your identity provider, a ZTNA service, or a dedicated remote-access product. Discovering that in month nine is the single most expensive mistake we see, which is why the estimator raises it before anything else.
Managing a large estate through BIG-IQ changes the arithmetic considerably - central configuration, templating and traffic statistics let you retire far more virtual servers than a device-by-device audit ever would. If that describes you, use the BIG-IQ to Avi migration estimator instead.
F5 to Avi migration: common questions
How long does an F5 BIG-IP to Avi migration take?
For a mid-size estate of roughly 300 virtual servers and 95 applications, expect 43 to 47 weeks at a balanced pace. The virtual server count is not what decides it. Application owner availability for testing usually is, because every virtual service has to be validated by someone who can say the application still works.
Do iRules convert to Avi automatically?
No. Avi uses DataScript, which is also Tcl but with a different event model and API. Simple redirects and header manipulation convert quickly. Anything using session tables, side-band connections or persistent state is a rewrite, and the right answer is often to move that logic back into the application rather than recreate it on the load balancer.
Does Avi replace BIG-IP APM?
It does not. Avi has no equivalent to APM's access policies, VPE workflows or network access. Those users need an identity provider with SAML or OIDC, a ZTNA service, or a dedicated remote-access product. Discovering this in month nine is the single most expensive mistake on these programmes, which is why the estimator flags it before anything else.
Can ASM WAF policies be imported into Avi?
Not directly. Avi WAF uses a different engine with a positive-security model built on the OWASP core rule set. Policies are rebuilt from intent, deployed in detection mode, and tuned against real traffic before enforcement. Budget a tuning window per application rather than a single switch-on.
What is the F5 Configuration Conversion Tool and how much does it help?
Avi ships a converter that reads a BIG-IP configuration and produces Avi objects for virtual services, pools, health monitors, SSL profiles and persistence. On a clean LTM estate it handles around 80 per cent of the build. iRules, APM policies and unusual profiles fall outside it, which is why the estimator lowers coverage when your estate is iRule-heavy or runs non-HTTP protocols.
Should we migrate application by application or all at once?
Application by application, with the old BIG-IP virtual server left in place until the new Avi virtual service has proved itself. That is what makes rollback a DNS change rather than an incident. Big-bang cutovers are only sensible for small, well-understood estates.
How does the cutover actually work?
The most common approach builds the Avi virtual service on a new address, tests it out of band, then moves traffic with a DNS record change and a short parallel run. VIP IP takeover is possible where DNS TTLs cannot be controlled, but it needs L2 planning and a maintenance window because both platforms cannot own the same address at once.
What does Avi need in terms of infrastructure?
A controller cluster - three nodes for production - and Service Engines sized to your traffic. As a planning rule, allow one Service Engine pair per Service Engine group and budget roughly one Service Engine per twenty virtual services, with two vCPUs each, or four where WAF or heavy SSL is involved. The estimator sizes this from your answers.
Is this estimate a quote?
No. It is a planning estimate built from how these programmes actually run. The figure that moves most between this page and a real plan is how much of your configuration converts cleanly, and that can only be settled by reading a redacted configuration.
Want the estimate turned into a plan?
Send us a redacted bigip.conf and we'll tell you what really converts, what has to be rebuilt, and what should never be migrated at all. No charge, no obligation.