MLV migration is a program: bronze to silver to gold with gates

Moving a handful of warehouse views to Materialized Lake Views is a rewrite. Moving hundreds is a program. Teams that treat the long tail like a weekend notebook usually discover dependency order the hard way: gold breaks, silver thrashes, and bronze shortcuts were never registered as the real contract.

Frame the work as bronze to silver to gold with gates. Count the estate. Order by dependency. Prove a representative POC. Then convert with per-view notebooks so blast radius stays local. Success is parity plus runtime, not "the portal shows an MLV."

Figure 1. MLV migration is a program across bronze, silver, and gold. Gates belong between layers, not as a weekend cutover wish. Source: Microsoft Learn: medallion lakehouse architecture.

I learned this on estates where the warehouse view graph looked flat on a slide and nested in reality. One mega-notebook converted "almost everything" and left on-call owning silent grain drift. The portal was green. The business measures were not.

The core idea

MLV migration succeeds when you manage inventory, dependency order, and proof gates, not when you invent a clever CAST trick.

Schema-enabled lakehouses and bronze shortcut layouts change how names resolve. Views that assumed a warehouse catalog need an explicit path story. A representative POC must clear parity and runtime before the long tail starts. Per-view notebooks keep failures isolatable. "Views exist" is a status report. "Views match and finish in budget" is a release.

A model that stays explainable

1. Count and dependency-order first

Inventory every warehouse view, its references, and its consumers (reports, downstream views, notebooks). Draw edges before rewriting SQL. Bulk conversion without a graph is how you convert leaves before trunks and spend a week chasing missing objects. Numbers beat optimism: if you have three hundred views, say three hundred and plan batches.

2. Redesign resolution for schema-enabled lakehouses

Shortcuts and schemas are not cosmetic. Bronze paths may move from flat warehouse objects to schema-qualified lakehouse tables. Update the mental model and the SQL together. Document how MLVs read shortcut-backed bronze versus managed silver. Migration is partly a namespace migration pretending to be a syntax migration.

3. Gate a representative POC

Pick a vertical slice that touches bronze shortcuts, a non-trivial silver transform, and a gold consumer with known measures. Prove row counts, key parity, critical column aggregates, and wall-clock under realistic concurrency. Only then open the floodgates. A POC that only converts three isolated bronze views teaches almost nothing about your real graph.

4. Prefer per-view notebooks over a mega-notebook

One notebook per MLV (or small tightly coupled set) limits blast radius, clarifies ownership, and makes CI diffs readable. Mega-notebooks hide which object failed and invite "fix the whole estate" as the only recovery. Shared helpers belong in libraries; object definitions belong in isolatable units.

5. Define success as parity plus runtime

Portal presence is not done. Done means agreed parity checks pass against the warehouse baseline (or a frozen snapshot), and runtime fits the refresh window you will actually run. Track both metrics per batch. A fast wrong MLV is a regression factory.

6. Promote in layer waves with explicit stop criteria

Bronze contracts first when shortcuts must stabilize. Silver next for transforms. Gold last when consumers depend on stable keys. Each wave has exit criteria and a rollback story. Skipping waves to "save time" usually spends it twice in incident mode.

Failure modes I design against

Rewrite-first inventory-never. Clever SQL, unknown dependents, surprise report breaks.

One notebook to rule them all. A single failure blocks hundreds of unrelated objects.

POC theater. Happy-path views only; no gold consumer; no runtime budget.

Assuming warehouse names map one-to-one. Schemas and shortcuts change resolution; silent wrong-table reads follow.

Declaring victory on object count. One hundred MLVs with twenty parity failures is not a migration.

Converting gold before bronze shortcuts exist. You materialize fiction, then blame Spark.

What the program office should track

Keep a living register: view name, layer, dependencies, notebook path, POC/batch id, parity status, runtime vs budget, owner. Review it in the same meeting that prioritizes feature work. Migration debt becomes invisible the moment it is only tracked in chat. If a batch slips, slip the date in the register; do not silently widen the parity exception list.

Dual-run without lying to yourself

If you keep warehouse views alive beside MLVs, pin the comparison to the same business day and the same key set. Dual-run that compares Tuesday warehouse to Wednesday lakehouse will manufacture false failures and false confidence. Record which baseline snapshot the parity job used. When stakeholders ask why a batch is late, show the register and the failing tier, not a vague sense that "Spark is slow."

Trade-offs

Program overhead feels slow next to "just convert it." It is faster than a partial cutover that freezes reporting. Per-view notebooks add files; they subtract mystery. Strict POC gates annoy stakeholders who want a date more than a proof. Give them both: a date contingent on gate metrics. Schema redesign may force temporary dual-run cost. Budget it. Dual-run without parity jobs is theater.

What I would put on an ADR

1. Full view inventory and dependency graph gate any bulk MLV conversion.
2. Schema and shortcut resolution rules are documented before silver/gold waves.
3. A vertical POC must pass parity and runtime before long-tail batches.
4. One notebook (or small set) per MLV; shared logic in libraries only.
5. Success = parity checks + runtime budget, not portal object existence.
6. Layered promotion with stop criteria and a named owner per batch.

Primary references: Materialized Lake Views and lakehouse schemas on Microsoft Learn. Pair them with your shortcut inventory and a written parity harness.

Closing

Hundreds of views do not migrate because someone found a template. They migrate because someone ran a program with gates.

Count the graph. Prove a slice. Convert in isolatable units. Call it done when parity and runtime agree, not when the portal looks busy.