---
title: "Discussion on \"Migrating Ingress NGINX to Gateway API Without Downtime: A Practical Guide\" | Hashnode"
description: "Discussion on \"Migrating Ingress NGINX to Gateway API Without Downtime: A Practical Guide\". Choosing an implementation, running Ingress and Gateway API side by side, and getting pod shutdown timing right on AWS, GCP, and Azure"
url: "https://hashnode.com/posts/migrate-ingress-nginx-to-gateway-api/6a6b083ce34048fd11db48a4"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Migrating Ingress NGINX to Gateway API Without Downtime: A Practical Guide](https://pillars.hashnode.dev/migrate-ingress-nginx-to-gateway-api?utm_source=hashnode&utm_medium=feed)

Choosing an implementation, running Ingress and Gateway API side by side, and getting pod shutdown timing right on AWS, GCP, and Azure

Jul 30 · 27 min read · pillars.hashnode.dev  
Updated Aug 6  
Read the article

-   [#kubernetes](https://hashnode.com/tag/kubernetes)
-   [#gateway-api](https://hashnode.com/tag/gateway-api)
-   [#aws](https://hashnode.com/tag/aws)
-   [#traefik](https://hashnode.com/tag/traefik)
-   [#sre](https://hashnode.com/tag/sre)
-   [#kubernetes-networking](https://hashnode.com/tag/kubernetes-networking)
-   [#ingress-nginx](https://hashnode.com/tag/ingress-nginx)

## Written by

[Pillars](https://hashnode.com/@pillars)

@pillars · Dubai, UAE

  
[View profile](https://hashnode.com/@pillars)

Pillars is an outsourced Site Reliability Engineering (SRE) & DevOps partner for businesses where downtime means lost revenue, customers, or trust. We go beyond monitoring — covering reliability across cloud infrastructure, Kubernetes operations, observability, automation, and incident response.

Pillars is an outsourced Site Reliability Engineering (SRE) team with 17+ years of IT experience. We provide 24/7 infrastructure monitoring, incident response with 15-min SLA, and production support for businesses that depend on their online presence and need reliable uptime without building an in-house SRE team. Our engineers work with AWS, GCP, Kubernetes, Terraform, Prometheus, and PagerDuty. We write about real incidents, infrastructure patterns, and reliability engineering practices from the trenches.

## Responses 1

Markdown supported · ⌘↵ to post

[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.