Security teams should make each migration decision from an application profile that weighs security, efficiency, user experience, cost, and business criticality. The right choice depends on how sensitive the app is, how much change it can tolerate, and whether cloud migration should preserve, improve, or redesign its identity and access model. A blanket lift and shift often leaves risk unchanged or higher.
How to think about the migration choice
The six options are really different answers to one question: how much of the application’s current risk, structure, and operating model should survive the move. Rehost fits when the app is stable and the goal is speed. Revise and re-architect fit when the cloud move is also meant to improve resilience, security, or maintainability. Rebuild and replace are for cases where the existing design is too constrained or too risky to carry forward. Retain is a valid outcome when migration would create more exposure than value.
The decision should start with an application profile, not with a preferred migration pattern. That profile needs to capture business criticality, data sensitivity, technical debt, integration complexity, operational dependency, and the degree to which the app depends on its current identity and access assumptions. A simple lift-and-shift can move the same weaknesses into a new environment, while a controlled redesign may reduce attack surface and operational fragility.
For cloud migration decisions, CSA Cloud Controls Matrix is a useful control reference because it ties cloud choices to IAM, data security, operations, and supply chain concerns. When the application’s access model, trust boundaries, or tenancy assumptions are central to the migration outcome, the choice is not just technical, it is also a control-design decision.
How each option changes security and delivery risk
Rehosting is usually the lowest-effort path, but it preserves most of the original architecture, including any weak authentication, overbroad access, brittle secrets handling, or poor segmentation. It is best when time matters more than redesign and the current system is already reasonably well governed.
Revising and re-architecting sit in the middle. These choices are appropriate when the cloud move should improve how the application is secured, scaled, monitored, or segmented. They make sense when the current implementation works but the operating model needs cloud-native controls, better separation of duties, or a better fit with modern identity patterns.
Rebuilding and replacing are usually justified when the current design is too tightly coupled to old infrastructure, too risky to extend, or too expensive to secure incrementally. They also fit when a vendor product or managed service can absorb the functionality with less operational burden. Retain should be treated as a deliberate outcome, not a failure to decide, when migration would add compliance, resilience, or cost problems without improving the system.
Cloud migration often exposes identity weaknesses that were tolerated on-premises. That is why Ultimate Guide to NHI is relevant here: cloud moves frequently change how service accounts, API keys, automation credentials, and privileged access are used, and that can materially affect whether rehosting is safe or whether redesign is needed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud migration decisions hinge on IAM design, tenancy, and privileged access patterns. |
| DCS — Datacenter Security | Rehosting and retaining can preserve or shift infrastructure and boundary assumptions. | |
| Recommendation — Map each application to cloud IAM requirements before deciding whether to rehost or redesign. Assess whether existing infrastructure controls still hold after the migration path is chosen. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | The question is explicitly about choosing migration approaches for cloud adoption. |
| A.5.15 — Access control | The answer depends on whether the application’s access model can be preserved or improved. | |
| Recommendation — Review cloud-service security requirements before approving a migration pattern. Validate access control requirements before selecting rehost, revise, or rebuild. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Migration choices should account for how much of the current configuration baseline is carried forward. |
| IA-5 — Authenticator Management | Cloud migration often changes secret, token, and credential handling for applications. | |
| Recommendation — Establish a secure configuration baseline before deciding to lift and shift. Review credential lifecycle handling when deciding whether the app can be safely rehosted. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege | The answer stresses preserving or redesigning identity and access to reduce migration risk. |
| GV.OV-01 — Oversight of cybersecurity risk | The decision is a governance choice balancing business value, risk, and operating model change. | |
| Recommendation — Use least privilege as a gate for whether the application can remain mostly unchanged. Require risk-based oversight before approving the migration strategy for each application. | ||
Practitioner Guidance
What to verify: Before choosing rehost, confirm that the application can move without carrying forward an unsafe access model. If the system depends on long-lived secrets, manual exception handling, or flat network trust, the migration decision should move toward revise, re-architect, or rebuild rather than a direct lift and shift.
Decision rule: If the application is business-critical, externally exposed, or handles sensitive data, favor options that let you reduce privilege, improve observability, and simplify recovery. If it is low criticality, low change tolerance, and already well controlled, rehost or retain may be the right economic choice.
What practitioners underestimate: Migration choice is often decided by application code, but the real constraint is frequently operational identity. Cloud migration changes how the app authenticates, how secrets are stored, and who or what can act on its behalf, so access design should be part of the migration gate, not a post-move cleanup item.
Practitioner takeaway: The best migration choice is the one that matches the app’s risk profile and the target operating model, not the one that simply moves fastest.
Related resources from NHI Mgmt Group
- How should security teams maintain identity assurance during cloud migration?
- How should security teams govern Oracle Fusion roles during cloud migration?
- How should security teams test cloud environments during migration?
- How should security teams manage segregation of duties risk across hybrid Oracle environments during cloud migration?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
