TLDR: I called the advisor before shipping an Airtable data migration — it caught real blockers. Same week I skipped that step on a Shopify sync, and a 30-second query I didn't run would have saved me two production-blocking bugs.

The Setup

Two data migrations, same week, back to back.

First: a full Airtable → Postgres pipeline for a law firm client (a practice management system I've been building). Five phases — inspect.mjs, wipe.mjs, seed, migrate.mjs, verify.mjs — each its own script, each touching live client data.

Second, running parallel: a multi-store Shopify sync for an ecommerce business — a supply chain app unifying inventory from two storefronts — a primary store and a secondary store — into a single products table.

Both felt tight. Both had verify steps. I was moving fast.

Where I Got It Right

Before I declared the Airtable migration done, I called the advisor — the stronger Claude reviewer that sees your full context and looks for what you're too close to see.

It flagged blockers. Real ones.

The receipts are in the commit history: fix: advisor-flagged blockers + flags in migration pipeline, then fix: unblock production migration runtime. Two separate fixes the advisor surfaced before a single lawyer's matter record moved to the new system. Shipped clean because of it.

Where I Didn't

022_multi_shopify.sql shipped at 00:28 EDT on May 13.

I was confident. I even wrote a comment at the top of the migration:

"No SKU overlap between stores, so each product row stays unique per (store, shopify_id)."

Wrong.

A Replenishment Cream SKU and a Kids Gummies SKU both exist in both the primary store and the secondary store as separate products rows — same SKU, nearly identical name. The same retail products are sold through both storefronts. Of course they are.

The downstream damage was instant. The report SQL grouped by COALESCE(canonical_product_id, p.id), assuming each SKU had exactly one product row. With that assumption broken, every report — Velocity, Ledger, Forecast, L10, History — rendered two unlabeled rows for those SKUs, with wildly different numbers.

Two production blockers. The Arc CDP audit caught them before my client's review the next morning, but the point is they were there…

What Would Have Caught It

SELECT sku, COUNT(*) FROM products GROUP BY sku HAVING COUNT(*) > 1;

Thirty seconds. That's it. That query tells you everything before you ship a single line.

I didn't run it. I trusted the comment I'd just written.

Why This Matters to Me

Comments in a migration that encode invariants — "no overlap," "unique per X," "always one-to-one" — are load-bearing assumptions, not documentation.

They're untested hypotheses written at 00:28 when you want to go to sleep.

The advisor doesn't want to go to sleep. And it's specifically good at the thing I'm bad at at midnight: asking whether I've actually verified the assumption the whole pipeline rests on.

The law firm migration taught me what right looks like. The ecommerce migration taught me what skipping the advisor costs. I now treat a pre-ship advisor call the same way I treat phase 4 verify — it's not optional, it's a phase.

Two lessons. Same week. Won't forget either one.