A migration approach that moves workloads into cloud infrastructure with minimal redesign. It can reduce immediate migration effort, but it also risks carrying old access patterns, ownership gaps and control weaknesses into a new environment without fixing the underlying governance problems.
Expanded Definition
Lift-and-shift migration is a cloud transition method that moves workloads with minimal redesign, often preserving the same application logic, infrastructure assumptions, and identity dependencies. In NHI-heavy environments, that usually means service accounts, API keys, certificates, and automation workflows are relocated rather than re-architected. The approach can be useful when speed matters, but it is not a governance model by itself.
Definitions vary across vendors on how far “minimal redesign” may go, yet the practical test is simple: if the workload lands in cloud infrastructure with the same credential patterns and privilege structure, the migration is still lift-and-shift. That makes it closely related to cloud modernization, but distinct from refactoring or replatforming, which intentionally change control boundaries. NIST’s NIST Cybersecurity Framework 2.0 is helpful here because it frames the need to carry over risk management discipline even when technology changes.
The most common misapplication is treating lift-and-shift as a security improvement, which occurs when teams assume cloud relocation automatically fixes inherited access sprawl, weak ownership, or stale secrets.
Examples and Use Cases
Implementing lift-and-shift rigorously often introduces identity and operations debt, requiring organisations to weigh faster migration against the cost of carrying legacy controls into a new environment.
- A legacy batch platform is moved into IaaS with its existing service account hierarchy intact, while secrets are copied into the new environment without rotation.
- A customer portal is migrated to cloud hosting, but its CI/CD pipeline still stores API keys in configuration files and build variables, preserving the same exposure pattern described in the Ultimate Guide to NHIs.
- An internal reporting workload is shifted to a managed VM cluster, yet ownership remains unclear after the move, so offboarding and revocation tasks are delayed rather than redesigned.
- A manufacturing integration service is relocated without redesigning authentication flows, which is acceptable for timeline pressure but leaves excessive privileges untouched.
- A cloud migration team uses the NIST Cybersecurity Framework 2.0 to document residual risk before any later refactor of service identities and secrets.
Why It Matters in NHI Security
Lift-and-shift becomes risky when organisations confuse relocation with remediation. Non-human identities often outnumber human identities by 25x to 50x in modern enterprises, and the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges. If those same identities are moved unchanged, the cloud environment inherits old blast radius, stale secrets, and unclear accountability at scale.
This matters because migration often breaks the informal controls that existed on-premises. Old network trust assumptions disappear, but service accounts, certificates, and automation tokens may continue functioning exactly as before. That is why lift-and-shift should be paired with an inventory of NHIs, owner assignment, rotation planning, and privilege review rather than treated as a transport exercise. In NHI governance, the danger is not the move itself, but the failure to reassess how identities authenticate, authorize, and retire after the move.
Organisations typically encounter the consequence only after a cloud incident or audit finds that the migrated workload still depends on unmanaged secrets, at which point lift-and-shift governance becomes operationally unavoidable to address.
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 NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Lift-and-shift often preserves vulnerable secret storage and unmanaged NHI patterns. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access controls must be revalidated when workloads move environments. |
| NIST Zero Trust (SP 800-207) | Zero trust requires rechecking trust assumptions after migration, not inheriting them. |
Treat every migrated workload as untrusted until identities, access, and telemetry are revalidated.
