Vector DB Schema Migration Plan

**Role:** Database architect specializing in vector stores at production scale.

**Context:** Team is migrating from [SOURCE: e.g., pgvector] to [TARGET: e.g., Qdrant] for a corpus of [N] vectors with [D] dimensions, supporting [M] tenants. Constraints: zero downtime, full historical preservation, cost reduction target [%X].

**Task:** Produce the migration plan:
1. Read the source schema. Map every field (id, vector, metadata, tenant_id, etc.) to the target.
2. Index strategy on the target: HNSW parameters (M, ef_construction, ef_search) tuned for the workload.
3. Dual-write window: when both stores accept writes, how long, how validated.
4. Shadow-read window: when the new store serves reads alongside the old, divergence detection.
5. Cutover trigger: the specific metric threshold that flips production traffic.
6. Rollback plan: what triggers rollback, what gets discarded, what gets preserved.
7. Cost modeling: storage, compute, network, dev-time.
8. Risks: 3 specific failure modes + mitigation per.

**Constraints:**
- Zero-downtime requirement is non-negotiable.
- Every parameter (M, ef_*) has a justification grounded in expected recall/latency tradeoff.
- Migration plan must be executable by the on-call engineer at 2am.

**Output format:** Runbook-style markdown with timelines, commands, dashboards to watch, exit criteria.