The migration will usually stall because promotion of the Aurora read replica is not supported through Terraform in this workflow. The practical pattern is to use the console for the temporary migration steps, then import the promoted resources into Terraform once the cutover is complete. That keeps the end state managed as code without blocking the transition.
Why Terraform stalls the cutover when you force every Aurora step into code
The blocker is not “Terraform cannot manage Aurora”; it is that the migration itself contains a temporary control-plane step that Terraform does not cleanly express in this workflow. Aurora replica promotion is an operational transition, not a steady-state resource declaration. If teams insist on pure Terraform from the first step, they usually turn a short migration into a deadlock.
That deadlock is common in infrastructure work because the migration path and the managed end state are not the same thing. The right mental model is to separate temporary operational actions from the configuration you ultimately want Terraform to own.
Why the console is often the right tool for the temporary phase
The console is useful here because it lets you perform the one-off promotion, failover, or cutover action without pretending that the action is a durable desired-state definition. Once the replica is promoted and the migration is complete, the resulting resources can be imported so Terraform resumes control of the steady state.
This is a practical boundary, not a philosophical compromise. For the temporary phase, you need an operator-friendly action path; for the post-cutover phase, you need a clean, versioned state file that matches reality. That division is what preserves traceability while avoiding a stalled migration.
In broader cloud control terms, the same pattern appears whenever a platform exposes an irreversible or time-sensitive transition that is easier to execute than to model. The goal is not to abandon infrastructure as code, but to avoid forcing declarative tooling to impersonate a migration runbook.
What the final Terraform state should represent
After cutover, Terraform should describe the production topology as it exists after promotion, not the pre-cutover replica arrangement. That usually means importing the promoted cluster or instance, reconciling any drift, and then removing the obsolete source resources only after you have confirmed the new state is stable.
The critical practitioner point is that state reconciliation matters more than purity. A successful migration is one where the codebase eventually matches the deployed environment, the resource history is understandable, and the team can operate the new Aurora deployment without hidden manual dependencies.
That also means you should be explicit about which changes are allowed to remain manual and for how long. Temporary manual steps are acceptable during a controlled transition; permanent manual drift is not.
Risk and Threat Considerations
Trying to automate every step from the start can create an operational dead end, but it can also encourage unsafe workarounds, repeated retries, or rushed changes to the automation itself. In migration workflows, the risk is less about exploitation and more about control failure, drift, and an incomplete cutover that nobody fully owns.
Failure mechanism: Teams treat a transient migration action like a permanent declarative resource, then discover that the tooling cannot express the promotion step cleanly, leaving the cutover blocked or forcing brittle exceptions.
Impact: The migration stalls, the old and new states diverge, and the team may end up with inconsistent ownership, confusing rollback options, or a partially managed production environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PO-01 — Policies and Processes | Aurora migrations need an approved change process that separates transient cutover steps from managed state. |
| Recommendation — Define a migration runbook that distinguishes temporary operational actions from steady-state infrastructure management. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The question concerns configuration drift and post-cutover state control in infrastructure management. |
| Recommendation — Standardize the post-cutover configuration and reconcile drift before resuming normal Terraform applies. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Aurora promotion is a controlled change that must be planned, executed, and then brought back under governance. |
| Recommendation — Control the cutover as a managed change, then import the promoted resources into the configuration baseline. | ||
Practitioner Guidance
What to prioritise: Design the migration as a two-phase process, first execute the temporary cutover step, then bring the promoted Aurora resources under Terraform management once the environment is stable.
What to verify: Confirm that the imported state matches the post-cutover topology, that no orphaned replica assumptions remain in code, and that future applies will not try to recreate the pre-promotion layout.
Common mistake: Trying to “solve” the limitation by over-abstracting the Terraform module or forcing the promotion action into code that was never meant to model a one-time transition.
Practitioner takeaway: Use Terraform to own the steady state, not to pretend that every migration step is a steady-state resource operation; that separation is what keeps the cutover moving and the final environment manageable.
Related resources from NHI Mgmt Group
- What happens when teams try to enforce step-up auth only in the UI instead of on the server?
- What happens when security teams try to automate across disconnected tools without a shared workflow layer?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
