The Ingress NGINX project is winding down. For many organizations, this means planning a migration for critical infrastructure.
While the HAProxy Kubernetes Ingress Controller is the natural successor for these workloads, a "rip and replace" strategy isn’t always viable. You might have complex configurations, customized annotations, or deployment freezes that make a sudden switch risky.
There's a lower-risk path: Place HAProxy in front of your existing Ingress NGINX deployment.
By leveraging the HAProxy One platform approach, you can bridge your legacy Ingress NGINX setup and your future infrastructure without downtime. This buys you time while adding immediate security and observability benefits.
Taking a "shield and shift" approach
This strategy mirrors the architecture we've previously recommended for vulnerability protection (like CitrixBleed). Deploy HAProxy Enterprise as your edge layer, sitting in front of your current Ingress NGINX controller. You wrap your existing ingress with enterprise-grade security and visibility, without touching your working NGINX configurations.
This approach leverages a unified data plane. HAProxy Enterprise at the edge creates a protective layer that's consistent with your future HAProxy Kubernetes Ingress Controller. The HAProxy One platform uses the same high-performance engine at the edge and within Kubernetes, unlike disparate solutions that force you to maintain different configurations and skill sets.
The security policies, rate limits, and observability metrics you configure at the edge today translate directly to your Kubernetes clusters tomorrow. No relearning. No translation.
1. Immediate security hardening
Legacy software becomes a security liability over time. An HAProxy edge layer acts as a security filter. You can apply rate limiting, bot management, and enterprise WAF rules to sanitize traffic before it reaches the deprecated controller.
2. Better visibility into your traffic
Migration anxiety comes from blindness. HAProxy Fusion unifies the management of your external edge gateways and internal Kubernetes controllers.
HAProxy Fusion provides a single pane of glass for all traffic flows—even those heading to your legacy Ingress NGINX controller. It allows you to visualize service dependencies and automate the routing changes required for the migration, turning a manual, error-prone switchover into a managed workflow.
3. Migrate one service at a time
This is the operational advantage. Once HAProxy Enterprise handles your ingress traffic, you don't need to cut everything over at once.
Configure HAProxy Enterprise to route most traffic to your existing Ingress NGINX setup. Then carve out specific paths, domains, or services to route to a new, parallel HAProxy Kubernetes Ingress Controller deployment.
Migrate service by service, pod by pod, or region by region. Test a new configuration in production with real traffic. If it works, great. If not, revert the routing without redeploying your cluster.
Configuration example
The setup is straightforward. Configure your edge HAProxy Enterprise to listen on your public IP address and forward traffic to your Ingress NGINX service's internal IP address.
Here's a simplified routing configuration:
| #------------ Global and defaults ------------# | |
| # Set performance tuning and security logging | |
| # [Placeholder: Global/defaults for buffer sizes, timeouts] | |
| #----- Frontend: accept and route traffic -----# | |
| frontend main_ingress | |
| bind :443 ssl crt /etc/haproxy/certs/ | |
| mode http | |
| # Apply security policies at the edge | |
| # [Placeholder: ACLs for WAF/bot protection] | |
| # Migration routing logic | |
| # Send updated services to new HAProxy Ingress Controller | |
| use_backend new_haproxy_ingress if { hdr(host) -i new-app.example.com } | |
| # Everything else goes to legacy Ingress NGINX | |
| default_backend legacy_nginx_ingress | |
| #----------- Backends: old and new -----------# | |
| backend legacy_nginx_ingress | |
| mode http | |
| # Points to existing Ingress NGINX LoadBalancer IP or Service | |
| server nginx_lb 192.168.1.50:80 check | |
| backend new_haproxy_ingress | |
| mode http | |
| # Points to new HAProxy Kubernetes Ingress Controller | |
| server haproxy_kic 192.168.1.51:80 check |
Looking ahead: Gateway API support
This architecture isn't just a stopgap. It's infrastructure that scales with you.
As Kubernetes networking moves toward the Gateway API, a flexible edge routing layer lets you adopt new standards at your own pace. We're developing HAProxy Unified Gateway to support both Ingress and Gateway API standards—giving you a single platform that evolves with the ecosystem.
Stabilize your environment now. Migrate on your timeline. The configuration knowledge you build today (the routing logic, security policies, and operational patterns) carries forward. You're not buying time to delay a painful migration. You're building the foundation for your next-generation infrastructure, one service at a time.
Getting help
You don't have to migrate alone:
Community Support: Join our Slack to discuss migration strategies with other users
Documentation: We're releasing migration tutorials and annotation mapping guides soon
Enterprise Support: If you need hands-on help for critical workloads, our support and sales teams can help you architect a safe transition with HAProxy Fusion and HAProxy Enterprise
