Flex Tooling Migration Terraform K8s CLI
Parent: MongoDB Atlas Flex and Serverless Tiers · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-b397d383429d
↓ Facts as markdownall context files
Source-anchored research for Flex Tooling Migration Terraform K8s CLI. 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.
Structure and components
- The Flex resource documentation recommends mongodbatlas_advanced_cluster for managing Flex because it also supports tenant and Dedicated clusters. The migration guide likewise recommends advanced_cluster for converted shared-tier deployments, although its Serverless-to-Flex subsection contains conflicting resource recommendations. (medium confidence) (verified as of 2026-10-23) [source]
How-to and procedures
- Avoid leaving one converted Atlas cluster bound to multiple Terraform resource addresses: HashiCorp warns that duplicate imports can cause unwanted behavior, and the Atlas guide explicitly removes the former Serverless address when replacing it with the imported resource. (high confidence) [source]
Problems, failure modes and limitations
- For mixed Terraform and Kubernetes tooling, Pulumi recommends assigning ownership by namespace, resource type, or workload boundary because overlapping tools can overwrite desired state. Applying that ownership discipline during a Flex tooling migration is a methodological inference; the article does not test MongoDB Flex or establish a Flex-specific reconciliation failure. (low confidence) [source]
Comparisons and alternatives
- Flex imports use a provider-defined ID in PROJECT_ID-FLEX_CLUSTER_NAME form. Terraform's import command binds that existing object to the specified resource address; the ID format comes from the provider, rather than Terraform itself. (high confidence) [source]
Facts and statements
- MongoDB documents January 22, 2026 as the end of general tooling support for M2/M5 and Serverless. Existing M2/M5 clusters migrated to Flex; Serverless deployments could become Free, Flex, or Dedicated, so automation must first identify the actual target type. (medium confidence) (verified as of 2026-10-14) [source]
- For an already converted Serverless-to-Flex deployment, the provider guide describes importing the existing cluster, updating references, removing the obsolete serverless state binding, and confirming a plan with no changes. It warns that retaining the obsolete binding can plan deletion. HashiCorp separately requires each remote object to have only one Terraform resource address; treat import and old-binding cleanup as a controlled state reconciliation, with plan review before applying. (high confidence) [source]
- A March 24, 2025 community report encountered CANNOT_USE_FLEX_CLUSTER_IN_CLUSTER_API after converting an M0 deployment to Flex. The author mentioned updating a Terraform module to 1.29.0 and reported that importing the converted cluster resolved the state synchronization problem; the thread does not identify a Terraform provider version. This is a historical incident, not evidence that current advanced_cluster resources lack Flex support. (low confidence) [source]
- The Atlas migration page requires removing obsolete M2/M5 and Serverless CLI commands and configures Kubernetes Flex deployments through spec.flexSpec with operator 2.12.0 or later. (low confidence) (verified as of 2026-10-14) [source]
- The Flex migration guidance tells CLI users to remove M2/M5 and Serverless commands, including obsolete Serverless continuous-backup steps. It directs workloads requiring private endpoints or continuous backup and point-in-time restore to Dedicated clusters. (low confidence) (verified as of 2026-10-14) [source]
- Provider release 2.14.0, dated July 15, 2026, includes a fix for intermittent tenant/Flex-to-Dedicated upgrade failures; PR 4548 explains that Atlas could transiently return IDLE with the old TENANT/FLEX provider and replaces one retry with bounded polling until both IDLE and Dedicated are observed. (high confidence) (verified as of 2026-07-15) [source]
- For converted clusters managed through Spacelift, its documented resource-import route runs terraform import as a task on the owning stack; this supplies a platform-specific way to perform the state reconciliation required by the Atlas migration guide. (medium confidence) (verified as of 2026-10-22) [source]
- A Terraform state rollback does not reverse an Atlas tier conversion: Spacelift explicitly says rollback changes only state, while the Atlas guide separately describes reconciling state after the infrastructure has already converted. (medium confidence) [source]
Children
- No children recorded.