Ingress NGINX Migration Services: Zero Downtime, Production-Proven

As a Kubernetes Certified Service Provider and AWS Advanced Tier Partner, Pelotech handles the entire migration from Ingress NGINX, from controller evaluation and annotation auditing to zero-downtime cutover, so your engineering team stays focused on the current roadmap.
Our senior engineers have done this exact migration in production, on AWS, with zero dropped requests to prove it.
Schedule a free migration consultation call
Trusted by industry leaders who want to avoid downtimes
A company logo
A company logo
The current situation

Why migrate from Ingress NGINX Today?

Security & Compliance risk

Ingress NGINX is end of life. This means there are no incoming security patches, leaving an unpatched vulnerability in your production traffic path. For regulated businesses, this creates SOC 2, PCI-DSS, HIPAA, or ISO 27001 compliance exposure.

Architectural dead end

The Ingress API is no longer being developed, and will have no further changes or updates made to it. Every month you remain on the Ingress API, you are running infrastructure with no roadmap, no new capabilities, and a widening gap between where your architecture is and where it needs to be.

Operational
reliability problems

Teams already on Ingress NGINX are reporting recurring reliability issues that users feel:

Every time your team updates a routing rule, active users get dropped

Real-time features like live chat, video streaming, and notifications cut out during routine configuration changes

As traffic grows, the system struggles to keep up.

Where you currently are

The migration needs to happen and you know it. What stands in the way is bandwidth. Preparation involves auditing annotations, evaluating controllers, testing in non-production, and setting up weighted DNS, and a team without dedicated SRE or DevOps capacity tends to lose sprint cycles and deprioritize features to get through it.

The production cutover carries the most exposure, because failure points that go unidentified there are the ones that cause downtime and disrupt your users.

Migration Challenges

What goes wrong with
typical NGINX ingress migrations?

Teams typically attempt this migration in one
of two ways and face unexpected issues either way

High risk

Medium risk

The standard cutover

The typical strategy is to stand up the new gateway, confirm it is responding, and remove the old Ingress. The problem is that DNS does not update immediately when you make the switch, leaving the TTL values on your existing records. This means some users will still resolve to the old address after the old Ingress is gone, causing silent failures that users feel. For a business handling live transactions, customer requests, or real-time features, this can lead to lost revenue, eroded user trust, and a long support queue.

DIY with migration tooling

Tools like ing-switch and ingress2gateway scan your cluster and generate Gateway API manifests, providing a useful starting point for understanding the scope of the migration. But because the output is not a deployment, every manifest needs to be reviewed, validated, and in many cases completely redesigned before it is production-safe. That work still falls on your engineering team and competes with every other priority already on the roadmap.

Recommended

What actually works?

Run both systems simultaneously under the same hostname with weighted DNS records, gradually shifting traffic until the transition is verified to be clean. If anything looks wrong, a single weight swap rolls everything back instantly, preventing downtime and negative impacts on customers.

We’ve tried it and proven it works.

Hire a Team to Handle Your Migration From Ingress NGINX Without Downtime

Unlike most migration vendors that take the brief, build what they are asked, and leave production issues for you to handle, Pelotech’s engineers are hands-on strategic partners. Migration is not something we’ve built theoretical frameworks for; we built a migration approach in our internal GitOps infrastructure, verified it works, and then ran it for AWS Kubernetes customers, with zero dropped requests.

Schedule a free migration consultation call.
Kubernetes Expertise

Kubernetes Certified Service Provider for Migrations With Zero Downtime

Businesses require the highest standards of security and reliability from the partners they trust with their production infrastructure. Pelotech's KCSP certification means our engineers have been independently verified against technical depth, security practices, and production readiness by the same organization that governs the Kubernetes ecosystem itself.

The team you evaluate is the team you get

The senior engineers you see in the evaluation and the sales call are the same ones who run your migration and are accountable for the result.

Senior engineers only

Engineers with 10 to 20 years of experience handle each migration, rather than simply reviewing outputs from junior resources at the end.

KCSP and AWS Advanced Tier Partner

Independent verification that the engineers handling your migration meet the highest technical bar in the Kubernetes ecosystem.

Practical migration experience

We’ve run the same migration on our own infrastructure first, worked through every failure mode, and implemented the same approach for customers, with zero dropped requests.

Case Studies

Modernization Outcomes, Not Modernization Plans

“The difference between working with Pelotech and other consulting teams is like night and day. Their engineers show up to every meeting with a clear agenda and a defined set of priorities. They drive the initiative forward instead of waiting for direction, which has been incredibly refreshing.”

Kaine Robertson
Driving Innovation & Growth at VendNovation

“I'd have absolutely no reservations recommending Pelotech to anyone who needs Cloud migration or just Cloud-native technology solutions. They're a brilliant team, and they've delivered above and beyond what we needed them to deliver.”

Matt Homes
Head of IT, STEM Learning

"We give Pelotech the highest recommendation possible. We have worked with Joachim and his team, and have found him and the team to be of the highest integrity, honesty, quality and speed. We would not have the product, or quality of product, that is used by the USAF, Joint Forces and commercial companies, if not for their dedicated, excellent work. We have used many developers and engineers over 30 years, and they are the best we have ever seen or used.
This may sound over-the-top, but is our genuine appreciation and acknowledgement of them as people and providers."

