Ingress-NGINX is Phasing Out: How to Migrate Smoothly by March 2026

The Ingress-NGINX Controller maintained by the Kubernetes community (repository kubernetes/ingress-nginx) will officially reach its end of life in March 2026. After this date, there will be no more releases, bug fixes, or security patches. Existing installations won’t “break” immediately, but they will continue uncontrolled: new CVEs, new Kubernetes versions, new incompatibilities – without upstream fixes.

Important: This does not affect NGINX as a web server. It concerns the Kubernetes controller from the community (ingress-nginx), not the NGINX project.

The good news: You don’t have to switch to an entirely new configuration world in one step. There are migrations that feel like a “soft landing” – including the continued use of many classic Ingress-NGINX annotations.

Why This Topic Should Be on Your Agenda Now

Ingress is an edge and security component. Once there are no more patches, “it works” becomes a risk that becomes unpleasantly visible at the latest during:

• Security audits / ISO 27001 / SOC 2
• Customer requirements (Supply Chain, Patch Management)
• Regulations (depending on the industry)
• Kubernetes upgrades

Kubernetes itself puts it very directly: After March 2026, no further updates to address newly discovered security vulnerabilities.

What Exactly Is Ending – and What Is Not?

Ending: kubernetes/ingress-nginx

• Best-effort maintenance until March 2026
• After that: read-only, no releases, no fixes

Not Ending: Kubernetes Ingress as an API

You can continue to use Ingress resources – just not with the community controller if you want upstream maintenance. (And prospectively, the focus is shifting towards the Gateway API.)

Two Practical Migration Paths (Plus a Strategic Option)

At its core, you have three sensible directions:

1. Traefik: Migration “on the side” – through annotation compatibility and parallel operation
2. F5/NGINX Ingress Controller: “Close to the NGINX ecosystem”, commercially driven, politically easy to sell for many enterprises
3. Gateway API: Strategically cleaner target state – but rarely the fastest “EOL exit”

Decision Logic in a Table

Traefik explicitly positions the migration so that existing Ingress resources continue to run without changes because the Kubernetes Ingress NGINX Provider translates NGINX annotations into Traefik configuration. F5 describes its own Ingress Controller as an NGINX-based implementation with annotation/ConfigMap extensions.

The “Soft” Path: Zero-Downtime Migration from Ingress-NGINX to Traefik

Traefik has prepared the topic very operationally: Install Traefik alongside NGINX, gradually shift traffic, remove NGINX – without downtime.

Prerequisite: Traefik Version and Provider

The Kubernetes Ingress NGINX Provider requires Traefik v3.6.2 or newer. The provider documentation also shows the key parameters (IngressClass, controllerClass, namespaces, etc.).

Migration Principle in One Sentence

You operate two controllers in parallel that “see” the same Ingress resources. Then you shift traffic in a controlled manner – via DNS or external load balancer – and remove NGINX.

Step-by-Step: Parallel Operation, Verification, Traffic Shift, Shutdown

1) Install Traefik in Parallel (Without Touching NGINX)

Traefik is rolled out additionally – the crucial switch is the provider:

helm repo add traefik https://traefik.github.io/charts helm repo update helm upgrade --install traefik traefik/traefik \ --namespace traefik --create-namespace \ --set providers.kubernetesIngressNginx.enabled=true

This exact activation (providers.kubernetesIngressNginx.enabled=true) is the core for Traefik to understand your existing NGINX Ingresses.

Best Practice: Use IngressClass control instead of scanning “everything in the cluster”. The provider specifically supports ingressClass/controllerClass configuration.

2) Verify That Traefik Serves Your Ingresses Correctly

Before changing DNS, test Traefik directly via its load balancer address (without redirecting user traffic). Traefik recommends tests with curl --connect-to to maintain hostname/SNI.

Pay special attention to:

• Redirects (HTTP→HTTPS)
• CORS headers, timeouts, body size behavior
• Session affinity / cookie stickiness, if used
• gRPC/WebSockets, if in use

