From Kemp LoadMaster to HAProxy

Kemp LoadMaster (now under Progress) is a solid ADC, but the per-instance licensing plus annual support, with advanced features like WAF and GSLB gated behind Enterprise tiers, gets expensive as you scale instances and throughput. HAProxy is the open-source workhorse of L4/L7 load balancing: extremely fast, battle-tested, and free, with a commercial edition available if you want a vendor and a GUI. For straightforward L4/L7 balancing, TLS termination, and health-checked backends, this is a clean migration. The effort is in translating Kemp’s Virtual Service model into HAProxy’s config and in replacing any Enterprise-tier features you actually depend on.

Map the model: Virtual Service to frontend/backend

Kemp organises around Virtual Services (a VIP plus its real servers and rules). HAProxy splits that into frontends (what listens) and backends (the pool of real servers), tied together by ACLs:

• VIP / listener becomes a frontend with a bind (IP:port, plus TLS).
• Real servers become a backend with server lines.
• Scheduling method (round robin, least connections) maps directly to HAProxy’s balance algorithms.
• Health checks become option httpchk / check directives, port these carefully, a wrong check silently drains a pool.
• Content rules / SubVS map to HAProxy ACLs and use_backend rules.

Rebuilding content rules and SubVS routing

Kemp’s SubVS model, where one Virtual Service fans out to several sub-services by content, is the piece that needs the most deliberate translation. In HAProxy a SubVS becomes a decision made in the frontend: you write ACLs that match on host header, path, or another request attribute, then route with use_backend ... if to the backend that stands in for each sub-service. Host and path routing that felt built-in on Kemp is now explicit config you can read and version.

The thing to watch is evaluation order. Kemp applied content rules in an order that was partly implicit in the UI, while HAProxy evaluates ACLs and use_backend rules in the order you write them, with default_backend as the fallback. Rebuild the routing tree deliberately and test each branch rather than assuming the old precedence carries over. For large lookups, a customer-to-pool table or many host mappings, use a map file resolved with something like req.hdr(host),map(/etc/haproxy/hosts.map) instead of a long ACL chain, which keeps the config maintainable as VIP count grows.

TLS, health checks, and persistence in one pass

Treat certificates, checks, and persistence as a single hardening pass per Virtual Service. Move each certificate as a concatenated PEM of cert, key, and chain, reference it with bind ... ssl crt, and set an explicit TLS policy through ssl-default-bind-ciphers and a minimum version rather than inheriting whatever Kemp shipped. Validate the served chain from an external client so a missing intermediate does not slip past you.

Health checks are make-or-break here, as noted below, so port them precisely: option httpchk with http-check expect for HTTP services, the default connect check for raw TCP, and inter, fall, and rise tuned to the Kemp interval and retry counts. Persistence maps to a stick-table keyed on src for source-IP affinity or to cookie-based persistence for HTTP, and you match the method each application actually needs. Doing all three together per VIP means you validate a service end to end before moving on rather than discovering a gap after cutover.

Handle the parts that need design

• TLS termination: move certificates to HAProxy (bind ... ssl crt), and decide on TLS policy (ciphers, versions, OCSP). This is also a good moment to centralise certs with something like cert-manager or an internal CA workflow.
• Persistence: Kemp’s persistence options map to HAProxy stick-table / cookie-based persistence, match the method your apps actually need (source IP vs cookie).
• WAF: if you used Kemp’s WAF, HAProxy does not include one in the same way, pair it with a dedicated WAF (for example a ModSecurity/Coraza engine) or front it with one. Plan this explicitly rather than dropping the capability.
• GSLB / global balancing: Kemp GSLB has no built-in HAProxy equivalent, use DNS-based GSLB or an external service for multi-site.

The per-VIP cutover sequence

1. Stand up HAProxy (HA pair with keepalived/VRRP for the VIP, do not run a single node for production traffic).
2. Recreate one Virtual Service as a frontend/backend, with its health checks, TLS, and persistence.
3. Test in parallel, point a test hostname or a small slice of traffic at the HAProxy VIP and compare behaviour, especially health-check accuracy and persistence.
4. Cut over that VIP (DNS or IP move) in a window, keep Kemp ready for rollback.
5. Migrate VIP by VIP, leaving the trickiest (WAF/GSLB-dependent) services until their replacements are in place.

The details that bite

• Health checks are make-or-break. A mistranslated check marks healthy servers down or sick servers up, validate every one against the Kemp behaviour.
• HA is yours to build. Kemp’s HA was packaged; with HAProxy you configure keepalived/VRRP and test failover before go-live.
• Observability. Wire up the HAProxy stats/Prometheus exporter so you are not flying blind after leaving Kemp’s UI.
• Config management. Many VIPs means treating HAProxy config as code (templated, version-controlled) rather than hand-edited per box.

Making the call

Kemp LoadMaster to HAProxy removes per-instance and Enterprise-tier licensing in exchange for configuring and operating HAProxy yourself. Translate Virtual Services into frontends/backends, port health checks and persistence carefully, and design replacements for WAF and GSLB if you used them. Build real HA with keepalived, cut over one VIP at a time with Kemp on standby, and manage the config as code. Model the removed per-instance and support cost against HAProxy infrastructure (or the commercial edition) in the calculator above.