A specification does not move packets. Apply an HTTPRoute to a cluster with no Gateway controller installed and nothing happens, because Gateway API defines which resources exist rather than running a process that handles traffic [6][7]. That gap never surfaced under Ingress, where "using Kubernetes Ingress" and "using ingress-nginx" were close to the same sentence and the spec mapped almost one-to-one onto the implementation [8]. The retirement notice names no software to install, making the installation choice explicit [2].
The dev.to migration write-up lists five Envoy-based candidates (Envoy Gateway, kgateway, Istio, Contour, Cilium) and three outside that family (Traefik, Kong, NGINX Gateway Fabric), before the cloud providers' own offerings [9]. That is eight named options [10], all claiming Gateway API conformance [9]. A recommendation to migrate to a specification is a recommendation to run a procurement exercise.
Conformance covers less than the badge suggests. Features sit in three tiers: Core, Extended, and Implementation-specific. Core is the minimum every implementation must support, Extended is recommended but optional, and a conformance claim requires Core alone [11]. The capabilities that get a service to production tend to sit higher, with auth, rate limiting and circuit breaking commonly landing in Extended or Implementation-specific [12]. Envoy Gateway spells authorization as a SecurityPolicy CRD and Istio as AuthorizationPolicy, and writing either resource is where the lock-in begins [13]. Conformance buys portable routing; the policy layer stays vendor-specific [14].
That makes the article's comparison a claim about one particular cluster. NGINX Gateway Fabric places highest on migration ease because it shares the same nginx data plane, while Istio places lower because installing the entire service mesh stack is a prerequisite, and Istio is the only one of the four compared that has mesh capability at all [16][17]. Migration ease is a measure of distance from a config. The config being measured is the ingress-nginx annotation set the author sorted into three categories with before/after manifests [19]. For that ranking to transfer, your annotations have to be the ones that map onto nginx-shaped extensions, and your production traffic features have to be inside the tier the implementation actually covers. Note also that the write-up states these rankings in relative terms rather than publishing a scale.
The deadline behaves differently from an upgrade deadline. In March 2026 the Helm charts and container images stay usable and existing deployments keep serving [5]. What ends is the patch stream, so the real date is set by whoever files the next vulnerability against a component sitting in every inbound request path, and the fix does not arrive [1][5].
The failure mode that produced all of this was maintainer supply: for years one or two people kept ingress-nginx running in their spare time [3], and InGate, the planned successor built with the Gateway API community, was retired after no contributors came forward [4]. If one column in the evaluation deserves extra weight, it is that one. The same article puts Envoy Gateway, at CNCF incubating, and Istio, at CNCF graduated, ahead on development momentum [18]. Governance is the attribute that ingress-nginx's ending actually measured.
