Adopt and migrate infrastructure

Praxis can take infrastructure you already run and adopt it into Facets, and it can move live data and secrets from AWS to GCP. Both jobs happen in conversation: you describe what you want, and the agent loads the right skill, a set of step-by-step instructions it follows using its own tools, and carries out the work. The two are complementary steps of the same move: first adopt the infrastructure so Facets manages it, then migrate the data that lives inside it. Neither task has a dedicated screen.

Import existing infrastructure

You can bring resources that are already running, whether created by hand, by another tool, or by a separate Terraform setup, under Facets without recreating them. This is how you take existing infrastructure that predates Facets and put it under the same managed, code-driven workflow as everything else, without a risky rebuild. Facets manages infrastructure as code and keeps a record, called Terraform state, of every resource it owns. Importing adds an existing resource to that record, so future changes flow through Facets while the resource itself keeps running untouched.

The defining guarantee is zero change. Before Praxis applies anything, it builds an import plan and holds it to a hard gate: the plan must show nothing to add, change, destroy, or replace. If the plan proposes to destroy or replace a resource that is actually running, Praxis treats that as a fault in how the resource is modeled and fixes the model instead of loosening the gate. To reach a clean plan, the agent reads your cloud account read-only to find the real resource identifiers, imports only what genuinely exists, and works through any drift, the gaps between the code and the running resource, until the plan comes back empty.

Throughout, Praxis holds to one principle: never delete, recreate, or disrupt a running resource, and make the smallest change possible. Nothing is applied until you approve it, and the final apply is effectively a no-op that records the imported resources in Facets without altering what is live.

This works across AWS, GCP, Azure, and MongoDB Atlas, and has been used to adopt large production estates.

GCP has a dedicated, phased approach for big shared environments. Praxis adopts the running estate read-only under the zero-change gate, proves the modules deploy by standing up one of each type in a fresh environment, then bulk-adopts the rest by type. One rule holds throughout: when the new environment shares the source's GCP project or network, nothing done in the new environment may affect the running one.

Migrate data stores

Adopting infrastructure into Facets does not move the data inside it. For that, Praxis migrates a running cache, database, or set of secrets from AWS to GCP. In every case the source stays strictly read-only: the migration reads from it and never writes to or alters it, and Praxis verifies the copy before you cut over. Praxis plans the move and generates the exact commands, but it does not run the copy itself from the chat. The copy runs from a host that can reach both the source and target endpoints, the reachability host that is the prerequisite people most often miss, or Praxis hands it to an operator to run.

Caches (Redis or Valkey, such as AWS ElastiCache to GCP Memorystore): Praxis first checks whether a copy is worth making at all, since a cache you can rebuild from its source of truth can be started cold on the target instead. When a copy is needed, it drives RIOT, an open-source Redis migration tool, to replicate the keys, then watches key-count parity and replication lag so you know when the target has caught up and cutover is safe.

Databases (AWS RDS or Aurora running Postgres or MySQL, to GCP Cloud SQL or AlloyDB): Praxis chooses the strategy from how much downtime you can accept. For near-zero downtime it uses Google's Database Migration Service to run a full load followed by change data capture, which streams ongoing writes until you switch over; for a planned maintenance window it uses a one-shot dump and restore. Any change the source needs to enable replication is printed for you to run yourself, never applied automatically. When the load finishes, Praxis verifies the result table by table, comparing row counts and checksums so you can trust that the target matches. After cutover, reset the sequences and AUTO_INCREMENT counters on the target: change data capture does not advance them, so new inserts otherwise collide with existing primary keys. This is the most common post-cutover bug.

Secrets (AWS Secrets Manager to GCP Secret Manager): a person runs this migration, by design. The read-only access Praxis uses to explore your cloud deliberately cannot read secret values, so the agent plans the mapping and reviews the output for an operator to run. It never creates the target secret, which must already exist as part of your infrastructure code, and it verifies each copied value byte for byte. Secret values stay in memory during the run and are never written to disk or logs.

Access and safety

You reach these capabilities by chatting with Praxis or through the Praxis CLI; there is no dedicated screen for them. Importing needs access to the Facets Control Plane, through the raptor CLI, plus the cloud integration for the account; the data migrations need the cloud integration and a reachability host. Read-only discovery and the final import apply run server-side under your organization's connected cloud credentials, while the actual copy of your data runs from the reachability host or an operator. The source is always read-only, and any write, whether applying an import, enabling replication, or copying a secret, happens only after you explicitly approve it. For how Praxis executes commands, protects credentials, and keeps you in control, see How Praxis works and stays safe.

Related

• Cloud Migration Center - The guided app for planning a cloud-to-cloud move
• Cloud operations and cost - Explore and inspect cloud resources, read-only
• Catalog - Map what you run before you adopt it
• How Praxis works and stays safe - The shared execution and safety model