# Flex Tooling Migration Terraform K8s CLI > Source-anchored research for Flex Tooling Migration Terraform K8s CLI. Run status: COMPLETED. Parent: [MongoDB Atlas Flex and Serverless Tiers](https://llms-explorer.com/tree/mongodb-atlas-flex-and-serverless-tiers/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/flex-tooling-migration-terraform-k8s-cli/ ## 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](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/flex_cluster.md) ## 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](https://developer.hashicorp.com/terraform/cli/commands/import) ## 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](https://www.pulumi.com/blog/terraform-kubernetes/) ## 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](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/resources/flex_cluster.md) ## 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](https://www.mongodb.com/docs/atlas/flex-migration.md) - 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](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/docs/guides/serverless-shared-migration-guide.md) - 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](https://www.mongodb.com/community/forums/t/problem-with-terraform-and-new-flex-cluster/316438) - 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](https://www.mongodb.com/docs/atlas/flex-migration.md) - 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](https://www.mongodb.com/docs/atlas/flex-migration.md) - 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](https://raw.githubusercontent.com/mongodb/terraform-provider-mongodbatlas/master/CHANGELOG.md) - 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](https://docs.spacelift.io/vendors/terraform/state-management) - 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](https://docs.spacelift.io/vendors/terraform/state-management)