---
title: "5 Reasons to Switch to the Calico Ingress Gateway (and How to Migrate Smoothly)"
source: "https://www.tigera.io/blog/5-reasons-to-switch-to-the-calico-ingress-gateway-and-how-to-migrate-smoothly/"
description: "Learn the top reasons to migrate to the Calico Ingress Gateway and how it offers a seamless path from Ingress NGINX."
---

[Technical Blog](https://www.tigera.io/category/technical-blog/)

# 5 Reasons to Switch to the Calico Ingress Gateway (and How to Migrate Smoothly)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Nov 24, 2025 • 8 min read

## The End of Ingress NGINX Is Coming. What Comes Next for Production Clusters?

![Ingress NGINX retirement illustration](https://www.tigera.io/app/uploads/2025/12/Blog-image-NGINX-controller-down-300x209.png)

If you’re running Ingress NGINX in production, ingress is no longer a “set it and forget it” part of your platform.

[Ingress NGINX is approaching retirement](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/), and that changes the risk profile of every Kubernetes cluster that depends on it. What was once a familiar, well-supported default is becoming a long-term maintenance decision that platform teams.

For many organizations, this moment forces a bigger question: **Do we keep extending Ingress-based tooling, or do we move to the Kubernetes model that is designed to replace it?**

That model is the **Gateway API.**

The Gateway API introduces a more expressive, standardized, and future-proof way to manage ingress traffic. It separates platform and application responsibilities, reduces vendor-specific configuration, and supports advanced routing and policy use cases without relying on annotations.

For teams migrating off Ingress NGINX, **Calico Ingress Gateway**—a production-hardened, 100 percent upstream distribution of Envoy Gateway—provides a secure and supported path forward. For existing Calico customers, migration can often be handled using available tooling and documentation. For other teams, working with Tigera ensures the transition is safe, supported, and aligned with production requirements.

## Why Ingress NGINX Is No Longer Enough

Ingress NGINX solved an important problem early in Kubernetes adoption, but its design shows its age in modern production environments.

Configuration relies heavily on controller-specific annotations, which makes behavior harder to reason about, harder to standardize, and difficult to port across environments. As deployments grow, annotation sprawl increases operational risk and creates friction between platform teams and application developers.

Ingress also lacks a clean separation of responsibilities. Cluster operators and developers often share the same Ingress resources, increasing the likelihood of misconfiguration and making it harder to enforce consistent policy at scale.

With the Ingress NGINX Controller approaching retirement, these limitations become more than inconveniences. Reduced maintenance and ecosystem support increase long-term risk, especially for organizations running business-critical workloads. Continuing to rely on Ingress NGINX means taking on ownership of that risk yourself.

This post explains why Gateway API is the future of Kubernetes ingress, and why platform teams are choosing Calico Ingress Gateway as their long term solution.

🎥 Looking for guidance on what comes after NGINX Ingress?

These on-demand sessions cover both the **strategy** and the **hands-on migration**to Kubernetes Gateway API using Calico Ingress Gateway.

**① Moving Beyond NGINX: Gateway API & Calico Ingress Gateway**

Learn the safest, future-proof path away from NGINX Ingress using the Kubernetes Gateway API.

[▶ Watch on demand](https://www.tigera.io/event/moving-beyond-nginx-using-kubernetes-gateway-api-based-calico-ingress-gateway/)

**② Calico Demo: Switching from NGINX Ingress to Gateway API**

See a real migration from NGINX Ingress Controller to Calico Ingress Gateway, including security and observability.

[▶ Watch on demand](https://www.tigera.io/event/calico-demo-switching-from-nginx-ingress-controller-to-calico-ingress-gateway/)

## Reason 1: Ingress NGINX Is Being Phased Out and That Creates Platform Risk

Ingress has served the Kubernetes ecosystem well, but it was never designed to support the scale, complexity, and role separation that modern platforms require.

As Ingress NGINX approaches retirement, the challenges that teams have worked around for years become harder to ignore:

- Heavy reliance on controller specific annotations

- Inconsistent behavior across ingress implementations

- Limited extensibility for advanced routing and policy

- Blurred ownership between platform operators and application teams

Over time, these issues increase operational risk. Platform teams are left maintaining fragile configuration patterns while trying to standardize ingress behavior across many services and teams.

With reduced ecosystem support ahead, continuing to rely on Ingress NGINX means accepting long term ownership of that risk. Ingress is no longer just a configuration detail. It is now a platform decision with security, supportability, and operational consequences.

👉 **Ready to make the switch?**Talk to the [Tigera team](https://www.tigera.io/demo/) about your Ingress NGINX transition.

## Reason 2: Gateway API Is the Future of Kubernetes Ingress

The Kubernetes Gateway API was created to address the shortcomings of Ingress and provide a durable foundation for service networking.

Unlike Ingress, Gateway API is built around a clear separation of responsibilities:

- **GatewayClass** defines platform wide behavior

- **Gateway** manages infrastructure and listeners

- **HTTPRoute** and related resources allow application teams to define routing safely

This model reduces friction between teams and enables consistent policy enforcement without sacrificing flexibility.

Gateway API also brings first class support for capabilities that previously required custom annotations, including traffic splitting, header based routing, cross namespace access controls, and multi protocol support. These features are part of the API itself, making configurations easier to reason about, audit, and evolve over time.

Because Gateway API is upstream and vendor neutral, adopting it reduces future migration risk and avoids lock in to controller specific behavior. It is not just an alternative to Ingress. It is the direction Kubernetes is moving for ingress and gateway traffic.

The remaining question is not whether to adopt Gateway API, but which implementation provides the safest and most operationally sound path forward.

## Reason 3: Production Grade Envoy Built for Scale and Reliability

Calico Ingress Gateway is built on Envoy Proxy, one of the most widely adopted and battle tested proxies in modern infrastructure.

By delivering a 100 percent upstream, production hardened distribution of Envoy Gateway, Calico provides:

- High performance Layer 7 traffic handling

- Mature resiliency features such as retries, timeouts, and circuit breaking

- Native observability through Envoy telemetry

- Compatibility with the broader Envoy ecosystem

For teams coming from NGINX, this represents a significant step forward in both capability and consistency. Complex behaviors that once required fragile annotations become explicit, well defined configuration.

Just as important, Calico maintains strict upstream compatibility. This ensures long term stability and avoids the operational risk that comes from forks or proprietary extensions.

👉 [Contact Tigera](https://www.tigera.io/demo/) to see how Calico Ingress Gateway runs Envoy in production

## Reason 4: Built In Security from the Edge to the Pod

Ingress is often the first line of defense for Kubernetes workloads, yet many ingress solutions treat security as an add on rather than a core concern.

Calico Ingress Gateway combines Envoy’s application layer controls with Calico’s proven network security capabilities to deliver end to end protection across Layers 3 through 7.

This includes:

- Web application firewall capabilities

- HTTP request filtering and inspection

- Anomaly detection at the edge

- Deep integration with Calico Network Policy

By unifying ingress security with cluster wide network policy, Calico enables a true zero trust model. Traffic is inspected, controlled, and enforced consistently from the perimeter to individual workloads.

This level of integration is difficult to assemble from standalone components and becomes increasingly valuable as environments grow in size and complexity.

## Reason 5: A Supported Migration Path That Reduces Risk

Migrating from Ingress NGINX does not have to be disruptive.

Gateway API and Calico Ingress Gateway are designed to support incremental adoption. In many environments, teams can run existing ingress controllers alongside a new Gateway API implementation, validate routing behavior, and transition traffic gradually.

For organizations already using Calico, migration can often be handled using available tooling and documentation. For teams new to Calico, working directly with Tigera ensures that migration is planned, tested, and aligned with production requirements.

The goal is not just to replace Ingress NGINX, but to do so in a way that minimizes risk, preserves uptime, and sets a solid foundation for the future.

Already a Calico customer?

You can review the Ingress NGINX to Gateway API migration guide to begin planning your transition.

👉[View the migration guide](https://www.tigera.io/blog/securing-kubernetes-traffic-with-calico-ingress-gateway/#calico-ingress-gateway-migration)

![MIgrate Ingress NGINX Controller to Gateway API with Calico Ingress Gateway](https://www.tigera.io/app/uploads/2025/11/NGINX2CalicoMigration.jpg)Migrate Ingress NGINX Controller to Gateway API with Calico Ingress Gateway

## Make the Ingress Decision with Confidence

Ingress NGINX retirement has turned ingress into a strategic platform decision. Teams need a solution that is supported, secure, and aligned with where Kubernetes is going, not one that requires ongoing workarounds to keep running.

Gateway API provides the future-proof foundation Kubernetes was missing, and Calico Ingress Gateway delivers that foundation using proven, upstream Envoy technology with security built in from the start.

Whether you are already running Calico or evaluating your options for the first time, the path forward does not need to be risky or disruptive. With the right implementation and the right level of support, migrating away from Ingress NGINX can be a controlled and confidence-building step toward a more secure and scalable platform.

### 🚀 Next Steps:

- 👉 **Teams new to Calico:** [Work directly with Tigera](https://www.tigera.io/demo/) to assess your environment and define a supported migration plan.

- 👉 **Already a Calico client:** Easily [review the migration guide](https://docs.tigera.io/calico/latest/networking/ingress-gateway/about-calico-ingress-gateway) and begin planning your transition.

### 📚 Your Guided Reading on NGINX Deprecation

Get up to speed on Ingress NGINX retirement and learn how to migrate confidently. Follow these posts in order for a structured path from awareness to action:

- **Step 1 – Understand the change:** [Ingress NGINX Controller Is Dead — Should You Move to Gateway API?](https://www.tigera.io/blog/ingress-nginx-controller-is-dead-should-you-move-to-gateway-api/)

- **Step 2 – Assess your options:** [Is It Time to Migrate? A Practical Look at Kubernetes Ingress vs Gateway API](https://www.tigera.io/blog/is-it-time-to-migrate-a-practical-look-at-kubernetes-ingress-vs-gateway-api/)

- **Step 3 – Explore migration strategy (this blog!):** [5 Reasons to Switch to the Calico Ingress Gateway and How to Migrate Smoothly](https://www.tigera.io/blog/5-reasons-to-switch-to-the-calico-ingress-gateway-and-how-to-migrate-smoothly/)

- **Step 4 – Deep dive into Calico Ingress Gateway:** [A Detailed Look at the Calico Ingress Gateway](https://www.tigera.io/blog/a-detailed-look-at-the-calico-ingress-gateway/)

- **Step 5 – Understand security implementation:** [Securing Kubernetes Traffic with Calico Ingress Gateway](https://www.tigera.io/blog/securing-kubernetes-traffic-with-calico-ingress-gateway/)

- **Step 6 – Take action:** [Ask for a demo](https://www.tigera.io/demo/)

This reading path ensures you go from understanding the NGINX deprecation to a practical migration plan with confidence.

[NGINX Ingress Controller](https://www.tigera.io/tags/nginx_ingress_controller/)[Calico Ingress Gateway](https://www.tigera.io/tags/calico-ingress-gateway/)[Best Practices](https://www.tigera.io/tags/best-practices/)[How-To](https://www.tigera.io/tags/how-to/)

## Related posts

[![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

#### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 27, 2026

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a...

[Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

[![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

#### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 24, 2026

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms...

[Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

[![VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/app/uploads/2026/08/VM-Migration-What-Happens-to-Your-NSX-Segments-in-Kubernetes.png)](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

#### [VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/)
on Aug 5, 2026

Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to...

[Read more](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=3213 metric#misses=34 metric#hit-ratio=99.0 metric#bytes=1560045 metric#prefetches=0 metric#store-reads=175 metric#store-writes=14 metric#store-hits=169 metric#store-misses=23 metric#sql-queries=30 metric#ms-total=598.33 metric#ms-cache=38.69 metric#ms-cache-avg=0.2058 metric#ms-cache-ratio=6.5 sample#redis-hits=48519197 sample#redis-misses=13756703 sample#redis-hit-ratio=77.9 sample#redis-ops-per-sec=95 sample#redis-evicted-keys=0 sample#redis-used-memory=78537688 sample#redis-used-memory-rss=78962688 sample#redis-memory-fragmentation-ratio=1.0 sample#redis-connected-clients=1 sample#redis-tracking-clients=0 sample#redis-rejected-connections=0 sample#redis-keys=19861 -->
