61 lines
3.2 KiB
Markdown
61 lines
3.2 KiB
Markdown
# verify-cutover-checklist
|
|
|
|
Verification checklist for a v6 → Prisma Next cutover: the data never moves — only the code does.
|
|
|
|
## Priority
|
|
|
|
CRITICAL
|
|
|
|
## Why It Matters
|
|
|
|
A v6 → Next migration is a *client and workflow* migration against the **same MongoDB
|
|
database** — there is no data export/import step, and introducing one (or pointing the new
|
|
stack at a fresh database) turns a code migration into an outage. The checklist below keeps
|
|
the cutover observable and reversible.
|
|
|
|
## Ground rules
|
|
|
|
- **No data moves.** The Next contract is authored to describe the existing collections;
|
|
both stacks read the same database during the staged phase.
|
|
- **v6 stays runnable until cutover is verified.** Do not delete the v6 client, schema, or
|
|
dependencies until the checklist passes.
|
|
|
|
## Checklist
|
|
|
|
1. **Same database, verified:** the Next config points at the same connection string /
|
|
database name the v6 app uses (minus v6-specific URL parameters that the `mongodb@^7`
|
|
driver rejects — validate the URL with the driver first).
|
|
2. **Server floor:** MongoDB server is 8.0+ (Next's requirement; v6 tolerated older).
|
|
Confirm before authoring any contract.
|
|
3. **Contract round-trip on a copy:** on a staging copy (or `mongodb-memory-server`), emit
|
|
the contract, run plan → migrate → verify → sign, and confirm `verify` passes against
|
|
data copied from production shape. Verification failures here are contract-mapping bugs,
|
|
not database problems.
|
|
4. **Index parity:** enumerate indexes on every collection (`db.collection.getIndexes()`)
|
|
and confirm the Next contract declares the same set — v6 `db push` may have created
|
|
indexes the new contract must re-declare, or verification and query performance will
|
|
diverge.
|
|
5. **Validator impact assessed:** Next emits closed `$jsonSchema` validators by default;
|
|
confirm legacy documents (extra fields, drifted shapes) pass them on the staging copy
|
|
before applying to production.
|
|
6. **Storage-name addressing audited:** every ported call site uses collection storage
|
|
names (`db.orm.users`), not model names (see `schema-contract-mapping.md`).
|
|
7. **Transaction inventory mapped:** grep the v6 app for `$transaction`; each hit gets a
|
|
driver-session equivalent (the `mongodb` driver is directly available; the façade wrapper
|
|
is expected soon — see `client-api-mapping.md`).
|
|
8. **Raw call inventory mapped:** every `$runCommandRaw` / `findRaw` / `aggregateRaw` call
|
|
has an explicit Next-side replacement (`mongoRaw(...)` lane or pipeline builder).
|
|
9. **Staged read-only soak:** run the Next stack read-only against staging/production data
|
|
alongside v6 and compare outputs before allowing writes.
|
|
10. **Cutover + rollback:** switch writes to Next only after the soak; keep the v6 branch
|
|
deployable as the rollback path. Rolling back is a code rollback — the data was never
|
|
moved.
|
|
|
|
After cutover, install and follow Prisma Next's own skills for ongoing work (see the
|
|
hand-off rule in `SKILL.md`).
|
|
|
|
## References
|
|
|
|
- [v6 MongoDB documentation](https://www.prisma.io/docs/orm/overview/databases/mongodb)
|
|
- Prisma Next migrations + queries skills — authoritative for the Next side; verified @ `a2791c5dd59d579b4b3052942ae7f8fe5e2ee852`
|