Snowflake Data Clean Room migration tool¶

Deploy the backend (required)¶

1. Download migration-backend.sql from the Snowflake-Labs/dcr-migration-tool (https://github.com/Snowflake-Labs/dcr-migration-tool) GitHub repository.

2. In Snowsight, open a new SQL worksheet and run the contents of migration-backend.sql.

Deploy the Streamlit interface (optional)¶

The Streamlit app provides a graphical interface for the same stored procedures. All migration actions can also be performed directly via SQL. The Streamlit interface supports Provider and Consumer clean room migrations; webapp clean room migrations must be run via SQL worksheet.

To deploy the Streamlit app:

1. Download streamlit_app.py from the GitHub repository.

2. In Snowsight, navigate to Streamlit and click + Streamlit App.

3. Name the app DCR Migration Tool, set the database to DCR_SNOWVA and the schema to MIGRATION, paste the contents of streamlit_app.py into the editor, and click Create.

Step 1: Review eligible clean rooms¶

To view the clean rooms in your account and their eligibility for migration, run the following command, or open the Streamlit app:

USE ROLE SAMOOHA_APP_ROLE;
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.PROVIDER.view_cleanrooms();

Each clean room is classified as one of the following:

• Eligible: ready to migrate.

• Ineligible: blocked by an unsupported configuration. The reason is shown.

• Internal (UUID): orphaned or test clean rooms; skipped automatically.

Review the list and determine which clean rooms to migrate.

Step 2: Plan the migration¶

The Plan phase is read-only. It discovers the clean room’s configuration, translates it into Collaboration API YAML specifications, and returns a generated SQL script for your review without making any changes to your account.

The tool automatically detects whether the current account is the Provider or the Consumer, and generates the appropriate script for each.

In the Streamlit app: select a clean room, then click the View Script tab.

Via SQL:

USE ROLE SAMOOHA_APP_ROLE;

CALL DCR_SNOWVA.MIGRATION.AGENT_MIGRATE_ORCHESTRATOR(
    '<cleanroom_name>',
    'PLAN'
);

The output includes:

• Template YAML specs. Template names are versioned automatically (for example, migrated_my_template_2026_04_07_V1).

• Data offering YAML specs. Table names with dot notation are converted to use underscores.

• A collaboration spec with the analysis_runners block configured to match your clean room’s topology.

• Any warnings that must be resolved before you execute the migration.

Common warnings and how to resolve them:

Step 3: Execute the migration (Provider account)¶

The Execute phase writes to your account. It registers your templates and data offerings, then initializes the new clean room. The operation is idempotent: if it’s interrupted, it’s safe to run again.

In the Streamlit app: click the Execute Migration tab and confirm.

Via SQL:

USE ROLE SAMOOHA_APP_ROLE;

CALL DCR_SNOWVA.MIGRATION.AGENT_MIGRATE_ORCHESTRATOR(
    '<cleanroom_name>',
    'EXECUTE'
);

During execution, the tool:

1. Calls REGISTRY.REGISTER_TEMPLATE for each template.

2. Calls REGISTRY.REGISTER_DATA_OFFERING for each dataset.

3. Fetches system-generated resource IDs from REGISTRY.VIEW_REGISTERED_TEMPLATES.

4. Regenerates the collaboration spec using the authoritative IDs.

5. Calls COLLABORATION.INITIALIZE to create the new clean room.

6. Polls the status and waits for CREATED before calling COLLABORATION.JOIN.

Step 4: Finalize — consumer joins the collaboration¶

After the Provider executes the migration, each Consumer account must also deploy the tool and run their migration steps. The Consumer runs the same Plan → Execute flow in their account, using the same clean room name.

The Consumer migration:

1. Checks prerequisites in the Consumer account context.

2. Reads Consumer-side metadata (data offerings, join policies, column policies).

3. Generates a Consumer-side collaboration spec.

4. Calls COLLABORATION.JOIN to join the new clean room.

5. Links consumer data offerings to the Provider account via link_data_offering.

Step 5: Validate¶

The Validate phase confirms that the migrated collaboration is equivalent to the original clean room.

In the Streamlit app: click the Validate tab.

Via SQL:

USE ROLE SAMOOHA_APP_ROLE;

CALL DCR_SNOWVA.MIGRATION.AGENT_MIGRATE_ORCHESTRATOR(
    '<cleanroom_name>',
    'VALIDATE'
);

Validation checks:

• The collaboration status is CREATED (Provider) or JOINED (Consumer).

• The template count matches the legacy clean room.

• The data offering count matches.

• The consumer count matches.

If validation passes, your original clean room is still intact. Don’t drop it until you’ve confirmed that your pipelines are running correctly against the new collaboration.

CleanroomNotInstalled error¶

The clean room name is incorrect or you’re using the wrong account. List your available clean rooms to verify the exact name:

USE ROLE SAMOOHA_APP_ROLE;
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.PROVIDER.view_cleanrooms();

Pre-flight failure: multi-provider configuration detected¶

Multi-provider clean rooms aren’t supported in this release. Contact your solutions engineer to discuss options, or proceed with eligible single-provider clean rooms.

Analysis output doesn’t match after migration¶

This can occur when a clean room used provider-run analysis. In the Provider and Consumer architecture, source_table always referred to the provider’s table; in the Collaboration API, this mapping may be reversed. Review the generated template YAML in Plan mode and check whether source_table and my_table need to be swapped.

Missing REFERENCE_USAGE grant¶

If you see a missing reference usage grant error when joining the collaboration, run the following as ACCOUNTADMIN:

GRANT REFERENCE_USAGE ON DATABASE <provider_database> TO SHARE <collab_share>;

For more information, see Troubleshooting Collaboration Data Clean Rooms.