You moved off ingress-nginx. What did the conversion quietly change?

The conversion tools translate what they can see. An Ingress object carries its rules and its annotations, and those come across. What does not come across is everything ingress-nginx did that was never written on the object: defaults set in the controller's own configuration, habits of the controller itself, and annotations the converter has no equivalent for and skips.

None of that shows up in a diff of the manifests. It shows up as a page that used to ask for a password and now does not, or a hostname that used to resolve and now resets the connection. Usually a customer finds it, after cutover.

• 2026-03-24. The ingress-nginx project was archived. No further releases or security fixes come from upstream.
• November 2026. Microsoft ends support for the managed NGINX ingress in AKS.

Patched builds of ingress-nginx are sold commercially, so staying put is a real option for some teams. This is for the teams that are moving, or have already moved and can still run the old controller, or stand it back up, to compare against.

A test estate of nine Ingress objects, converted to Gateway API with the standard upstream converter and served by Envoy Gateway. Both controllers were sent the same requests and the answers compared. Most of the comparisons differed, and every difference traced back to one of seven causes. Worst first:

Five of the seven are behavior the conversion lost, and each needs a fix before cutover. The HSTS header is a good example of why: ingress-nginx adds it by controller default, not by annotation, so no converter ever sees it. Envoy Gateway, Istio, and NGINX Gateway Fabric differ from each other in places too, so the target you chose matters.

• Sizing, free. You export the Ingress objects in scope, read-only, with your own credentials, and send them over. I size the work by the distinct behaviors in them, not by cluster count, and reply with a fixed price.
• Written scope. Clusters, hosts, exclusions, the fee, the delivery date, the terms below, and one rerun, agreed in writing before work starts.
• The proof. Both controllers, old and new, are sent the same requests for every route in scope, and every answer is compared: status, redirect target, security headers, and body where it should match.
• Every difference sorted. Each one is read and placed as a conversion gap to fix, an intended change, or harmless, with a fix direction for each gap.
• What you get. The written report, the fix list, and every comparison as data, signed with the Strickle Works key so anyone can check them with ssh-keygen, which you already have (how). Then one rerun after your fixes to show the gaps closed, and written acceptance.

One scope

$9,500, fixed. A bounded proof of one defined scope.

Broader

From $19,500, fixed for a defined scope. Several clusters, or one estate with more distinct behaviors. Clusters that repeat the same configuration add a small step each.

A program

From $35,000, plus scope steps, for a migration run across many teams or estates.

Fixing

$2,500 to $3,500 a day in capped blocks, or a fixed price once the findings are known. Never priced per difference. When I fix something I also prove, the report says so.

Witnessed review

$2,500 to $5,000. Someone else ran the proof, and you want it checked from outside. You get a written statement of exactly what I checked and what I found.

No hourly billing. The price is set in the written scope before work starts, and if the work runs long, that is my cost, not yours.

The fee buys the agreed signed proof, not a passing result. Differences and documented exclusions are valid results. If a tooling or delivery failure on my side stops the signed proof, I fix it and rerun once, and if it still fails, the fee is waived. Blockers on your side and changes to the scope fall under the written terms.

Everything here is written and asynchronous. You send the export, the scope comes back in writing, the report comes back in writing, and turnaround is quoted in days in the scope. If you want to walk through the report live, that happens in an evening slot.

• Request methods. GET and CORS preflight only. Request bodies, uploads, and websockets are not tested.
• Behind a login. Only the login challenge is compared, not the routing behind it.
• Client addresses. Requests come from one machine, so source-range allow and deny lists are tested for that address only.
• The backend's view. What the controller sends toward a backend is seen only through what the backend sends back.
• Tuning. Timeouts and similar proxy settings that no single request reveals are listed for review, not proved.

The report lists every exclusion for your estate by name, so what was not proved is on the page next to what was.

It is not the migration done for you. The proof tells you what changed and how to fix it. Fixing is a separate block, priced above, and you can buy the proof without it.

It is not a legal or compliance certification, and it is not a load test. It does not say every possible request behaves the same, and it does not promise no incident follows. It is a written, checkable account of how your routes answered on each side.

Douglas Adolph. I designed and built the deployment system behind a fleet of thousands of production Kubernetes clusters at a Fortune 50 company, along with the controllers, authentication path, and secrets tooling around it.

The engineer who scopes your work is the engineer who does it. Longer background, and the public code, at douglasadolph.com.

A short note is enough. Tell me roughly what you are moving and I will tell you whether this answers your question, including when it does not.

• How many clusters and roughly how many Ingress objects.
• The controller you are moving to, or choosing between.
• Whether you have cut over yet, and the date you are working against.

What comes back is a reply from me rather than a scheduling link.

hello@strickleworks.com

This is one engagement of several. The rest of the practice, and the prices, are at strickleworks.com.