1 · System snapshot
What actually exists, as verified from code and infrastructure — not from the docs.
V1 (live, revenue-bearing) V2 (target)
────────────────────────── ───────────────────────────
AWS serverless (Lambda/API GW) FastAPI services
DynamoDB: identity, payments, ──ETL──▶ Postgres: 49 tables across
booking history 4 graph layers (entities,
Firebase Auth ────────auth bridge───────▶ relationships, momentum,
Stripe (137 paid meetings) intent)
LLM discovery over structured
profile evidence
130+ legacy accounts, 137 completed paid consultations, and authentication continuity must survive the cutover. V1 stays publicly available during the transition.
2 · Risk map
Every material risk found, ranked by blast radius × likelihood. Each is tied to a specific component — nothing generic.
| ID | Severity | Risk | Where it lives | Blast radius if it fires |
|---|---|---|---|---|
| R1 | CRITICAL | Auth continuity break at cutover — Firebase session/UID mapping is assumed, not verified, for pre-2024 accounts. | Firebase → Postgres identity bridge | Legacy users locked out of paid history; support storm; trust loss in the exact cohort V2 needs to retain. |
| R2 | CRITICAL | ETL is not idempotent — a partial failure and re-run can duplicate meetings and credit records. | DynamoDB → Postgres migration jobs | Double-counted paid consultations; corrupted credit ledger; manual reconciliation across 49 tables. |
| R3 | HIGH | No rollback path once V2 begins accepting writes — reverse migration was never designed. | Cutover plan | Any post-cutover defect becomes a forward-fix emergency instead of a controlled revert. |
| R4 | HIGH | LLM discovery has no evaluation harness — regressions in goal-to-profile resolution ship silently. | NL discovery layer over the graph model | Core V2 differentiator degrades without anyone noticing until users churn. |
| R5 | MEDIUM | Migration has no per-stage observability — success is inferred from absence of errors, not from counts proven to match. | ETL pipeline | Silent data loss discovered weeks later, when it is expensive to trace. |
3 · Remediation plan
The top risks translated into bounded, sequenced work items. Written so any senior engineer — not just me — could execute them.
F1 · Verified identity-bridge dry run
addresses R1 · ~3 daysEnumerate every legacy account, resolve its Firebase UID against the V2 identity table in a read-only pass, and produce an exceptions list before any cutover. Accounts that fail mapping get a manual re-link flow, designed now, not during the incident.
Acceptance100% of legacy accounts either map cleanly or appear on the exceptions list with a re-link path.
F2 · Idempotency keys + migration ledger
addresses R2, R5 · ~4 daysGive every migrated record a deterministic source key; upsert instead of insert. Add a migration ledger table recording per-stage counts (read / written / skipped / failed) so every run is auditable and safely resumable.
AcceptanceRunning the full ETL twice produces byte-identical row counts; ledger totals reconcile against DynamoDB source counts.
F3 · Dual-write window with nightly reconciliation
addresses R3 · ~5 daysInstead of a hard cutover, run a bounded dual-write period: V1 remains the system of record while V2 shadows writes. A nightly reconciliation job diffs the two and reports drift. Rollback becomes "stop writing to V2" — cheap and boring.
AcceptanceSeven consecutive drift-free nights before V2 is promoted to system of record.
F4 · Minimal eval harness for discovery
addresses R4 · ~3 daysFreeze 50 real goal-resolution queries with expected profile matches into a regression suite that runs in CI. Not a research project — a tripwire that catches silent degradation of the product's core promise.
AcceptanceSuite runs on every merge; a resolution-quality drop below the frozen baseline fails the build.
4 · Recommendation
Do not cut over on the current plan. The migration is architecturally sound — the four-layer graph model is the right target — but R1 and R2 make the current execution path an unacceptable bet on revenue-bearing data. Execute F1–F3 first (~2 weeks), then migrate with the ledger proving every count. F4 ships alongside, so the discovery layer V2 is being built for is protected from day one. Outcome when this plan was executed on the real system: 130+ accounts and all 137 paid meetings migrated with zero loss and zero auth interruptions.