Moving from Snowflake

Move over — with proof that the numbers match

Nobody swaps a warehouse over a weekend — you swap it once you are certain. lavalake ships a toolkit for exactly that: it reads your Snowflake inventory, translates definitions, adopts your dbt models, and lets both systems compute in parallel until it is proven row by row that the results agree.

Inventory: Tables and views, read straight from Snowflake
Translation: Table and view definitions as proposals
dbt: manifest.json or raw SQL
Proof: Parallel run with row counts and checksums
Connection: Snowflake as a registered, read-only source

First, see what is actually there

The first step is an inventory: the toolkit signs in to your Snowflake account and lists tables and views. So the project starts with a list rather than an estimate — the basis for planning effort and sequence.

Translate instead of retype

A Snowflake table becomes a finished proposal for the table in the lake, a view becomes a SQL proposal. Your dbt models come along too: the toolkit reads the `manifest.json` or the raw SQL files and turns them into an adoption plan.

Step	What you get
List the inventory	The source's tables and views, at a glance.
Translate a table	A proposal for the target table, with types carried over.
Translate a view	A SQL proposal; Snowflake-specific syntax is flagged for review.
Adopt dbt	A plan across all models, with sequence and dependencies.
Parallel run	Row counts and checksums from both systems, side by side.

Compute in parallel until it is proven

This is the part that makes a migration decidable. Both systems run the same query and the toolkit puts row counts and checksums next to each other. You see in black and white where your platform returns the same result — and where work remains. You switch when that list is right, not when a date demands it.

A migration rarely fails on technology. It fails because nobody can prove that the new number is the correct one.

You decide what is adopted

Every step produces a proposal for you to review. Creation runs through the same confirmation-gated paths as everything else in the platform, and every action is written to the tamper-evident log. What was adopted, and by whom, stays traceable throughout.

What you have afterwards

Open formats on your own storage: Apache Iceberg instead of a proprietary table format.
Costs that depend on hardware rather than on queries.
The same models and the same metrics — just on your own infrastructure.
A documented reconciliation you can put in front of an auditor.

Where this sits in the platform

The same picture as on the home page: one platform, one authorization model, one store.

One platform, one authorization model: every access — human, agent or BI tool — runs through the same identity and the same audit trail.

See it instead of reading about it

In half an hour we walk through the platform against your questions — ingestion, permissions, search, agent. No slides.

Book a live demo