Introduction
Starting with Crusoe Terraform provider v1.3.0, crusoe_ib_partition is deprecated in favor of crusoe_transport_partition. Both types manage the same partition in Crusoe Cloud.
If you only change the resource type in your .tf file, Terraform plans to destroy the old resource and create a new one. Applying that deletes the live partition.
Use this guide when you are not using a moved {} block — for example on an older provider version, or when you prefer import. The partition stays in Crusoe; only Terraform state is updated.
ℹ️ Note: If you are on provider v1.4.0 or later, the
moved {}block is the simpler path. See How-To Migrate crusoe_ib_partition to crusoe_transport_partition in Terraform instead. Use this article whenmoved {}is not available to you.
Prerequisites
- Terraform Installed
- Crusoe Terraform Provider Configured (v1.3.0 or Later; v1.4.0+ Recommended)
- Crusoe Credentials in
~/.crusoe/config(orCRUSOE_ACCESS_KEY_ID/CRUSOE_SECRET_KEY) - An Existing Partition Currently in State as
crusoe_ib_partition - The Partition ID, From
terraform state showor the Crusoe Console
Instructions
Step 1: Get the Current Partition ID
Run terraform state show against the resource you are migrating:
terraform state show crusoe_ib_partition.<RESOURCE_NAME>
From the output, record three values:
-
id— the partition ID. You pass this to the import in Step 4. -
name— needed in Step 2. -
ib_network_id— needed in Step 2.
The partition ID is also visible in the Crusoe Console. Confirm it matches what Terraform has in state before continuing.
Step 2: Switch the Resource Type in Your Configuration
In your .tf file, change the resource type from crusoe_ib_partition to crusoe_transport_partition, keeping the same resource name, and rename the ib_network_id attribute to transport_network_id with the same value:
resource "crusoe_transport_partition" "<RESOURCE_NAME>" {
name = "<PARTITION_NAME>"
transport_network_id = "<NETWORK_ID>"
}Keep the name value exactly as it was. A mismatch here causes Terraform to plan a change after the import succeeds.
Do not add a moved {} block. If one is already present, remove it — this guide covers the import path instead.
Step 3: Check the Plan Before Applying Anything
terraform plan
Because the old resource is no longer in your configuration and the new one has no state, Terraform reports a destroy and a create:
Plan: 1 to add, 0 to change, 1 to destroy.
⚠️ Warning: Do not apply this plan. It deletes the live partition and disconnects any attached VMs.
This step is a confirmation that you are in the expected state, not an action. Continue to Step 4.
Step 4: Move the State to the New Resource Type
Choose Option A or Option B. Both produce the same result — the same partition tracked under the new resource type.
Option A — removed and import blocks in configuration (preferred, Terraform 1.7+)
Safer than running state rm by hand, because Terraform shows you the full plan before anything changes. Add a removed block with destroy = false for the old resource, and an import block targeting the new one:
removed {
from = crusoe_ib_partition.<RESOURCE_NAME>
lifecycle {
destroy = false
}
}
import {
to = crusoe_transport_partition.<RESOURCE_NAME>
id = "<PARTITION_ID>"
}If the partition is not in your default project, use a composite ID instead:
id = "<PARTITION_ID>,<PROJECT_ID>"
Then run terraform plan and confirm it shows no destroy of the existing partition before you apply:
terraform plan terraform apply
After a successful apply, delete the removed and import blocks from your configuration. Keep the crusoe_transport_partition resource.
Option B — terraform state rm and terraform import
Back up your state first:
terraform state pull > backup.tfstate
⚠️ Warning: Complete both of the next two commands. Between
state rmand a successfulimport, the partition is live in Crusoe but not managed by Terraform. If the import fails, restore withterraform state push backup.tfstateand retry.
Remove the old resource from state, then import the partition under the new type:
terraform state rm crusoe_ib_partition.<RESOURCE_NAME> terraform import crusoe_transport_partition.<RESOURCE_NAME> <PARTITION_ID>
state rm drops the resource from state only. It does not delete the partition in Crusoe.
For a non-default project, append the project ID:
terraform import crusoe_transport_partition.<RESOURCE_NAME> <PARTITION_ID>,<PROJECT_ID>
Step 5: Verify the Migration
terraform plan
Expected output:
No changes. Your infrastructure matches the configuration.
Then confirm three things:
- The partition ID in the refresh line matches the original ID from Step 1.
- Any attached VMs are still running. They are unaffected by a state-only change.
- No
applyis needed after No changes — it would be a no-op.
Example
A partition named repro-partition is already in Terraform state as crusoe_ib_partition, and a VM is using it. The goal is to track it as crusoe_transport_partition without deleting it.
1. Starting configuration
terraform {
required_providers {
crusoe = {
source = "crusoecloud/crusoe"
version = "1.3.1"
}
}
}
resource "crusoe_ib_partition" "repro" {
name = "repro-partition"
ib_network_id = "<network-id>"
}Running terraform state show crusoe_ib_partition.repro returns the partition ID 58571f25-4243-4245-a80f-91229ae0d671.
2. The destructive plan to avoid
After switching the resource type with no moved {}, removed, or import, terraform plan returns:
# crusoe_ib_partition.repro will be destroyed
# (because crusoe_ib_partition.repro is not in configuration)
- resource "crusoe_ib_partition" "repro" {
- id = "58571f25-4243-4245-a80f-91229ae0d671" -> null
...
}
# crusoe_transport_partition.repro will be created
+ resource "crusoe_transport_partition" "repro" { ... }
Plan: 1 to add, 0 to change, 1 to destroy.This plan is not applied.
3. Option A configuration
terraform {
required_providers {
crusoe = {
source = "crusoecloud/crusoe"
version = "1.3.1"
}
}
}
resource "crusoe_transport_partition" "repro" {
name = "repro-partition"
transport_network_id = "<network-id>"
}
removed {
from = crusoe_ib_partition.repro
lifecycle {
destroy = false
}
}
import {
to = crusoe_transport_partition.repro
id = "58571f25-4243-4245-a80f-91229ae0d671"
}terraform plan shows no destroy, and terraform apply completes the move.
4. Option B commands
terraform state pull > backup.tfstate terraform state rm crusoe_ib_partition.repro terraform import crusoe_transport_partition.repro 58571f25-4243-4245-a80f-91229ae0d671
The import returns:
crusoe_transport_partition.repro: Importing from ID "58571f25-4243-4245-a80f-91229ae0d671"... Import successful!
5. Result
Either path ends with the same verification output:
crusoe_transport_partition.repro: Refreshing state... [id=58571f25-4243-4245-a80f-91229ae0d671] No changes. Your infrastructure matches the configuration.
The partition keeps ID 58571f25-4243-4245-a80f-91229ae0d671 and the attached VM stays up.
Common Issues
Plan Is 1 to Add, 1 to Destroy
-
Cause: Config was switched to
crusoe_transport_partitionwithoutmoved {},removed/import, orstate rm+import. - Solution: Do not apply. Use Option A or Option B in Step 4.
Error: Unable to Move Resource State
-
Cause: A
moved {}block was used on provider v1.3.0 or v1.3.1. -
Solution: Upgrade to v1.4.0 and use
moved {}(see Related Articles), or use this import guide instead.
Import Succeeds but Plan Wants to Change Name or Network
-
Cause:
nameortransport_network_idin the new resource does not match the existing partition. -
Solution: Use the same name, and the same network ID you had on
ib_network_id.
Wrong Partition Imported
-
Cause: The ID passed to
importwas not the live partition. -
Solution: Confirm the ID with
terraform state show(beforestate rm) or the Crusoe Console before importing.
Partition Is Unmanaged After a Failed Import in Option B
-
Cause:
terraform state rmsucceeded butterraform importfailed — for example a wrong ID, expired credentials, or the wrong project. -
Solution: Restore with
terraform state push backup.tfstate, confirm the partition ID and your credentials, then retry the import.