Jonathan Josephson
Founder & CTO at Quantum Interface
The Challenge
Why they chose Pelotech
The Solution
The Result

The Challenge

A tech-forward company running Kubernetes on AWS needed to migrate off Ingress NGINX before the EOL deadline. Their cluster ran multiple namespaces, relied on NGINX annotations for mTLS and request buffering, and carried the DNS sequencing risk that causes most migrations to drop requests during cutover.

Read the full story

Why they chose Pelotech

Their engineering team had the capability to run it internally. They did not have the bandwidth to absorb a two- to three-month preparation process without paying the price for the roadmap. They needed a team that had already solved the problems their migration would surface — not one that would discover them alongside them in production.

Read the full story

The Solution

Pelotech completed a full annotation audit, first configured Envoy Gateway in a non-production environment, and then executed a weighted DNS cutover via ExternalDNS and AWS Route 53. Both systems ran simultaneously under the same hostname throughout the transition.

Read the full story

The Result

Zero failed requests, verified through continuous polling throughout the entire cutover.

Read the full story
Our Process

Your Migration Shouldn’t Derail Your Product Roadmap

Our engineers, who have already resolved every failure point, can help you implement it without your users noticing any change.

Schedule your free migration consultation call

Step 1

Cluster assessment

We review your existing annotation inventory, namespace model, AWS configuration, and current Ingress resources before we scope anything. While that’s on, we identify which annotations map cleanly to the Gateway API, which require redesign, and where the multi-namespace complexity lives in your specific environment. The engagement is built from what we find, not from a standard template.

Step 2

Controller validation and environment setup

Before anything touches your production cluster, we configure and validate Envoy Gateway in a non-production environment that mirrors your actual setup. We test against your specific requirements and confirm that all production requirements are met before the migration plan is finalized.

Step 3

Annotation mapping and Gateway API translation

Every Ingress NGINX annotation currently in use gets mapped, categorized, and re-expressed in Gateway API resources. Annotations that translate directly are handled systematically. Annotations that require redesign are resolved before the cutover window.

Step 4

Zero-downtime cutover

The old Ingress and the new HTTPRoute run simultaneously under the same hostname, with weighted DNS records controlling traffic distribution between them. We start with all production traffic on the old Ingress, then validate the new gateway under zero load and gradually shift traffic by adjusting weights, while continuous polling confirms no failed requests. We can roll back at any point when issues appear.

Step 5

Validation and handoff

Production traffic will be verified through the new gateway, full documentation of the configuration will be delivered to your team, and your engineers will be briefed on the ongoing operation.

FAQs

Frequently Asked Questions

What is the risk of staying on Ingress NGINX past the EOL date?

Every vulnerability discovered after the EOL date will not be patched. Beyond the security exposure, running end-of-life software in your traffic path (the layer that handles every customer request) results in compliance findings under SOC 2, PCI-DSS, HIPAA, and ISO 27001.

I am using the Ingress API but not Ingress NGINX. Does this apply to me?

Yes. The Ingress API is no longer being developed. Any organization still building on it is running infrastructure that won’t receive any new capabilities. Gateway API also fixes the structural limitations that made Ingress increasingly difficult to work with at scale.

How long does the migration take?

It depends on your cluster's complexity, the number of Ingress resources in play, and how heavily you rely on annotations that need to be re-expressed in the Gateway API. Although the cutover can happen in a single change window, the preparation steps take considerably longer. We scope the timeline during the assessment, not before it.

Can we run Ingress NGINX and the new gateway simultaneously during the migration?

Yes, and we recommend it. Running both in parallel is what makes a zero-downtime cutover possible. Our weighted DNS approach keeps the old Ingress serving production traffic while the new gateway is validated under zero load. Traffic shifts gradually by adjusting DNS weights. The old Ingress stays live until the transition is successful.

What happens if something goes wrong during the cutover?

The weighted DNS approach makes rollback immediate. If anything looks wrong after the traffic shift, swapping the weights back instantly moves production traffic back to the old Ingress.

How is Pelotech different from other migration vendors?

The engineers on the sales call are the engineers on your project. We also ran Ingress NGINX in our own GitOps platform, which means we ran this migration on our own infrastructure, have a solution for potential failures, and can do it with zero downtime.

What does the engagement actually start with?

We start with an assessment. We review your cluster, annotation inventory, namespace model, and AWS setup before we scope anything. No timeline is promised before that step is complete, because the honest answer depends entirely on what we find.

Do we have to move to the Gateway API, or can we switch to another Ingress controller?

Switching to another Ingress controller is the lowest-effort path and buys time. But it does not move you toward where Kubernetes networking is going. The Ingress API is feature-frozen regardless of which controller implements it.

Company

About us Careers

Resources

Blog Content Hub

Services

Kubernetes ExpertiseKubernetes Security ConsultingAWS Cost Optimization ServicesAWS ExpertiseCloud servicesSoftware Development & Data SolutionsPlatform Engineering ServicesGovcloud Consulting ServicesCustom Backend Development ServicesLegacy System Modernization ServicesTrainings

Something in mind?

Contact us