| name | dcr-v1-to-v2 |
| title | DCR V1 to V2 Migration |
| summary | Migrate a Snowflake Data Clean Room from V1 SAMOOHA Provider/Consumer API to V2 Collaboration API. |
| description | Use when migrating a Snowflake Data Clean Room from V1 (SAMOOHA Provider/Consumer API) to V2 (Collaboration API). Discovers V1 setup via introspection queries, maps constructs to Collaboration API equivalents, converts JinjaSQL templates, and generates provider/consumer setup plus cleanup scripts. Output is local files only — no live DDL/DML. Triggers: DCR migration, V1 to V2, clean room upgrade, clean room migration, migrate DCR, upgrade clean room, SAMOOHA to Collaboration API. |
| tools | ["snowflake_sql_execute","Bash","Read","Write","Edit"] |
| prompt | Migrate my V1 Data Clean Room to V2 Collaboration API. |
| language | en |
| status | Published |
| author | Snowflake Solutions Team |
| type | snowflake |
DCR V1 to V2 Migration
Overview
Guides migration of a Snowflake Data Clean Room from V1 (SAMOOHA Provider/Consumer API) to V2 (Collaboration API). Produces local SQL scripts and reports — never executes DDL/DML against your accounts. Use this when you have an existing V1 clean room (calls into samooha_by_snowflake_local_db.provider.* / consumer.*) and want a generated V2 setup plus a side-by-side validation plan.
In scope: V1 inventories, JinjaSQL template conversion (drops the join_policy filter), provider + consumer setup scripts, cleanup scripts, validation checklist.
Out of scope: executing generated SQL, V0 direct-share setups, non-Snowflake clean rooms.
Prerequisites
- "Snowflake Data Clean Rooms" (SAMOOHA) installed on both accounts.
- Quick Start completed on both (
CHECK_MOUNT_STATUS() returns TRUE).
- Access to the V1 provider account with
SAMOOHA_APP_ROLE or ACCOUNTADMIN.
Workflow
Step 0 — Connection setup
Run cortex connections list, identify the active connection, confirm with the user that it points to the V1 provider account, and store it as provider_connection.
⚠️ STOPPING POINT: Do not run discovery queries until the user confirms the connection.
Step 1 — Discovery
Load discover/INSTRUCTIONS.md and execute its workflow using provider_connection. Output: discovery_report.md (clean room name, linked datasets, join policies, templates, consumer accounts).
⚠️ STOPPING POINT: Present the discovery report and confirm before mapping.
Step 2 — Mapping
Map each V1 construct to V2. Reference v1_v2_mapping.md for the full table.
- Parties: V1 provider → V2 owner (
COLLABORATION.INITIALIZE); V1 consumer → V2 runner (COLLABORATION.JOIN, COLLABORATION.RUN).
- Datasets: secure view →
REGISTRY.REGISTER_DATA_OFFERING with allowed_analyses: template_only. Wrap raw tables in a secure view first. Data stays in the provider DB.
- Join policy: V1
set_join_policy → V2 schema_and_template_policies per column ( for join keys, for date columns).