3) Gradually Shift Traffic (Two Practical Variants)

Option A: DNS-Based Migration (Simple, but Plan TTL Realistically)

Add Traefik to DNS (round-robin), observe behavior, then remove NGINX from DNS.

Traefik points out a real issue: Some providers/ISPs do not reliably respect TTL – so keep NGINX running for another 24–48 hours after removing it from DNS.

Option B: External Load Balancer with Weighting (Controlled Rollout)

If you already have a Global LB / Cloud LB / Traffic Steering in front, you can shift weighted (10% → 50% → 90% → 100%). Traefik outlines this as a more controlled alternative.

4) Cleanly Remove NGINX – But Retain IngressClass

A frequently underestimated point: If Traefik observes your existing Ingress resources via the NGINX IngressClass, the corresponding IngressClass must not simply disappear. Traefik explicitly describes this as a necessary step: Preserve IngressClass, then uninstall.

Additionally: Remove admission webhooks to prevent Ingress changes from being blocked later (when NGINX is no longer there).

TLS During Migration: The Classic That Slows Down Teams

If Traefik is not yet “public” in DNS during the verification phase, Let’s Encrypt HTTP-01 typically does not work. Traefik suggests pragmatic ways:

• Continue using existing certificates via spec.tls.secretName (cert-manager, external PKI)
• Alternatively, configure ACME DNS-01 Challenge for Traefik
• Do not “green test” with curl -k – it masks real issues

Practical Tip: If you use cert-manager, this is the most pleasant path: Both controllers access the same TLS secrets.

What Does “Annotation Compatibility” Mean in Reality?

Traefik does not say “we are NGINX”, but: We translate NGINX annotations into Traefik configuration. This is invaluable for migration, but you should be honest in the blog post:

• There is a list of supported annotations and behavioral differences.
• Certain “special tricks” from ingress-nginx (e.g., very individual snippets/template hacks) are naturally harder to map 1:1.

If you bring this transparency, the article does not seem like marketing, but like platform experience.

Alternative: Stay Within the NGINX Ecosystem – with the F5/NGINX Ingress Controller

For some organizations, “controller change” is politically difficult in itself. Then the obvious option is: move away from community ingress-nginx, to the officially maintained NGINX Ingress Controller from F5/NGINX.

NGINX documents the controller as an Ingress implementation with extensions via annotations and ConfigMap and promotes it as a long-term alternative after retirement.

Typical Positioning for Decision Makers:

• less “tooling culture change” (NGINX remains in the stack narrative)
• clear vendor owner for lifecycle & support
• but: product/license questions should be clarified early

Strategic Target State: Gateway API (Modernize, but Not as an EOL Emergency Project)

The Gateway API is for many platform teams the cleaner long-term abstraction (role model, delegation, standardization). But: EOL migration ≠ architecture modernization in one sprint.

A proven approach in companies:

1. Remove EOL risk (change controller, stabilize operation)
2. Observe & standardize (dashboards, logs, SLOs, policies)
3. Gradually switch to Gateway API, where it adds value (e.g., delegate teams/namespaces, central policy, multi-tenant)

This keeps the migration deliverable without turning it into a “platform revolution”.

Migration Checklist for Production

Conclusion: Migration Is Less a Tool Problem Than a Risk and Operations Problem

Ingress-NGINX ends in March 2026 – this is not a drama, but a clear lifecycle cut. If you want to get out quickly and pragmatically, Traefik with the Ingress-NGINX Provider is a very attractive path because it largely carries over existing Ingress manifests and annotations and describes the parallel operation cleanly. If you need to stay in the NGINX narrative (organization, compliance, support), the F5/NGINX Ingress Controller is the obvious alternative.

The real success curve does not come from “installing a new controller”, but from:

• controlled traffic shift
• reproducible tests
• clean TLS strategy
• observability before the transition