A common mistake is treating migration as a pure code-generation exercise. In practice, the hard part is reconstructing the environment’s structure so Terraform reflects how resources actually work together. Without that model, teams may import incomplete stacks, miss dependencies, and create state that is technically valid but operationally weak.
Why Cloud-to-IaC Migrations Fail When Teams Start from Resources Instead of Relationships
Migrating cloud infrastructure to Infrastructure as Code is often mistaken for a straight conversion of existing assets into files. That framing misses the real objective: expressing the environment in a way that is repeatable, reviewable, and safe to change. When teams focus on copying resources one by one, they tend to preserve fragmentation, hidden dependencies, and one-off manual decisions that were never visible in the console. The result is code that looks organised but does not accurately represent how the platform actually behaves.
That matters because Infrastructure as Code changes the failure mode. A bad template is not just a documentation problem; it becomes a deployment pattern that can be reused, reviewed with false confidence, and scaled across environments. If dependencies, ordering, networking assumptions, or identity bindings are not reconstructed correctly, the migration can create a more brittle system than the one it replaced. For identity-heavy cloud estates, the same mistake often shows up in service credentials, access policies, and automation permissions, where the operational truth is more complex than the exported resource graph. In practice, many security teams encounter broken dependency chains only after the first attempted redeployment, rather than through intentional design review.
For teams that manage machine access and automation, the issue overlaps with non-human identity governance because infrastructure definitions often embed service roles, tokens, and permissions. The OWASP Non-Human Identity Top 10 is relevant here because it highlights how machine identity sprawl and weak lifecycle control can become embedded in cloud automation, not just in the application layer.
How a Real Migration Should Reconstruct the Operating Model, Not Just the Provisioning Steps
A useful IaC migration starts with understanding how the current environment is assembled, which parts are reusable, and which parts are accidental. That means inventorying resources, but also mapping dependencies such as network paths, secrets usage, instance roles, load balancer attachments, DNS relationships, and any stateful services that do not tolerate naive recreation. The point is not to reproduce every historical choice. The point is to define a stable desired state that can be safely reconciled in future change cycles.
Good migrations usually separate the work into layers. First comes discovery and decomposition: identify what belongs together, what must be managed together, and what should remain outside the first cut. Next comes state modelling: decide what will be imported, what will be newly declared, and what needs refactoring before it can be safely managed as code. Then comes validation: test whether the proposed code can reproduce the environment without silent drift, missing permissions, or dependency failures. This is where many projects fail, because code generation tools can emit syntactically valid configuration that still encodes the wrong operational assumptions.
- Rebuild dependency order before writing modules.
- Separate stable platform primitives from application-specific overlays.
- Confirm which resources are safe to import and which should be recreated.
- Check whether access policies, secrets, and service identities are being migrated as first-class objects.
- Validate state management, not just syntax, before treating the migration as complete.
The biggest practical constraint is that some cloud components cannot be migrated cleanly without redesign. State-heavy services, tightly coupled shared networks, and manually tuned exceptions often need a transition path rather than direct conversion. If the migration tooling is treated as a source of truth instead of a transformer, teams usually end up encoding old fragility into new automation, which is where the guidance breaks down.
Where the Edge Cases Hide: Legacy Drift, Shared Services, and Over-Automation
Tighter automation often increases the cost of getting the model wrong, so organisations have to balance speed against fidelity. That trade-off is especially visible when the old environment contains drift, undocumented exceptions, or shared services that were never designed for clean ownership boundaries.
One common edge case is legacy infrastructure with years of manual fixes. Teams may assume the existing environment is the correct baseline, when in fact it is only the currently functioning baseline. Another is multi-account or multi-subscription shared services, where a seemingly local change can break other workloads that depend on central networking, logging, or identity controls. A third is over-automation of credentials and permissions, where the migration copies access patterns without challenging whether those permissions still need to exist in the new design.
There is also a consensus gap in the industry around how aggressively to refactor during migration. Some practitioners advocate a near-lift-and-shift first, then iterative improvement. Others argue that if the environment is being rebuilt as code anyway, major structural flaws should be corrected early. NHI Management Group’s view is that the right answer depends on the blast radius of the change: where dependencies are dense or identities are highly privileged, conservative sequencing is usually safer than broad refactoring. The migration succeeds when the resulting code is an accurate operating model, not when it merely looks complete.
Risk and Threat Considerations
The main risk in cloud-to-IaC migration is not only deployment failure. It is the creation of a repeatable configuration that preserves hidden exposure, especially around privilege, dependency, and drift. When imported state is incomplete or structurally wrong, organisations can unintentionally standardise insecure access paths or fragile service relationships across future releases.
Failure mechanism: Teams often migrate visible resources but miss the control relationships that make them safe, such as least-privilege policy scope, inter-service trust, secret rotation, or network segmentation. Once that incomplete model is codified, every subsequent deployment reuses the same blind spot. In cloud estates with automation and machine identities, this can turn one-off operational shortcuts into persistent access and change-management weaknesses.
Impact: The result can be broken redeployments, hidden privilege retention, widened blast radius, or configuration drift that is harder to detect because it is now embedded in code. In more sensitive environments, an attacker who obtains an overly broad service identity or exploits a mis-modelled dependency can move through the environment more easily than the original manual setup suggested.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | IaC migration must preserve secure, repeatable cloud configuration. |
| CIS 5 — Account Management | Migrations often carry forward service accounts and access paths. | |
| CIS 16 — Application Software Security | IaC transforms operational change into repeatable software artifacts. | |
| Recommendation — Standardise cloud baselines in code and validate configurations before rollout. Review and remove unnecessary identities and access during migration. Treat infrastructure definitions as controlled software and review changes before deployment. | ||
| NIST CSF 2.0 | PR.IP-1 — Configuration Management Policy and Processes | IaC depends on disciplined configuration and change control. |
| ID.AM-2 — Software Platforms and Applications Are Inventoried | Migration requires a trustworthy inventory of cloud components and dependencies. | |
| Recommendation — Apply configuration management controls to keep infrastructure state consistent and reviewed. Inventory cloud resources and dependencies before converting them into code. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Cloud IaC often embeds machine identities and ownership boundaries. |
| NHI-03 — Secret Exposure and Lifecycle | IaC migrations frequently involve tokens, keys, and certificates. | |
| NHI-05 — Privilege and Access Scope | Mis-modelled IaC can preserve excessive automation privileges. | |
| Recommendation — Inventory machine identities and assign ownership before codifying access paths. Rotate and control secrets as part of the migration instead of copying them into code. Reduce service identity privileges to the minimum required in the new design. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Over-permissive automation identities can be retained through migration. |
| Recommendation — Monitor for retained or expanded account permissions during infrastructure refactoring. | ||
Practitioner Guidance
What to prioritise: Reconstruct the dependency model before optimising for file generation. The migration should prove that the environment can be safely re-applied, not just that the resources can be described.
What to verify: Check whether the imported or generated configuration captures identity bindings, secret dependencies, network reachability, and resource ordering. If any of those are implicit, the migration is not yet trustworthy.
What practitioners underestimate: The hardest part is usually not syntax or tooling, but deciding which parts of the old environment are accidental and should be removed rather than preserved. Treat any manual exception that survived in production as a design question, not an implementation detail.
Practitioner takeaway: A successful migration leaves teams with a governed operating model they can safely re-create, not a scripted copy of whatever happened to be running yesterday.
Related resources from NHI Mgmt Group
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
