If you’re running Ingress-NGINX in production, you’ve probably seen the writing on the wall. The retirement was announced back in November 2025, and as of March 2026, it’s happening. The Ingress API isn’t going away overnight, but active development on Ingress-NGINX is done. Time to move.

The good news: SIG Network just shipped Ingress2Gateway 1.0, a migration tool that actually works now.

What Changed in 1.0

Previous versions were barely usable — they supported only three Ingress-NGINX annotations. The 1.0 release bumps that to over 30, covering the stuff people actually use: CORS, backend TLS, regex matching, path rewrites, timeouts, and more.

More importantly, every supported annotation is backed by integration tests running against real controllers in live clusters. They spin up both an Ingress-NGINX controller and multiple Gateway API controllers, apply the same config through both paths, and verify the behavior matches. Not just YAML diffing — actual runtime behavior comparison.

This matters because Ingress-NGINX has plenty of surprising defaults and edge cases that only surface under real traffic. Finding those in staging beats finding them in production.

How It Works

Install it:

brew install ingress2gateway
# or
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

Point it at your cluster or your manifests:

ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml

# or from files
ingress2gateway print --input-file my-ingress.yaml --providers=ingress-nginx > gwapi.yaml

It outputs Gateway API resources (Gateway + HTTPRoute) and, critically, tells you what it couldn’t translate. Unsupported annotations, configuration snippets, things that don’t have a Gateway API equivalent — all surfaced as warnings. This is the part most people underestimate. Migration isn’t just about converting YAML. It’s about understanding what you’ll lose and deciding if you ever needed it.

What to Migrate To

Gateway API is the destination. The question is which implementation to run. Here are the real options:

NGINX Gateway Fabric

If you want to stay in the NGINX ecosystem, NGINX Gateway Fabric is the direct successor. It implements Gateway API natively instead of bolting it on through annotations. Backed by F5, actively maintained. The closest thing to a drop-in replacement if your team already knows NGINX internals.

Envoy Gateway

Envoy Gateway is the reference implementation that SIG Network points to most often. Built on Envoy proxy, which already powers most service meshes. If you’re running Istio or considering it, this is the natural fit. Solid community, fast-moving project.

Traefik

Traefik has supported Gateway API since v3. Good choice if you’re already using it or want something that handles both ingress and middleware concerns (rate limiting, circuit breaking) without extra CRDs. The dashboard is genuinely useful for debugging routing issues.

Cilium Gateway API

If you’re running Cilium as your CNI, it has a built-in Gateway API implementation powered by eBPF. No separate proxy deployment needed — routing happens at the kernel level. Fewer moving parts, better performance, but you’re coupling your CNI and ingress layer.

Kong Gateway

Kong supports Gateway API and brings its plugin ecosystem along. If you need authentication, rate limiting, or transformation at the gateway level and don’t want to build it yourself, Kong’s plugin model is mature.

Istio

Istio was actually one of the first projects to implement Gateway API. If you’re already running a service mesh (or planning to), using Istio as your gateway collapses two infrastructure layers into one. Overkill if you just need ingress, but worth it if you need mTLS, traffic management, and observability anyway.

My Recommendation

For most teams coming from Ingress-NGINX with no strong opinions:

  1. Start with Envoy Gateway or NGINX Gateway Fabric — both are well-documented, have active communities, and handle the common cases well
  2. Run ingress2gateway against your current setup and actually read the warnings
  3. Deploy both side by side — Gateway API resources can coexist with Ingress resources, so you can migrate route by route
  4. Don’t rush — Ingress resources will keep working for a while, but don’t use that as an excuse to never start

The migration is less about the tool and more about understanding what your Ingress-NGINX setup actually does. Half the annotations in most configs are cargo-culted from Stack Overflow and never mattered. This is a good opportunity to clean house.