Cloud Migration Center

What it is

Cloud Migration Center is a Praxis app for planning a move from one cloud to another. It is the guided front end for the hardest part of a migration: understanding what you actually run today, what it would cost to run on a new cloud, and how each piece maps into Facets, before anyone commits to moving anything.

The app produces a Facets blueprint, the configuration that models an environment and everything in it, along with the typed Terraform modules that go with it. So a migration does not just land on the target cloud, it lands on a model you can operate afterward: drift-free environments, developer self-service, and one-click replication for every remaining environment.

📘

Cloud Migration Center is a Praxis app, currently in beta, enabled per organization from Apps in settings. It requires a connected Facets integration: the app registers the blueprint and modules it produces on your Facets control plane, so connect that integration before you start a migration. Each migration is scoped to a Facets project. The app plans and maps a migration; it does not adopt your existing infrastructure into Facets-managed Terraform state or move data itself. That execution runs through the import and migrate capabilities.

Supported migration paths

Cloud Migration Center scans an AWS or Azure source cloud. Google Cloud as a source is planned and not yet available. The migration target is AWS or GCP. AWS to GCP is the one path supported end to end today, and it is the path the cost comparison covers.

Core Capabilities

Source discovery Connect an AWS or Azure account and the app scans it to inventory what is running: the services, data stores, Kubernetes workloads, and dependencies that make up your current footprint.
Cost comparison Upload an AWS Cost and Usage Report and the app maps each line item to its GCP equivalent, pricing it at GCP on-demand rates alongside 1-year and 3-year committed-use rates so you can weigh the tradeoff before any work starts.
Kubernetes workload discovery Point the app at a cluster and it discovers the workloads running in it, along with their namespaces and Helm releases, and maps each to a Facets module.
Workload mapping The app reverse-engineers a Facets blueprint that models the source, and maps each workload to a typed Terraform module for the target, following your own reference modules.
Human-in-the-loop planning Discovery and mapping are automated, but the decisions that matter stay with you: what is in and out of scope, the order environments migrate in, and when to cut over.

How It Works

A migration project is organized into three activities, shown as cards under Migration Activities. They share one project and one target blueprint, and you can run them in any order.

Discover Resources inventories the source cloud and reverse-engineers the Facets blueprint, through the guided workflow described below.
CUR Cost Mapping produces the cost comparison from an uploaded AWS Cost and Usage Report.
K8s Migration discovers a cluster's Kubernetes workloads and applies them to the same blueprint.

Across all three, the automated work stops at the plan. What is in and out of scope, the order environments migrate in, and when to cut over stay with you.

📘

Each scan runs as an agent session. Open it from its step to see exactly what the app did, and continue the conversation to dig into a finding or unblock a step, without leaving the page.

The Discover Resources workflow

Discover Resources moves through seven steps. Completed steps collapse to a summary, so you always land on the one that needs you.

Cloud Account Connect the source cloud you are migrating from, AWS or Azure, through a read-only cloud integration.
Migration Target Choose the cloud the workloads will run on, AWS or GCP.
Boundaries Scope the scan to the VPCs, VNets, resource groups, or tags that make up the footprint you are moving. You opt each boundary in; nothing is scanned until you do.
Cloud Inventory (optional) Capture a raw inventory snapshot of everything inside those boundaries, exportable as a portable HTML or Markdown file you can share. This step does not gate the rest of the workflow.
Link Facets Select the Facets integration, project, and project type the blueprint will map into.
Resource Scan Discover the resource types in scope and review the module each maps to. You approve every mapping before it moves on.
Dependencies Build the dependency graph from the approved resources and run discovery from root to leaf, producing the blueprint and its typed Terraform modules for the target.

From Plan to Live Environment

Cloud Migration Center produces the plan: the inventory, the cost comparison, the Facets blueprint, and the workload-to-module mapping. Turning that plan into a running system happens in the layers below it.

Adopting infrastructure and moving data. Bringing your existing resources under Facets-managed Terraform state, and moving databases, caches, and secrets onto the target, runs through the import and migrate capabilities. Cloud Migration Center hands off to them; it does not adopt state or move data itself.
Standing up environments. Facets stands up the target environments from the blueprint. Once the first environment is migrated and validated, the rest replicate from the same blueprint in one click.
What your team owns. Application code changes, application-level testing, and the decision of when to cut traffic over stay with your team. Facets plans and models the infrastructure; it does not rewrite your application logic.

Safety Boundaries

Cloud Migration Center reads and plans. It inspects the source read-only and never changes the source or the target on its own.

Read-only discovery. Scanning the source cloud uses read-only access. The app inventories and models what it finds; it does not modify the source.
Planning, not execution. The app produces a blueprint and a plan. Adopting infrastructure into Terraform state and moving data are separate, opt-in steps that run through the import and migrate capabilities, not this app.
Humans decide scope, sequencing, and cutover. The automated work stops at the plan. Every decision that changes a live system is yours.

Beyond these app-specific limits, every migration runs under the shared Praxis permission, credential, and isolation model. See How Praxis works.

Integrations

Source cloud (AWS or Azure): read-only access to inventory the source footprint during discovery.
Facets control plane: the connected Facets integration where the reverse-engineered blueprint and typed Terraform modules are registered, so the plan lands as real Facets configuration for the target.
Git repository (optional): link a repository to receive the generated Terraform modules. As discovery develops each module, it pushes the files to the repository. Skip this step to keep the modules in Facets only.
Import and migrate capabilities: the execution layer that adopts existing infrastructure into Facets-managed Terraform state and moves data. See import and migrate.

Tip: You can also drive migration planning programmatically. See the API Reference for details.

Permissions

Every action requires an authenticated Praxis session and is scoped to your organization, following the shared access model in How Praxis works. A migration is scoped to a single Facets project, and its plan and blueprint are visible only to members of the organization that owns it.

Import and Migrate - Adopts existing infrastructure into Facets-managed Terraform state and moves data; the execution layer this app plans for.
How Praxis works - The shared permission, credential, and isolation model behind every Praxis app.
Incident Responder - Another Praxis app; detects and diagnoses infrastructure and deployment incidents.
Alert Doctor - Another Praxis app; continuously tunes a project's Prometheus alert rules.

Cloud Migration Center

On this page