How do organisations decide whether to keep Ingress support during a gateway migration?

Why This Matters for Security Teams

Gateway migration is rarely just a routing change. For organisations that already depend on Ingress, the real question is how much operational risk can be absorbed while application teams, platform teams, and security teams move to a new control plane. Keeping Ingress support can preserve continuity, but it can also extend exposure if old manifests, stale policies, or unmanaged secrets remain in service.

The decision matters because migration windows are where control drift shows up. Existing definitions often embed assumptions about hostnames, TLS handling, auth middleware, and backend service reachability. If those assumptions are not validated against the target gateway, teams can end up with duplicate paths, inconsistent policy enforcement, and gaps in monitoring. NHI Management Group’s guidance on Ultimate Guide to NHIs is relevant here because gateway migration frequently exposes service accounts, API keys, and other secrets that were previously hidden inside routing automation.

Security leaders should also treat migration as a governance test, not a tooling preference. The NIST Cybersecurity Framework 2.0 emphasises managing change in a way that preserves resilience and control accountability. In practice, many security teams encounter failed cutovers only after an old Ingress path is still live in production, rather than through intentional decommissioning.

How It Works in Practice

The usual decision path starts with dependency mapping. If critical workloads still reference existing Ingress objects, controller annotations, or automation tied to those definitions, a temporary dual-path model may be justified. That does not mean “keep both forever.” It means explicitly time-boxing Ingress support while the organisation validates gateway parity for traffic policy, authentication, observability, and rollback.

A practical approach is to classify workloads into three groups: must-migrate now, can-run-dual, and can-retire later. The “can-run-dual” group should still be governed by a single source of truth for policy, because split ownership often creates configuration drift. Teams should also verify whether the gateway can replace any Ingress-only functions such as path rewrites, mutual TLS termination, rate limiting, or external auth integrations. If those capabilities are missing, keeping Ingress support may be safer than forcing a partial migration.

For security and reliability, current guidance suggests treating migration as a short-lived exception state. Use change control to document who can alter the legacy path, when it will be removed, and what telemetry proves it is still needed. Pair that with secret inventory and rotation, because routing transitions often reveal hard-coded credentials or stale tokens in CI/CD and manifests. NHI Management Group research has shown how often secrets are exposed in operational tooling, including Code Formatting Tools Credential Leaks and Hard-Coded Secrets in VSCode Extensions.

• Keep Ingress only when a defined workload still depends on it and no safe replacement exists yet.
• Enforce one policy baseline across both paths to avoid uneven access and logging controls.
• Set a retirement date and measure usage before extending the dual path.
• Review secrets, certificates, and automation tied to the old controller before cutover.

These controls tend to break down when multiple platform teams manage overlapping ingress rules across clusters because no single owner can prove which path is authoritative.

Common Variations and Edge Cases

Tighter cutover controls often increase short-term operational overhead, requiring organisations to balance migration speed against service stability. That tradeoff becomes sharper in regulated environments, multi-cluster estates, or platforms with many legacy applications that were built around Ingress-specific behaviour. Best practice is evolving, but there is no universal standard for how long dual support should remain in place.

One common edge case is the “shadow gateway” problem, where the new gateway is deployed but not fully enforced, so traffic keeps flowing through the old path by habit or exception. Another is applications that rely on custom annotations, rewrite rules, or controller-specific features that do not map cleanly to the target gateway. In those cases, keeping Ingress support may be the least risky option, but only if it is treated as a controlled transition and not as a permanent fallback.

Another issue is ownership. If application teams can still create new Ingress rules while the platform team is trying to deprecate them, the migration will stall. Current guidance suggests locking new legacy usage early, then allowing only approved exceptions. That is especially important where secrets management or identity controls are weak, because even a clean traffic migration can leave the old path as an attack surface. The Ultimate Guide to NHIs is useful here for understanding why unmanaged machine identities often linger after the routing change is complete.

Related resources from NHI Mgmt Group

• How do organisations decide whether to add a separate internal developer platform or extend the API platform they already have?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should organisations decide whether to keep using traditional MFA?
• How do organisations decide whether to replace an identity platform or keep extending it?