Provider migration, by design

Multi-cloud migration

Move workloads between AWS, Azure, and GCP without rewriting the design. ICE separates what you build from where it runs, so the canvas is portable by construction.

Five steps

Import the source

Authenticate against the existing cloud account. ICE crawls the resource graph and turns it into a canvas. 45+ importers on GCP today; AWS and Azure landing in pieces.

Review and clean up

Orphans, undocumented services, drift between intent and reality. The canvas makes everything visible. Delete the noise, group the rest.

Switch the target

Change the canvas provider. Each block remaps to the equivalent service on the new cloud. Postgres becomes RDS instead of Cloud SQL, Cloud Run becomes ECS, and so on.

Estimate cost and validate

Before you apply, ICE projects monthly cost per block on the new provider and flags requirements that do not translate (region availability, IAM, network shape).

Apply and watch

Plan, apply, and watch live progress. Logs and metrics surface on the canvas once the new resources are healthy. Cut traffic over when you are ready.

What gets translated

The block stays the same. The underlying service changes. A few examples.

Block	Source	Target
Scalable Backend	Cloud Run (GCP)	ECS Fargate (AWS) / Container Apps (Azure)
Postgres	Cloud SQL (GCP)	RDS (AWS) / Database for PostgreSQL (Azure)
Object Storage	Cloud Storage (GCP)	S3 (AWS) / Blob Storage (Azure)
Message Queue	Pub/Sub (GCP)	SQS (AWS) / Service Bus (Azure)
Observability	Cloud Logging (GCP)	CloudWatch (AWS) / Monitor (Azure)
Secret Store	Secret Manager (GCP)	Secrets Manager (AWS) / Key Vault (Azure)

What does not migrate automatically

Data. ICE creates the new database but you copy the data. Migration tooling is on the roadmap.
Custom IAM policies and org structures.
Cloud-specific features without an equivalent on the target (Vertex AI Vector Search, Cosmos DB shapes).
DNS cut-over. ICE prepares the new endpoint, you flip the records.

Why this works

The graph engine is provider-agnostic. Per-provider deployers handle SDK calls. That separation is what makes "switch the target" a button, not a sprint.

Architecture docs