Platform Migration Release
The Platform Migration release type covers the full lifecycle of migrating a data platform from one warehouse stack to another. It supports bidirectional BigQuery ↔ Snowflake migrations and introduces two structural features: a two-zone artifact model and an iterative equivalency loop.
Supported platform pairs: bigquery_to_snowflake, snowflake_to_bigquery
Artifact zones
Audit zone — read-only analysis of the source platform. No writes to any external system.
| Artifact | Command | Purpose |
|---|---|---|
ingestion_audit | /wire:ingestion-audit-* | Catalog all Fivetran connectors, sync configs, column selections |
db_object_audit | /wire:db-object-audit-* | Enumerate databases, schemas, tables, views, procedures |
security_audit | /wire:security-audit-* | Catalog roles, permissions, users, service accounts |
dbt_audit | /wire:dbt-audit-* | Catalog dbt models, classify by migration complexity |
orchestration_audit | /wire:orchestration-audit-* | Catalog orchestration jobs, schedules, and dependencies |
migration_inventory | /wire:migration-inventory-* | Synthesise all five audits into a unified catalogue |
Migration zone — writes to the target platform. Safety-gated commands require explicit confirmation.
| Artifact | Safety gate | Purpose |
|---|---|---|
migration_strategy | No | Platform-pair translation decisions, phasing, rollback |
target_setup | Yes | Target warehouse config, schemas, roles, service accounts |
ingestion_migration | Yes | Reconfigure/replicate Fivetran connectors to target platform |
dbt_migration | No | Translate dbt models batch by batch to target dialect |
orchestration_migration | Yes | Recreate orchestration jobs on target platform |
equivalency_validation | No (loop) | Iterative row-count, schema, value, freshness comparison |
cutover | Yes | Go-live runbook — point of no return |
migration_report | No | Post-migration record |
Setting up a Platform Migration release
Run /wire:new and select Platform Migration. You will be asked five additional questions:
- Source platform — BigQuery or Snowflake
- Target platform — must differ from source
- dbt project path — relative to repo root
- Orchestration tool — Dagster, dbt Cloud, Airflow, or None
- Connectivity — public endpoint or private network requiring an MCP tunnel
MCP server connections
The audit and migration commands connect directly to your source and target systems via MCP servers and APIs. Configure these before running any audit commands — not before /wire:new.
Warehouse access (source and target)
Both warehouse platforms are accessed via the claude.ai MCP servers, available when running Wire in Claude Code with an Anthropic account.
| Platform | MCP server | What it's used for |
|---|---|---|
| Snowflake | claude_ai_Snowflake | db-object-audit, security-audit, target-setup, equivalency-validate |
| BigQuery | claude_ai_BigQuery_MCP | db-object-audit, security-audit, target-setup, equivalency-validate |
Authenticate via the claude.ai interface before starting the audit zone. Run /wire:mcp list to confirm both platforms are reachable.
Ingestion tool connections
Wire auto-detects which ingestion tool you are using and connects via MCP or API fallback:
| Tool | Connection | Fallback |
|---|---|---|
| Fivetran | claude.ai Fivetran MCP server | Pre-exported CSV at audit/fivetran_connectors_input.csv |
| RudderStack | MCP server at mcp.rudderstack.com (OAuth) | None — authenticate via /wire:mcp auth rudderstack |
| Coupler.io | MCP server at app.coupler.io/mcp (personal access token) | CSV at audit/coupler_dataflows_input.csv |
| Segment | Public API token (SEGMENT_TOKEN env var) | None — no MCP server available |
| Airbyte | Airbyte API token (AIRBYTE_TOKEN env var, api.airbyte.com/v1 or self-hosted) | Optional: Agent MCP at mcp.airbyte.ai/mcp |
ingestion-audit-generate probes each MCP endpoint with a 10-second timeout and falls back automatically where a CSV fallback exists. For large Fivetran estates (100+ connectors), prepare the CSV from the Fivetran dashboard before running the audit zone — the template is at wire/TEMPLATES/migration/fivetran_connectors_input.csv.
Reverse ETL connections
If the source platform includes reverse ETL syncs, Wire audits them via the Hightouch REST API (https://api.hightouch.com/api/v1) using a read-only API key set in the HIGHTOUCH_TOKEN env var, or from a copy of the client's Hightouch Git config directory at audit/hightouch_git/.
Private network access
If either warehouse is behind a VPC and not publicly reachable, deploy an MCP server tunnel inside the client's network and register it in Claude Console → Settings → MCP Tunnels. Wire outputs the exact tunnel deployment steps during /wire:new setup — do not proceed to the audit zone until the tunnel is confirmed active.
Audit zone: parallel by default
/wire:migration-audit-all <release-folder>
This fans out five subagents simultaneously. Before launching, you will see a token cost confirmation with options to run in parallel or sequentially.
dbt audit and complexity classification
dbt-audit-generate reads every .sql model file and assigns a complexity rating:
| Rating | Criteria |
|---|---|
trivial | No platform-specific features; view or table materialization |
low | 1–2 platform-specific functions with direct target equivalents |
medium | 3+ platform-specific functions, OR incremental materialization |
high | Nested/repeated field logic, complex incremental strategies |
blocked | Depends on an out-of-scope object, OR uses a feature with no known target equivalent |
dbt migration: batched processing
/wire:dbt-migration-generate <release-folder> # next pending batch
/wire:dbt-migration-generate <release-folder> --batch 3 # specific batch
/wire:dbt-migration-generate <release-folder> --model stg_salesforce__accounts # single model
Each model gets one of three translation treatments:
- auto-translate: Mechanical syntax substitution applied with high confidence
- guided-translate: Non-trivial dialect difference — translated then flagged with
-- WIRE:REVIEW - rewrite: Logic tightly coupled to source platform features — flagged with
-- WIRE:REWRITE
Equivalency validation loop
Once data is flowing into both platforms:
/wire:equivalency-validate <release-folder>
Each run performs five check types: row count, schema, value, freshness, and dbt tests. When a check fails:
/wire:equivalency-investigate <release-folder> --object carwow_sales.fct_orders
/wire:equivalency-fix <release-folder> --object carwow_sales.fct_orders --approach "Update TIMESTAMP_DIFF translation"
cutover-generate is blocked until checks_failing: 0.
Safety gates
Four commands require explicit confirmation before proceeding:
target-setup-review— confirms DDL scripts have been reviewed, target environment is isolated, client has approved in writingingestion-migration-review— confirms target landing schemas are ready, parallel running window is agreedorchestration-migration-review— confirms all orchestration jobs have been reviewedcutover-review— the point of no return. Requires all equivalency checks passing, written client sign-off, rollback window agreed
Full command sequence
/wire:new # release_type: platform_migration
# ── AUDIT ZONE (read-only) ──────────────────────────────────────
/wire:migration-audit-all <release>
# Per-audit validate + review gates
/wire:ingestion-audit-validate <release>
/wire:ingestion-audit-review <release>
/wire:db-object-audit-validate <release>
/wire:db-object-audit-review <release>
/wire:security-audit-validate <release>
/wire:security-audit-review <release>
/wire:dbt-audit-validate <release>
/wire:dbt-audit-review <release>
/wire:orchestration-audit-validate <release>
/wire:orchestration-audit-review <release>
# Synthesis — requires all five audits approved
/wire:migration-inventory-generate <release>
/wire:migration-inventory-validate <release>
/wire:migration-inventory-review <release>
# ── MIGRATION ZONE ──────────────────────────────────────────────
/wire:migration-strategy-generate <release>
/wire:migration-strategy-validate <release>
/wire:migration-strategy-review <release>
# ⚠ SAFETY GATE
/wire:target-setup-generate <release>
/wire:target-setup-validate <release>
/wire:target-setup-review <release>
# ⚠ SAFETY GATE
/wire:ingestion-migration-generate <release>
/wire:ingestion-migration-validate <release>
/wire:ingestion-migration-review <release>
# dbt migration — batched; repeat for each batch
/wire:dbt-migration-generate <release>
/wire:dbt-migration-validate <release>
/wire:dbt-migration-review <release>
# ⚠ SAFETY GATE
/wire:orchestration-migration-generate <release>
/wire:orchestration-migration-validate <release>
/wire:orchestration-migration-review <release>
# Equivalency loop — repeat until checks_failing == 0
/wire:equivalency-validate <release>
/wire:equivalency-investigate <release> --object <table_or_model>
/wire:equivalency-fix <release> --object <table_or_model>
# ⚠ SAFETY GATE — point of no return
/wire:cutover-generate <release>
/wire:cutover-validate <release>
/wire:cutover-review <release>
/wire:migration-report-generate <release>
/wire:migration-report-validate <release>
/wire:migration-report-review <release>
/wire:archive <release>
A worked example of a Platform Migration engagement — using a fictional client scenario with realistic command output, agent delegation, and reviewer decisions — is available in the Tutorial: Platform Migration.