Provider migration, by design
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.
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.
Orphans, undocumented services, drift between intent and reality. The canvas makes everything visible. Delete the noise, group the rest.
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.
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).
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.
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) |
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