Inventory ingress behavior before replacing the controller
Ingress NGINX retirement requires a behavior inventory. Compare annotations, authentication and backend TLS before choosing a supported replacement controller.
By 
Paul. Architecture and infrastructure
Replacing an ingress controller changes the software that interprets routing configuration. A converted resource file can be accepted by Kubernetes while the application behaves differently. Start a migration with an inventory of observable routing and security behavior, then choose a maintained implementation capable of preserving it. The acceptance condition belongs at the application boundary.
Looking back from November 2026, the 11 November 2025 retirement announcement gave community Ingress NGINX best-effort maintenance until March 2026. It said existing deployments would continue working and installation artifacts would remain available after retirement. That was a maintenance deadline rather than a scheduled shutdown of everyone's routes. It concerned the Kubernetes community's controller, not the Ingress API or every product using NGINX.
The historical deadline has passed
A fresh primary check matters here. The Kubernetes post dated 30 March 2026, accessed in November 2026, states that Ingress NGINX was retired on 24 March 2026. It says further releases, bug fixes and security updates ceased, while existing deployments continue to function. March 2026 is therefore a past retirement, not a future planning window in this article.
That current confirmation does not inspect a reader's cluster. Identify the actual controller image, chart and responsible maintenance organization before deciding whether the notice applies. Similar names can conceal separate implementations and support arrangements. A route still answering traffic does not establish ongoing maintenance; conversely, the community retirement does not prove that another vendor's controller has the same status.
Record responsibility alongside the dependency. If a platform provider manages the controller, ask which implementation and release it operates and what replacement path it supports. If the application team owns it, include that component in its maintenance inventory. A migration without a named owner can leave both the old and replacement controllers running without clear accountability.
Capture the behavior hidden in annotations
Begin with important hostnames and the user journeys they serve. Record path matching and rewriting, redirects, request-size limits and timeouts where the application depends on them. An annotation is evidence of configuration intent. It does not independently establish that a replacement interprets it the same way, or that the existing controller currently applies it as expected.
Authentication deserves its own boundary check. Identify how an external authentication service receives a request, which headers carry identity and how denial or service failure affects the response. A migration that preserves ordinary successful routing can still accidentally admit a request that should be rejected. Include both permitted and denied cases in the proposed acceptance conditions.
Treat backend TLS separately from the certificate a browser sees. The connection from gateway to application has its own hostname and trust requirements. Record what certificate identity should be accepted, where trust material comes from and what happens when validation fails. Copying a TLS-related field is insufficient evidence that verification remains equivalent.
These are proposed inventory and verification steps. No cluster inspection, authentication exercise or certificate test was performed for this article. The relevant evidence must come from the product's configuration and observed behavior in an appropriate environment. Keep unknown items visible instead of silently treating them as default behavior.
Gateway API defines features; implementations deliver them
The Gateway API 1.4 article published on 6 November 2025 says version 1.4.0 was released on 6 October 2025. The November publication explained an October release. It placed BackendTLSPolicy and GatewayClass status supportedFeatures in the Standard channel, while the HTTPRoute externalAuth filter was experimental. Those different maturity levels matter when evaluating authentication parity.
A specification feature is not a promise that every controller release implements it. Check the candidate implementation's versioned documentation and conformance information against the precise feature needed. A broad claim of Gateway API support may cover basic routing while leaving a specific policy unsupported. Retain the implementation and version with the evidence so it remains reviewable after an upgrade.
Use configuration conversion as a starting point for review. Each old behavior needs a corresponding supported mechanism, an intentional change agreed with the owner, or an unresolved item that blocks the move. This keeps accepted resource syntax from being confused with completed application migration. It also exposes places where custom controller extensions may remain necessary.
A supported Ingress controller may be the smaller move
The strongest counterargument to an immediate Gateway API migration is practical: a maintained alternative Ingress controller may preserve more of the existing operating model with less change. The retirement of one controller does not compel every application to redesign its routing resources at the same time. Another supported implementation deserves evaluation where it fits the requirements.
That alternative still requires behavior checks. Shared Ingress syntax does not make proprietary annotations portable, and similar option names do not establish equivalent authentication or TLS semantics. Compare the total change and maintenance obligation, including extensions and operator familiarity. A smaller move is useful when evidence shows that it is smaller for this application.
Plan traffic transfer and rollback around the same acceptance cases. Establish what would stop the move, who can restore the prior path and how retained configuration stays compatible. A rollback path should be time-bounded by the known maintenance risk of the retired component. It is a recovery option, not a reason to leave the migration unfinished indefinitely.
For software maintenance, ask for a behavior inventory and a replacement recommendation tied to implementation evidence. The proposal should show what stays equivalent, what changes deliberately and which uncertainties prevent traffic transfer. Choose the controller after that comparison can explain the application's routing and security responsibilities.