Terraform state reconciliation after a Flex-to-Dedicated conversion
Parent: Flex Limitations and migration to Dedicated · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Terraform state reconciliation after a Flex-to-Dedicated conversion. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- When replacing the old Flex resource configuration, remove its obsolete state binding with terraform state rm mongodbatlas_flex_cluster.this. MongoDB warns that skipping this step plans deletion of the existing cluster; HashiCorp documents that state rm removes the binding without destroying the remote object. If the old configuration remains, Terraform can instead plan to create a replacement for the forgotten resource. (medium confidence) [source]
- For a converted deployment whose state is managed by Spacelift, its documented Tasks workflow can run terraform import on the owning stack. This is an application of Spacelift's generic import mechanism to MongoDB's post-conversion import procedure. (medium confidence) [source]
- HashiCorp permits keeping or removing import blocks after successful import because the import action is idempotent. MongoDB's v2.10.0 migration recipe removes the temporary import block; that cleanup choice is not a general Terraform requirement. (medium confidence) [source]
Facts and statements
- For a converted cluster previously managed as mongodbatlas_flex_cluster, MongoDB's v2.10.0 guide imports the existing Dedicated cluster into mongodbatlas_advanced_cluster using PROJECT_ID-CLUSTER_NAME; it describes this procedure as configuration-drift reconciliation that does not affect the underlying cluster infrastructure. (low confidence) [source]
- The guide generates configuration with terraform plan -generate-config-out=adv_cluster.tf, then restores variables and resource expressions and updates dependent resource references and data sources to mongodbatlas_advanced_cluster. (low confidence) [source]
- Review the import plan before applying and resolve unexpected changes. Import records existing infrastructure in state; successful reconciliation should reach a plan with no infrastructure changes. (high confidence) [source]
- A Terraform state rollback does not reverse the Atlas conversion. Spacelift says rollback only restores state; MongoDB describes post-conversion reconciliation as a procedure that does not modify cluster infrastructure. (medium confidence) [source]
- MongoDB provider release 2.14.0 (July 15, 2026) includes PR 4548's fix for intermittent tenant/Flex-to-Dedicated upgrade failures. Atlas could return IDLE with the old TENANT/FLEX provider; the fix replaces a single retry with bounded polling until the deployment is both idle and Dedicated. (high confidence) (verified as of 2026-10-31) [source]
- The versioned guide uses an import block and terraform plan -generate-config-out=adv_cluster.tf, then expects an import-only apply: one imported resource and zero added, changed, or destroyed. HashiCorp separately requires reviewing the import plan and correcting unexpected changes before applying. (medium confidence) [source]
- Importing a cluster does not complete configuration reconciliation: review generated optional defaults, restore variables and instance-address expressions, and update dependent resource references and data sources. MongoDB's guide targets a final no-changes result; HashiCorp likewise requires destination configuration to express the intended settings. (medium confidence) [source]
- Back up the Terraform state before reconciliation and perform state operations against the actual backend. MongoDB explicitly recommends a pre-migration backup. For Spacelift-managed state, Spacelift documents executing import through a stack task and exporting state with terraform state pull; the task workspace is discarded afterward, so export must persist the backup elsewhere. (medium confidence) [source]
- Current advanced_cluster documentation supports representing Flex clusters and upgrading them to Dedicated within mongodbatlas_advanced_cluster. Therefore, the v2.10.0 resource-replacement guide's statement that migration is UI-only does not describe every current workflow; determine the existing Terraform resource type before prescribing import and state removal. (medium confidence) (verified as of 2026-10-30) [source]
- The advanced_cluster Flex-upgrade documentation says only upgrade changes are applied during the upgrade operation, to avoid corrupt state if a later update fails. It directs users to run a secondary terraform apply for additional changes after the upgrade succeeds. (low confidence) (verified as of 2026-10-30) [source]
Children
- No children recorded.