Skip to main content

Tutorials

Command-level walkthroughs of every release type, showing the commands Wire runs at each step.

📄️Tutorials

The release-type reference pages tell you which artifacts a release produces and in what order, but they cannot show you what a release feels like on the day: what the command output looks like, when a specialist agent takes a task off your hands, which of the MCP integrations wakes up at a given gate and, above all, why a consultant chose one path over another when the reference offered two. Wouldn't it be useful to watch each release type run from start to finish on an engagement that resembles your own before you run it for real?

📄️Tutorial: Discovery (SOP)

In this tutorial we follow a ten-day discovery engagement for Thornfield Private Healthcare, a UK private healthcare group whose four clinics run on Cliniko, Stripe and HubSpot with no analytics layer between them, from the signed statement of work to a sponsor-endorsed roadmap and the spawning of the first build release. We start with the statement of work itself, since the engagement brief in the first step is generated from it, and then look at what this release type is for before walking through each command in turn.

📄️Tutorial: Dashboard Extension

In this tutorial we follow a three-day engagement for Foxwood Commerce Ltd, a UK direct-to-consumer fashion brand whose BigQuery, dbt and Looker platform has been in place for 18 months and whose marketing team still downloads reports from Google Ads, Meta Ads, Klaviyo and GA4 separately and reconciles them in spreadsheets. The whole of the work is three new explores, three dashboards and a runbook over data that is already in the warehouse. We start with the statement of work, then look at what the release type is for before walking through the five steps in turn.

📄️Tutorial: Platform Migration

If you have been asked to move an analytics platform from one warehouse to another against a fixed date, you will know that the translation work is only part of the job. The harder question, at every point in the engagement, is which systems you have written to, which you have left untouched and what you can still roll back if something on the new platform turns out to be wrong. This walkthrough traces a complete platform migration engagement from audit through to cutover, using a fictional B2B data services client moving their analytics stack from Snowflake to BigQuery, and it covers every domain in the migration sequence: ingestion (Fivetran), database objects, security, dbt, reverse ETL (Hightouch) and orchestration (Airflow). Along the way we will see how the "two-zone" model keeps the audit phase safe, as well as how the equivalency validation loop gates cutover, and we will start, after the statement of work, by looking at what makes a Platform Migration release different from the other release types.

📄️Tutorial: Tenant Carve-out

Not every migration moves a whole platform. When a business unit is divested, what you are asked to move is one tenant's share of a warehouse that several tenants have always used together, and the job is as much about what stays behind as about what moves: every extract, every comparison and every grant has to be scoped to that one tenant, and at the end you have to prove that no other tenant's rows came with it. A scoping mistake on a carve-out is a residency incident rather than a failed test, as we will see when we come to equivalency, and that is the reason the carve-out adds the checks it does.

📄️Tutorial: Looker to Omni Migration

Suppose your Looker contract is coming to an end, your BigQuery warehouse and dbt project are in good shape and the only thing that needs to move is the reporting layer that sits on top of them. Wouldn't it be useful to move that layer to Omni without touching the warehouse, and to prove, tile by tile, that every migrated dashboard returns the same numbers before any client user sees it? That is what the bi_migration release type is for, and in this tutorial we run a complete release of it, Looker to Omni, from an empty engagement repo through to Looker being switched off, using a fictional UK retailer whose warehouse and dbt project stay exactly where they are. Only the reporting layer moves.

📄️Looker to Omni: A Real Run

The Looker to Omni Migration tutorial walks a bi_migration release through a fictional engagement. What does the same release look like when it is run for real, against a live Looker estate of 196 dashboards and a shared Omni model that already carries validation errors of its own? Three Looker dashboards, and the LookML behind them, moved to Omni between 2122 on 7 September 2026, and the warehouse did not change. The Omni model was built on a branch, all 61 dashboard tiles were checked against their Looker originals and 52 rulings by the release director were recorded in files inside a git repo before the dashboards went into a 14-day parallel run with Looker.

📄️Tutorial: Agentic Data Stack

Suppose you have a dbt platform that works well, a Looker semantic layer that your analysts know their way around and a request from the business for natural language querying on top of it. The platform is not the problem; the problem is the size of the semantic layer, and what that does to an AI agent's ability to answer questions accurately. In this tutorial we trace an agenticdatastack release for a boutique analytics consultancy in exactly that position, with an existing, well-built dbt platform and a semantic layer too broad for a language model to navigate unaided.