This feature is in and subject to change. To share feedback and/or issues, contact Support.
Before you begin
- This tutorial assumes that you have a Cockroach Continuum organization. If you do not yet have one, refer to .
- You also need a cluster as the migration target. The Assistant does not create or configure the target cluster. If you do not yet have a cluster, refer to .
- This tutorial requires a PostgreSQL server on version 15 to 18. The server must be reachable from CockroachDB Cloud, and you must have a connection user that can create a database on it. A server bound to
localhostor reachable only over your VPN does not work. For more information, refer to . - To load the sample database, you need access to the
psqlclient. - To deploy the Assistant, you need an API key for a Cloud API with the role on the target cluster.
- To reach the Assistant’s web interface, your network must be on the target cluster’s IP allowlist.
Step 1. Load the sample database
Create the sample database, a miniature vehicle-sharing workload, on your PostgreSQL server.-
Save the following as
movr_sample.sql:Thefarecolumn uses the PostgreSQLMONEYtype, which CockroachDB does not support, so you can see the Assistant work through a conversion decision. -
Store your PostgreSQL server’s connection string in an environment variable. Replace
<your-postgres-connection-string>with the connection string for your server’s default database: -
Create the database and load the sample:
The second command reports each object as it is created:
Step 2. Deploy the Migration Assistant
The Assistant runs as its own instance alongside the target cluster. Use the following steps to create it by calling the cluster’smigration-assistant endpoint in the Cloud API. In these steps, replace {cluster_id} with the cluster’s ID from its overview page in the Console, and {secret_key} with your service account’s API key.
-
Create the instance:
The endpoint responds right away, but the instance is not ready yet; the response shows
PENDING:Theid,cluster_id, region, and timestamps shown are specific to your instance. -
Check on provisioning by re-running the following call every 30 to 60 seconds. Expect it to take 10 to 20 minutes. Continue once the status reaches
RUNNING:Once the instance is ready, the same call returns the address of the Assistant’s web interface:Record theurl. The response contains no sign-in credentials, because access to the Assistant uses your CockroachDB Cloud account. -
In a browser, go to the
urlfrom the previous step and sign in with your Cockroach Continuum organization. You must be a member of the organization that owns the target cluster. If the page does not load, confirm that your network is on the cluster’s IP allowlist (in the Cloud Console, under Networking), and allow a few minutes for a new allowlist entry to propagate.
Step 3. Connect the source
- On the Connect & verify page, enter the connection string for the
movr_sampledatabase as the source. - The Assistant fills in the target connection for the cluster it is attached to. Confirm that it identifies your cluster.
- Click Validate connections, and fix any reported connectivity or permission problems.
- Click Continue.
Step 4. Select what to migrate
- On the Tables tab of the Select objects page, ensure that
users,vehicles, andridesare selected. - On the Routines tab, ensure that
ride_duration_minutesandend_rideare selected. - Click Save selection.
- Click Continue to Schema conversion.
Step 5. Convert the schema
- The Assistant flags the
ridestable, because CockroachDB does not support theMONEYtype on thefarecolumn. Click Ask AI to convert these and wait for the Migration agent to return updated DDL that retypesfareasDECIMAL, along with an explanation of the change. - Click Apply to Schema to apply the updated
ridesstatement. - Click Continue to Generate plan.
Step 6. Generate the plan
- The Assistant generates your migration plan. For the sample, the plan defers the two foreign keys until after the data load and requires no changes from you.
- Click Continue to Pre-migration.
Step 7. Prepare the target
- Under each pre-migration step, click Execute to carry out the step. After executing a step, the Assistant automatically expands the next step.
- Click Continue to Data load.
Step 8. Load the data
- Click Execute on each table batch and wait for
users,vehicles, andridesto finish. The sample’s nine rows load in moments. Data movement uses the same machinery as . - Click Continue to Routine review.
Step 9. Create the routines
- Both of the sample’s routines convert cleanly. Click Create all 2 routines to create
ride_duration_minutesandend_rideon the target. - Click Run tests to continue and confirm that both routines pass.
- Click Continue to post-migration.
Step 10. Finish and verify
- Click Execute under each of the required post-migration steps, which restore the sample’s secondary index and deferred foreign keys.
- Click Execute under the optional verification step, which uses the same machinery as . Confirm that all three tables match the source.
- Click Continue to results.
Step 11. Review the results
Confirm that the Results page reports every selected object migrated and verified, and that Objects not migrated is empty. On a real migration, that list is your remaining work queue, and you would also re-create users, privileges, and any row-level security by hand. For more information, refer to .Step 12. Clean up
- Save local copies of any converted DDL or generated scripts you still need. The web interface you download them from goes away with the instance.
-
Delete the Assistant instance:
-
Optionally, drop the sample database from your PostgreSQL server:
The Assistant’s scope ends at a converted, loaded, and verified target. It does not run ongoing replication or perform application cutover. For those, refer to and .
What’s next
- Get more details on each stage of the migration process from .

