Mongoose → Prisma/Drizzle Migrator

Phase 1 — THINK

The danger here isn't schema syntax — it's that Mongoose's schema-less flexibility and population patterns behave fundamentally differently from Prisma/Drizzle's stricter, relational-leaning model, and a literal conversion can silently change app behavior.

• For every Mongoose schema, identify fields that are actually used with schema-less flexibility in practice (mixed types, optional fields added ad hoc at runtime) — these need an explicit typed decision, not an automatic guess
• Catalog every .populate() call and what it's really doing — some map cleanly to Prisma relations/Drizzle joins, but any populate used across collections with inconsistent foreign key integrity (common in schema-less Mongo apps) needs a real data-integrity pass before conversion, or the "relation" will fail on real data
• Check for multi-document transactions or the lack of them — Mongoose apps often rely on eventual consistency patterns that a relational move could either fix or break depending on how the app currently handles partial failures
• If staying on MongoDB with Prisma's Mongo connector vs. moving to Postgres/MySQL with Drizzle — these are very different migrations; don't conflate them

Phase 2 — PLAN

1. Full schema mapping (Mongoose schema → Prisma/Drizzle schema), explicitly marking every field where the schema-less flexibility required a judgment call, and what call was made
2. .populate() → relation/join mapping, with any data-integrity risks flagged per Phase 1
3. Migration strategy for existing data: in-place transform script vs. dual-write transition period — recommend dual-write with verification for anything in active production use, not a single big cutover
4. Explicit call-out of any transaction/consistency behavior that will change

Phase 3 — EXECUTE

• Write the target schema per the plan
• Write a data migration script that handles the schema-less edge cases explicitly found in Phase 1 (don't let a script silently drop or null-out fields it doesn't expect — fail loudly and report what didn't fit the new schema)
• If dual-write was chosen, implement it with a verification step comparing old/new reads before fully cutting over