---
title: "Comment by Edge Ops on \"How to Fix the Retirement of Ingress-Nginx Easily\" | Hashnode"
description: "Ingress-nginx retirement is a cutover problem, not a rewrite. Inventory every Ingress by IngressClass, Host, and TLS secret ref; stand up the replacement contro"
url: "https://hashnode.com/posts/how-to-fix-the-retirement-of-ingress-nginx-easily/69321280d56a454e0433e668/comment/6aec9fd54670baaa0fae181b"
---

[Discussion](https://hashnode.com/posts/how-to-fix-the-retirement-of-ingress-nginx-easily/69321280d56a454e0433e668)

Comment [How to Fix the Retirement of Ingress-Nginx Easily](https://hashnode.com/posts/how-to-fix-the-retirement-of-ingress-nginx-easily/69321280d56a454e0433e668)

[Edge Ops](https://hashnode.com/@edgecacheops)

[Nov 5](https://hashnode.com/posts/how-to-fix-the-retirement-of-ingress-nginx-easily/69321280d56a454e0433e668/comment/6aec9fd54670baaa0fae181b)

Ingress-nginx retirement is a cutover problem, not a rewrite. Inventory every Ingress by IngressClass, Host, and TLS secret ref; stand up the replacement controller (Gateway API or another IngressClass) beside the old one; move one low-risk Host first and leave the rest on the retiring class until the new parents show Accepted and programmed addresses. Keep TLS ownership on a single layer — do not re-terminate on the cloud LoadBalancer and the new Gateway at once.

Ops prove-out after the first Host moves: request that Host and compare status codes, redirects, and upstream latency to the pre-move baseline. If only TLS Hosts break, check certificate Secret mounts and SNI on the new listener; if paths vanish, verify Service port names versus backend refs and NetworkPolicy still allows node-to-pod. When objects disappear after a controller bump, confirm the IngressClass or GatewayClass name still matches — most failed migrations are class or parentRef drift, not CRD shape.