Most teams pick a load balancer replacement the wrong way: they line up ADC datasheets and compare throughput ceilings, module lists, and connection limits box by box. That produces a confident-looking shortlist and tells you almost nothing about whether the move will work, because an ADC migration is not decided by the appliance’s headline specs. It is decided by which of its modules you genuinely depend on, and by how much custom logic you are quietly carrying in its rules engine. The better approach is to fix a short list of factors that genuinely change the answer, score your real estate against them, and only then look at proxies. This guide gives you that rubric.
Start with the estate, not the appliance
Before you shortlist anything, inventory what the ADC actually does for you today. Separate plain L4 forwarding from L7 content switching, and write down which advanced modules are truly in use rather than merely licensed: WAF, GSLB, access and identity gateways, DDoS. Then count your custom rules (F5 iRules, NetScaler content-switching policies, A10 aFleX) and grade them by how procedural they are, note your peak L7 throughput and TLS handshake rate, whether you are heading into Kubernetes or staying on standalone VIPs, and how your high-availability pair is built. Those facts decide more than any throughput number.
The factors that turn a swap into a project
- L4 versus L7 needs. Plain L4 forwarding ports to any open proxy almost trivially. L7 content switching, header and path routing, and persistence take more care, and knowing your split tells you how much of the work is configuration versus re-engineering.
- Dependence on advanced modules. This is the factor that turns a clean swap into a multi-product project. Integrated WAF, GSLB, and identity or access gateways have no drop-in open equivalent, so each one you actually use becomes a separate component to plan, not a checkbox to tick.
- Throughput and TLS handshake rate. Size on the right number. TLS termination is CPU-intensive, and handshakes per second, not raw bandwidth, is what actually limits a software proxy under real load. Account for concurrent connections and connections per second alongside throughput.
- Kubernetes ingress versus standalone appliance. A fleet of classic VIPs is a different problem than dynamic service discovery inside a cluster. Where your workloads live points directly at which proxy removes the most hand-written config.
- Custom scripting you carry. Simple header, path, and redirect logic converts directly, and large lookups belong in map files. Only genuinely procedural rules need real scripting, so the volume of that procedural logic is a direct measure of the porting effort.
- Your HA model. The appliance packaged failover for you; on an open proxy you build and test it yourself. How resilient your current pair is sets the bar the replacement has to match rather than assume.
Which proxy fits which estate
Score your estate against the criteria above, then treat these as starting points rather than conclusions. A fleet of classic VIPs with content switching and persistence maps most directly onto HAProxy, the closest open analog to a hardware ADC. Workloads already sitting behind reverse proxies where you want a large module ecosystem fit NGINX, with the caveat that active health checks and cookie persistence live in its Plus tier. Estates heading into Kubernetes lean toward Traefik, whose dynamic service discovery removes most hand-written config, while Envoy suits teams wanting a programmable L7 data plane and service-mesh-grade control. Be honest that none of these replicates every proprietary module one for one: plan a dedicated WAF, an auth proxy, and DNS-based global balancing where you relied on integrated ones. The right proxy falls out of your scores, not out of any proxy’s popularity.
Where proxy swaps come undone
A few errors recur. The first is assuming a one-box open proxy replaces a fully-loaded ADC, then discovering mid-project that the WAF, GSLB, and access modules each need their own replacement. The second is sizing on raw throughput while ignoring TLS handshake rate, which is what actually caps a software proxy under real load. The third is treating vendor failover as a checkbox and skipping the work of building and testing your own active/standby HA. A quieter fourth: not confirming which modules are genuinely in use before cutover, so a clean swing turns into a scramble to reproduce a feature nobody documented.
Validate before you swing traffic
Turn your top candidate into a rehearsal with written acceptance criteria. Stage the new proxy, port a representative set of virtual servers, rules, and certificates, and warm it with test traffic, then validate L7 routing, persistence, and TLS or SNI live before any production traffic moves. Swing the VIP or DNS per service rather than all at once, keep the old ADC configured as immediate fallback through hypercare, and confirm health-check and failover timing matches the baseline the vendor pair gave you. Model the per-instance comparison on your own estate with the calculator, and treat the figures as illustrative until routing, TLS, and failover all pass under a load test versus baseline. Choose the proxy that clears your acceptance bar at the throughput and handshake rate you actually reach, not the one with the longest module list.