Rehearse a schema change on a preview before prod

A schema push on Convex validates every existing document against the new schema and FAILS the push if any row doesn't conform — a real data-conformance gate. The safe way to use that gate is to let it fail on a rehearsal copy, not on prod. This capability turns a preview deployment into that copy: seed it with a prod snapshot, push the new schema + run the backfill there, watch the gate, and only promote once it's green. It composes deploy-guard (target classification), migrate (the optional-then-tighten pattern), and @convex-dev/migrations (the batched, resumable backfill).

Workflow

PRECONDITION: preview deployments need a Preview Deploy Key (dashboard → Project Settings → Deploy Keys → Preview) exported as
```
CONVEX_DEPLOY_KEY
```
before any
```
--preview-create
```
/
```
--preview-name
```
deploy — a plain
```
npx convex login
```
session cannot create previews, and this is a paid-tier feature. If no preview key is available, fall back to rehearsing on the personal dev deployment seeded with the snapshot, and say so.
GUARD: deploy-guard — classify + announce the SOURCE (prod, being read) and the eventual TARGET (prod, being changed); get the fresh explicit yes for the prod promote up front and confirm the plan.
SNAPSHOT the source data read-only:
```
npx convex export --path snapshot.zip
```
(from the deployment holding the real data; add
```
--include-file-storage
```
only if the migration touches files). This is a read; it changes nothing.
CREATE the preview FROM THE PRE-CHANGE CODE — do this BEFORE editing schema.ts, so the preview starts on the schema the snapshot data already conforms to:
```
npx convex deploy --preview-create migrate-<slug>
```
(needs the preview key; auto-expires ~5 days). Seed it:
```
npx convex import snapshot.zip --deployment migrate-<slug>
```
(import targets a deployment by NAME with
```
--deployment
```
; there is no
```
--preview-name
```
flag on import). The import succeeds because the data still matches the old schema.
REHEARSE on the preview, in the migrate order — each push is
```
npx convex deploy --preview-name migrate-<slug>
```
(re-deploys to the SAME preview, keeping its data; NOT
```
convex dev
```
, which targets personal dev): (a) make the new/changed field OPTIONAL and deploy — if existing rows violate it the push FAILS HERE on the copy with the offending shape; fix and re-push until green. (b) write a @convex-dev/migrations backfill and run it against the preview; verify every row is now valid. (c) tighten the validator (required / narrowed union) and deploy again — the gate now passes because the backfill ran.
VERIFY on the preview: run the app's functions against the migrated data (MCP
```
run
```
/
```
runOneoffQuery
```
pointed at the preview, or a smoke query) to confirm behavior and shape.
PROMOTE only on the fresh explicit yes from step 1: apply the SAME sequence to prod (optional schema → backfill → tighten). Because it already succeeded on prod-shaped data, the prod push repeats a proven run. Keep the snapshot as the rollback artifact (
```
npx convex import snapshot.zip --replace --prod
```
); state plainly that data written after the snapshot is lost, so keep the promote window short.
CLEAN UP: the preview auto-expires; delete the local snapshot when done (it holds real data — treat it as sensitive, never commit it).

Rules

Create the preview from the PRE-CHANGE code and seed the snapshot BEFORE editing schema.ts — so the import conforms and the conformance gate then fails on the copy (not prod) when you push the change; each preview push is
```
deploy --preview-name
```
, import targets it with
```
--deployment
```
.
Follow the migrate order every time: optional field → push → backfill → verify → tighten → push; skipping 'optional first' makes the very first push reject existing rows.
The prod promote needs a fresh explicit yes (deploy-guard) and is a REPEAT of the proven preview run, not a new attempt.
Keep the prod snapshot as the rollback artifact; state plainly that a snapshot-restore loses data written after the snapshot, so keep the promote window short.
Treat the exported snapshot as sensitive real data: delete it locally when finished; never commit it.
Backfills go through @convex-dev/migrations (batched, resumable, dry-runnable), not ad-hoc one-shot mutations over a whole table.
This is the rehearsal-and-promote flow; for the plain 'explain optional-then-tighten' guidance with no live data, that's migrate.

convex-migrate-rehearse

NPX Install

Tags

SKILL.md Content

Rehearse a schema change on a preview before prod

Workflow

Rules