Trusted by industry leaders who want to avoid downtimes
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.
Get StartedIngress 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.
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.
Teams already on Ingress NGINX are reporting recurring reliability issues that users feel:
You already know the migration needs to happen. But, without dedicated SRE or DevOps capacity, can your team absorb the preparation workflow (annotation auditing, controller evaluation, non-production testing, weighted DNS setup) without sprint cycles slipping and features getting deprioritized? Have they actually run the migration in production to identify and resolve failure points that cause downtime and frustrate users?
Teams typically attempt this migration in one of two ways and face unexpected issues either way:
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.
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.
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.
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 Certified Service Provider
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 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.
Engineers with 10 to 20 years of experience handle each migration, rather than simply reviewing outputs from junior resources at the end.
Independent verification that the engineers handling your migration meet the highest technical bar in the Kubernetes ecosystem.
We've run the same migration on our own infrastructure first, worked through every failure mode, and implemented it for customers — with zero dropped requests.
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.
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 on the roadmap. They needed a team that had already solved the problems their migration would surface.
Pelotech completed a full annotation audit, configured Envoy Gateway in a non-production environment, and executed a weighted DNS cutover via ExternalDNS and AWS Route 53. Both systems ran simultaneously under the same hostname throughout the transition.
The Result
Zero failed requests — verified through continuous polling throughout the entire cutover.
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 →We review your existing annotation inventory, namespace model, AWS configuration, and current Ingress resources before we scope anything. 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.
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.
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.
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, 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.
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.
Free webinar
Ingress NGINX to Envoy Gateway
~60 min · Pelotech