Use case · Migrations

Migrate with receipts.

Replatform without breaking what depends on you. Migrations fail the same way every time: someone downstream depended on behavior nobody wrote down. Limen makes those assumptions explicit before you cut over. Run old and new pipelines in parallel, certify both against the same contract, and prove equivalence row by row. When you ship, you have a signed receipt that the new system delivers what the old one promised, not a Slack thread of complaints six weeks later.

Book a demo → How it works
parallel run · orders_daily · 2026-06-14
Legacy Redshift · etl_v6
vs
New Snowflake · dbt_v1
Contract assertion Legacy New Verdict
01 row_count 412,884 412,884 =
02 sum(revenue_usd) $8,114,902.40 $8,114,902.40 =
03 null(refund_at) 0.21% 0.34% Δ 0.13%
04 distinct(customer_id) 71,402 71,402 =
05 join.orders→items no orphans no orphans =
06 freshness 04:12 UTC 03:41 UTC =
1 deviation 5 of 6 contract assertions match byte-for-byte. 1 deviation flagged for review before cut-over.
↔
Run old & new in parallel
==
Certify equivalence row-by-row
✓
Cut over with a signed receipt
0
Slack threads of complaints
How it works

From "we'll figure it out post-cutover" to "here's the equivalence receipt."

Five steps from the discovery phase to the green-light cut-over. Each one produces an artifact you can show to whoever's nervous.

  1. Extract

    Limen scans the legacy system and emits the assertions every consumer is implicitly relying on: row counts, null rates, value distributions, joins, freshness.

  2. Encode

    Those assertions become explicit contracts, reviewed by the data team and approved by the consumers who actually depend on the table.

  3. Parallel run

    Old and new pipelines run side-by-side. Both materialize against the same contract. Equivalence is checked on every batch, every day, for as long as you want.

  4. Reconcile

    Limen surfaces every deviation with the failing assertion, the row counts, and the diff. You fix or you accept. Either way it's a decision, not a surprise.

  5. Cut over

    When all contracts are green, you ship the new system with a signed equivalence receipt. The legacy stays online a week longer. Limen flags the moment they diverge.

The receipt

A signed equivalence receipt is the cut-over artifact.

Not a slide deck. Not a Slack thread. A signed, timestamped, immutable record that this contract was enforced against both systems on this date, with this verdict. Forward it to engineering, finance, and the board.

  • Reproducible. Re-run any historical contract against either system to get the same verdict.
  • Defensible. A bit-for-bit record of what passed, what failed, and which deviations were accepted.
  • Forwardable. Compliance, examiners, partners: same artifact, on demand.
What gets caught

The four ways migrations break, caught before cut-over.

01

Implicit dependencies

A downstream dashboard quietly relied on a column being sorted, or a string being trimmed, or a join being case-insensitive. Limen surfaces it as a contract assertion before anyone migrates anything.

02

Subtle drift

The new pipeline returns the same row counts but different distributions: a percentile, a null rate, a long-tail value disappears. Equivalence catches the deviation; humans decide whether to accept it.

03

Timing changes

The new system is 31 minutes earlier on weekdays, 2 hours later on weekends. Freshness contracts catch the shape change so SLA consumers aren't surprised.

04

Semantic drift

A vendor's "active customer" definition changed. The contract pins the definition; the parallel run flags the day the two systems start disagreeing about who counts.

Get started

Ship the migration with a receipt.

We'll instrument one critical table in your legacy system, extract its implicit contract, and run it against your new system in parallel for two weeks. The receipt is the deliverable.

Book a demo →