Skip to main content
Crusoe Support Help Center home page
Crusoe

How-To Import an Existing Partition as crusoe_transport_partition

Rishabh Sinha
Rishabh Sinha
Updated

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 when moved {} 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 (or CRUSOE_ACCESS_KEY_ID / CRUSOE_SECRET_KEY)
  • An Existing Partition Currently in State as crusoe_ib_partition
  • The Partition ID, From terraform state show or 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 rm and a successful import, the partition is live in Crusoe but not managed by Terraform. If the import fails, restore with terraform state push backup.tfstate and 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 apply is 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_partition without moved {}, removed/import, or state 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: name or transport_network_id in 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 import was not the live partition.
  • Solution: Confirm the ID with terraform state show (before state rm) or the Crusoe Console before importing.

Partition Is Unmanaged After a Failed Import in Option B

  • Cause: terraform state rm succeeded but terraform import failed — 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.

Related Articles

Additional Resources

Related to

Was this article helpful?

0 out of 0 found this helpful

Still need help?

Our support team is ready to assist you with any questions.

Have more questions? Submit a request

Related Articles

Recently Viewed

Comments

0 comments

Article is closed for comments.