Keep Ingress support when critical applications still depend on existing definitions, older automation, or staged migration timelines. A dual path can lower operational risk if the target platform is not yet fully adopted. The decision should be driven by control maturity, migration scope, and the organisation’s tolerance for configuration change during transition.
Keeping Ingress During Migration Is a Transition Control, Not a Default
Organisations usually keep Ingress support when the migration would otherwise break live traffic, application delivery automation, or release processes that still depend on existing manifests and routing behaviour. The issue is less about preference and more about whether the old path remains operationally necessary while the new gateway model matures. That makes the decision a governance and change-management call as much as a platform call.
For teams managing that transition, the key question is whether dual support reduces exposure or simply prolongs ambiguity. A short overlap can protect availability and buying time for validation, but a long overlap can leave ownership split between two control surfaces and two ways of enforcing policy. The better approach is to define when Ingress is still the authoritative path, when it becomes compatibility only, and what evidence justifies its removal. In practice, many platform teams discover the migration boundary only after application owners have already encoded assumptions into deployment pipelines and release runbooks.
OWASP Non-Human Identity Top 10
How Teams Evaluate Dual Support Without Slowing the Migration
The practical decision starts with dependency mapping. If current workloads still publish Ingress objects, use controller-specific annotations, or rely on legacy routing and TLS patterns, removing support too early creates avoidable outages. If the gateway platform already covers the same functional needs, keeping both paths may still be justified temporarily, but only if the team can distinguish which applications belong on which path and who owns that decision.
Good migration decisions usually separate three questions. First, does the application require the old path because the target gateway lacks a feature, policy translation, or integration that is still needed? Second, is Ingress being retained for compatibility, or because the organisation has not yet completed governance work such as policy review, observability, or exception handling? Third, can the platform team prove that dual support will not create conflicting routes, duplicated certificates, or inconsistent access policies?
- Keep Ingress when it is still the only safe route for critical workloads that cannot be changed immediately.
- Retire Ingress sooner when the remaining use is accidental, undocumented, or limited to low-value technical debt.
- Use a defined cutover window when the new gateway can absorb the traffic model, logging, and policy requirements.
- Maintain explicit ownership for both configurations during overlap so that one path does not become a shadow platform.
The important operational point is that dual support should have a planned exit condition, not just a convenience rationale. Where the organisation cannot name the remaining dependencies, the migration is usually less controlled than it appears.
Where the Migration Trade-Off Becomes Hard to Ignore
Tighter platform standardisation often improves policy consistency, but it also increases short-term migration overhead, so organisations must balance reduced complexity against application disruption.
One common edge case is the mixed estate, where some services are ready for gateway-only routing while others still depend on legacy Ingress features. In that situation, the best answer is often not “keep everything” or “remove everything,” but “keep only what has a documented dependency and a review date.” That is a governance choice, not a technical compromise.
Another edge case is when operational teams retain Ingress because the new gateway is technically available but not yet trusted for production change control, monitoring, or rollback. That can be a valid temporary position, but it should be treated as a maturity gap. The usual failure mode is allowing the compatibility path to persist after the platform has become stable enough to remove it.
Guidance versus consensus matters here. There is no universal rule that Ingress must disappear immediately after a gateway migration begins. The consensus view is stronger on the need for explicit deprecation criteria than on the duration of overlap. Organisations should treat long-term dual support as a risk to clarity, not just a harmless implementation detail.
Risk and Threat Considerations
Retaining Ingress during migration can create configuration drift, inconsistent policy enforcement, and duplicated exposure paths if both systems remain active for too long. The risk is not only that traffic may flow through the “wrong” path, but that teams lose a single, reliable view of how external access is controlled.
Failure mechanism: when two routing models coexist, ownership, logging, certificate handling, and access rules can diverge. That creates a control gap where one path is hardened and monitored while the other remains partially inherited from legacy practice, increasing the chance of misrouting, unintended exposure, or missed change review.
Impact: the organisation may lose policy consistency, make incident response slower, and keep deprecated paths alive long after the migration should have converged. In a security incident, that can also leave a fallback route that attackers or misconfigurations exploit because it was assumed to be temporary and therefore received less scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 — Maintenance | Migration overlap is a controlled maintenance and change activity. |
| GV.SC-5 — Supply Chain Risk Management | Gateway migrations often depend on platform and tooling dependencies. | |
| Recommendation — Track legacy Ingress support as a managed maintenance activity with explicit retirement criteria. Assess platform dependencies before deprecating Ingress paths. | ||
| CIS Controls v8 | 4.8 — Unapproved Port, Protocol, and Service Usage | Dual routing paths can leave unnecessary exposure or unsupported access paths open. |
| 12.1 — Network Infrastructure Management | Ingress-to-gateway transition is fundamentally network control redesign. | |
| Recommendation — Remove or justify legacy access paths that are no longer required for production. Document and manage routing ownership during the migration. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Ingress and gateway automation often rely on non-human credentials and controllers. |
| Recommendation — Inventory automation identities and tie each routing path to a clear owner. | ||
Practitioner Guidance
What to prioritise: decide based on dependency evidence, not platform preference. If critical services still rely on Ingress definitions or rollout automation, keep support only as long as those dependencies are documented and actively reduced.
Decision rule: if the remaining use case is business-critical compatibility, retain Ingress with a named owner, expiry review, and a migration boundary. If the use case is undocumented or habitual, treat it as technical debt and remove it from the supported path.
What to verify: confirm that routing, certificate issuance, policy enforcement, and observability are not split across two control planes in a way that creates conflicting sources of truth. The migration is not complete until the organisation can show which path is authoritative for each workload.
Practitioner takeaway: the safest transition is usually not the fastest one, but the one with a clear sunset condition for legacy support and a clean ownership model during overlap.
Related resources from NHI Mgmt Group
- 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?
- How should organisations decide whether to keep specialist identity tooling after consolidation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
