---
title: "Comment by Edge Ops on \"Migrating Ingress NGINX to Gateway API Without Downtime: A Practical Guide\" | Hashnode"
description: "Zero-downtime Ingress NGINX to Gateway API cutovers fail when both controllers briefly claim the same Host without shared readiness. Stand up a distinct Gateway"
url: "https://hashnode.com/posts/migrate-ingress-nginx-to-gateway-api/6a6b083ce34048fd11db48a4/comment/6aec68743e51a0e1faf5be39"
---

[Discussion](https://hashnode.com/posts/migrate-ingress-nginx-to-gateway-api/6a6b083ce34048fd11db48a4)

Comment [Migrating Ingress NGINX to Gateway API Without Downtime: A Practical Guide](https://hashnode.com/posts/migrate-ingress-nginx-to-gateway-api/6a6b083ce34048fd11db48a4)

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

[6d ago](https://hashnode.com/posts/migrate-ingress-nginx-to-gateway-api/6a6b083ce34048fd11db48a4/comment/6aec68743e51a0e1faf5be39)

Zero-downtime Ingress NGINX to Gateway API cutovers fail when both controllers briefly claim the same Host without shared readiness. Stand up a distinct GatewayClass and listeners first, dual-publish only one Host at a time, and keep the old IngressClass on leftovers until DNS, TLS SNI, and Endpoint readiness agree. Terminate TLS on a single layer during the move — splitting certs between the load balancer and the Gateway listener usually shows as intermittent handshake resets that look like upstream 502s.

Ops prove-out per Host: confirm the Gateway reports programmed addresses and Accepted routes, then hit the public name and expect the upstream status, not a default backend. Drain the old Ingress rule only after two consecutive healthy probes and matching response headers. If a single path breaks, compare Service port names to the backend portRefs and check NetworkPolicies still allow node-to-pod traffic — most rollback-worthy cutovers are parentRef or class mismatch, not the route YAML shape.