A co-existence migration keeps the legacy access layer running for older apps while new cloud and mobile apps move to the modern identity platform. A full cutover replaces the legacy stack entirely after applications are identified, migrated, and reconfigured. Co-existence lowers risk early, while full cutover removes long-term maintenance and dependency overhead.
Why This Matters for Security Teams
Co-existence and full cutover are not just delivery choices. They change the risk profile of authentication, session control, and application governance. A co-existence migration is often the safer path when older web apps cannot be reworked quickly, but it also preserves duplicate policy paths, multiple admin planes, and inconsistent assurance levels. Full cutover removes that duplication, yet it exposes every remaining dependency and integration gap at once.
For identity teams, the practical question is how long the organisation is willing to carry two operating models. If legacy web access management remains in place too long, teams inherit extra operational cost, stale policy logic, and more places for privileged access drift. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the broader identity landscape, which is a reminder that migration programs often struggle first with inventory and ownership, not with the target platform itself. The broader risk is not the project plan. It is the hidden dependency chain behind older apps that still depends on manual exceptions and brittle trust assumptions. In practice, many security teams discover those gaps only after an application fails under the new control path, rather than through deliberate pre-migration testing.
How It Works in Practice
In a co-existence model, the legacy web access management layer remains authoritative for applications that cannot yet support modern federation, token-based access, or cloud-native policy checks. Newer applications are integrated directly into the modern identity platform, usually with SSO, conditional access, and stronger lifecycle controls. This approach reduces business disruption because migration can happen by application cluster, business unit, or risk tier instead of by forced enterprise-wide replacement.
A full cutover is different: the legacy stack is retired after each application has been discovered, remediated, reconfigured, and tested against the new identity boundary. That usually requires a strict inventory, dependency mapping, policy translation, and a rollback plan for high-risk systems. The control objective is not simply “move users.” It is to remove parallel trust paths and ensure the target identity stack becomes the single source of access decisions.
- Use co-existence when application refactoring is not yet feasible, but keep an exit date for each legacy dependency.
- Use full cutover when the application estate has been remediated enough to survive the removal of legacy session and policy handling.
- Validate how MFA, session timeout, logout, and federation behave before switching an app to the modern layer.
- Translate old access rules carefully; old policy semantics rarely map one-to-one to modern conditional access.
For teams building the target-state control model, the OWASP Non-Human Identity Top 10 is useful for understanding how non-human credentials and service flows create hidden migration dependencies, while NIST Cybersecurity Framework 2.0 helps anchor governance, risk, and control ownership during transition. NHIMG’s Ultimate Guide to NHIs is especially relevant where web access migration touches service accounts, secrets, and downstream automation. These controls tend to break down when legacy apps depend on embedded headers, shared accounts, or unsupported authentication plugins because the new platform cannot safely reproduce those assumptions.
Common Variations and Edge Cases
Tighter cutover planning often increases testing and remediation overhead, requiring organisations to balance speed against the risk of breaking older applications.
There is no universal standard for the best migration pattern yet. Current guidance suggests that co-existence is usually better for complex estates with many aging web apps, while full cutover is better once the organisation has enough application visibility and change capacity to remove the old stack cleanly. Some teams also use a hybrid sequence: co-existence first, then a staged cutover by application criticality.
The hardest edge cases are apps with hard-coded authentication assumptions, legacy reverse proxies, shared admin portals, and business workflows that still depend on session state from the old platform. In those environments, the migration is less about identity theory and more about preserving transaction integrity while changing the trust boundary. This is where policy translation, exception handling, and rollback discipline matter most. NHIMG’s Lifecycle Processes for Managing NHIs can also help when the migration exposes service tokens, automation accounts, or access keys that were previously hidden inside the legacy layer. The main tradeoff is straightforward: co-existence lowers short-term risk, but full cutover is the cleaner long-term security posture once the estate is ready.
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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV | Migration choice affects governance, oversight, and transition risk. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy migration often exposes service accounts and secret sprawl. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control matters when duplicative access paths exist. |
| NIST Zero Trust (SP 800-207) | AC-4 | Transitioning trust boundaries aligns with zero trust policy enforcement. |
| NIST AI RMF | Modern identity transitions need measurable risk management and accountability. |
Define migration risk, monitor controls, and assign owners for each identity transition.
Related resources from NHI Mgmt Group
- What is the difference between SaaS access management and full identity security?
- What is the difference between a vertically integrated Microsoft stack and an open directory platform for identity management?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between JIT access and Zero Trust for NHIs?
