Project Name
Migrated a Deprecated NGINX Ingress to Kong With Zero Downtime
Our client is a mid-market technology company headquartered in North America, specialising in broadband network analytics and subscriber data management.
Serving internet service providers and telecommunications operators across the region, the company processes high volumes of real-time network telemetry through a Kubernetes-native microservices architecture.
With a growing product suite and increasing API traffic from ISP customers, the company required a modern, supported, and extensible ingress layer to sustain its growth trajectory and meet the enterprise SLA commitments its customers expected.
A deprecated ingress controller in production is not a maintenance backlog item, but it is a live security exposure with a customer-facing blast radius.
- Deprecated Ingress Controller in Production: The existing NGINX Ingress Controller had reached end-of-life, meaning no further security patches, bug fixes, or community support, leaving every production API route exposed to unpatched vulnerabilities with no remediation path on the existing setup.
- Complex Routing Rule Migration Risk: Dozens of ingress rules governing path-based routing, host-based routing, TLS termination, and header manipulation needed to be migrated without altering any existing API consumer behaviour; a single missed rule meant silent traffic drops.
- No Centralised API Gateway Capabilities: NGINX Ingress provided basic routing but lacked built-in rate limiting, authentication plugins, request transformation, and observability, forcing the team to bolt on separate tools for each capability and manage them independently.
- Zero Tolerance for Service Disruption: The platform served real-time analytics to ISP customers with strict SLA requirements. Any migration-related downtime would directly impact customer trust and contractual obligations with no acceptable recovery window.
- Limited Internal Kubernetes Networking Expertise: The client's engineering team had deep application-layer expertise but limited experience with Kubernetes ingress controller internals, CRD-based configuration, and traffic shifting strategies at the cluster level.
- No Rollback Plan for Ingress Cutover: A failed migration with no tested rollback mechanism risked extended outage across all production services. The team needed a parallel-run strategy that allowed instant revert if Kong introduced any regressions.
Ksolves, an AI-first DevOps consulting company, designed and executed a phased migration from the deprecated NGINX Ingress Controller to Kong Ingress Controller, operating both controllers in parallel throughout the transition window. The governing principle was zero-disruption continuity: every routing rule was audited, translated to Kong CRD equivalents, validated in staging, and traffic-shifted in production with instant rollback capability at every stage.
- Ingress Rule Audit and Mapping: Every existing NGINX ingress annotation, path rule, TLS secret reference, and header-based routing configuration was catalogued and mapped to equivalent Kong Ingress Controller CRD definitions. This ensured complete functional parity before a single byte of production traffic moved.
- Parallel Ingress Controller Deployment: Kong Ingress Controller was deployed alongside the existing NGINX controller using IngressClass isolation, allowing both controllers to coexist in the same cluster without conflict. This enabled service-by-service traffic shifting with instant rollback capability throughout the migration window.
- Staged Traffic Migration With Validation Gates: Services were migrated in priority-ordered batches, each passing through automated smoke tests confirming response codes, latency baselines, and header correctness before production traffic was shifted to Kong.
- Kong Plugin Enablement: Post-migration, Ksolves configured Kong's native rate-limiting, key-auth, and Prometheus plugins. This replaced the patchwork of sidecar tools previously bolted onto NGINX, giving the team a single, unified control plane for all API governance.
- Runbook and Knowledge Transfer: A comprehensive operational runbook was delivered covering Kong CRD management, plugin configuration, TLS rotation, and troubleshooting workflows. This enabled the client's team to self-manage the ingress layer independently from day one post-engagement.
Technology Stack
| Category | Technology |
|---|---|
| API Gateway | Kong Gateway (OSS) |
| Orchestration | Kubernetes |
| Configuration | Kong Ingress Controller (KIC) |
| Legacy Ingress | NGINX Ingress Controller |
| Observability | Prometheus + Grafana |
Every production API route migrated, every routing rule preserved, and every ISP customer was unaware that the switch ever happened.
- Zero-Downtime Migration Across Production Services: Phased traffic shifting and parallel controllers enabled a seamless migration with zero service disruption.
- 100% Routing Rule Parity Achieved: All 40+ routing rules were successfully mapped, validated, and tested before production cutover.
- API Governance Unified Into One Platform: Kong consolidated rate limiting, authentication, and monitoring into a single centralized control plane.
- Ingress Incident Detection Reduced to Under 5 Minutes: Prometheus and Grafana integrations significantly improved ingress visibility and response times.
- Rapid Team Self-Sufficiency: The client team independently managed ingress changes within two weeks after migration and KT sessions.
“The migration was seamless. Our customers never noticed the switch, and we gained capabilities we’d been patching together for years.”
– VP of Engineering, Networking Company
Running a deprecated ingress controller in production is not a technical debt conversation; it is a live security exposure sitting directly in front of every customer-facing API. This client had no safe path to fix it without risking the entire platform going offline in the process. Ksolves, as an AI-first DevOps consulting company, removed that constraint entirely. Both controllers ran in parallel, traffic moved in validated batches, and every ISP customer stayed connected throughout. By the time NGINX was decommissioned, the team had a fully supported Kong control plane managing all routing, TLS, rate limiting, and authentication, consolidated from four separate tools into one. The deprecated liability is gone, the security posture is restored, and with Kong’s extensible plugin architecture in place, the client is positioned to adopt mutual TLS, OpenID Connect, and canary traffic management as their platform grows.
Still Running a Deprecated Ingress Controller in Production? Let’s Fix That Before Your Next Security Audit!
