Model your costs
4 products · 4 migration paths

Load Balancers / ADC migration paths

Application delivery controllers, F5, Citrix NetScaler, A10, carry per-instance and throughput-tier licensing. These paths compare moving to open-source proxies and load balancers.

Not sure which to pick? Read the buyer's guide →

Load Balancers / ADC migration guide

Application delivery controllers carry per-instance and throughput-tier licensing, premium appliance hardware, and per-module fees (WAF, GSLB). Open proxies, HAProxy, NGINX, Traefik, deliver L4/L7 load balancing and TLS termination on commodity hardware, removing the license tax for many use cases.

Let the estate pick the proxy

  • HAProxy, high-performance L4/L7, rich ACLs; the closest open analog to a hardware ADC.
  • NGINX, versatile reverse proxy/LB, huge ecosystem.
  • Traefik, dynamic, cloud-native ingress, ideal for Kubernetes.

The choice usually follows the shape of your estate. If you run a fleet of classic VIPs with content switching and persistence, HAProxy maps most directly onto the ADC mental model. If your workloads already sit behind reverse proxies and you want a large module ecosystem, NGINX fits, with the caveat that active health checks and cookie persistence sit in NGINX Plus. If you are heading into Kubernetes, Traefik’s dynamic service discovery removes most hand-written config. All three run on commodity hardware or VMs, so the license line disappears and is replaced by infrastructure and the engineering time to operate the proxy yourself.

Be honest about the advanced modules

Core L4/L7 load balancing and TLS offload port cleanly to open proxies. What does not port one to one is the surrounding module stack: integrated WAF (F5 ASM, Kemp and NetScaler WAF), access and identity (F5 APM, Citrix Gateway/ICA proxy for VDI), and GSLB for multi-site steering. None of these has a drop-in open equivalent. Plan a dedicated WAF such as a ModSecurity or Coraza engine, an auth proxy for access control, and DNS-based global balancing for GSLB. Inventory which modules are genuinely in use before you assume a one-box replacement, because these are the items that turn a clean migration into a multi-product project.

Translate config carefully

Inventory virtual servers (VIPs), pools/members, health checks, and persistence, then export rules/policies (F5 iRules, NetScaler content-switching, A10 aFleX) and TLS certificates. The translation work is mapping each virtual server → a frontend/backend or server/upstream block, and rules → ACLs/http-request logic (or njs on NGINX). Simple header, path, and redirect logic converts directly; large lookups belong in map files; only genuinely procedural rules need scripting. Migrate certs into the proxy’s store as full chains, and replicate health checks and session persistence, tuning check intervals and retry counts so failover timing does not change.

Sizing & the right tier

Size for L7 throughput and SSL/TLS TPS, and remember that TLS termination/inspection is CPU-intensive. The classic migration mistake is sizing on raw throughput while ignoring handshakes per second, which is what actually limits a software proxy under real TLS load, so account for concurrent connections, connections per second, and TLS handshake rate, not just bandwidth. Deploy active/standby (e.g. with keepalived/CARP) for HA, matching the resilience the vendor pair gave you, and treat that HA as something to build and test rather than a checkbox: the appliance packaged failover for you, and now you own it.

Cutover by swinging traffic

Stage the new proxy and warm it with test traffic, validate routing/persistence/TLS live (curl/SNI checks), then swing the VIP or DNS per service to the new proxy, keeping the old ADC configured as immediate fallback through hypercare. Roll back by swinging DNS back.

The checks that catch a bad swing

L4/L7 routing and persistence, TLS/SNI and certificate validation, health-check and failover behavior, and a load/throughput test versus baseline.

Use the TCO calculator to model a per-instance comparison.