Sources: Featurebase posts from David T / thodl15@gmail.com:
6a209ff3830d0ac0f9009e3c(Migrate existing store events): "There are multiple prior events missing from the old website, you need to migrate those over too."6a209f28a035a111ad254e00(Handle DB migration from old website): "There’s existing deck data hanging out in some old schema in your prior website, you really ought to migrate that over as part of the initial rollout"
PM triage:
- Problem: the rollout may strand existing user-visible event history and deck data if legacy website data is not migrated or intentionally excluded.
- Evidence: two related Featurebase reports from the same submitter; no specific store, event, player, deck IDs, or rollout owner named yet.
- Current workaround: unclear; users may perceive missing historical data as data loss.
- Product decision needed: define which legacy event/deck data must migrate for v1, what can remain archival-only, and who owns validation before rollout.
- 90/10 candidate: identify the smallest user-visible historical dataset required for launch continuity, migrate that path, and document any intentionally unsupported legacy data.
Needs product scoping/decision before implementation:
- Which old website/schema is the source of truth?
- Which data types are launch-blocking vs nice-to-have?
- Concrete examples of missing stores/events/decks to validate against.
