Pilot Migration + Cutover Plan

Pilot site: HeyAustin.com

Decided by the user: HeyAustin. The original recommendation below (CrestedButte, for blast-radius reasons) was the lower-risk pick, but HeyAustin is the flagship brand and the one with the richest data (233 venues, 1,212 events, the most complete recon, and the venue/rental/event overlap findings against 6thStreet) — starting here means every subsequent site is a strict subset of what's already been built and validated.

Original lower-risk rationale, kept for reference: CrestedButte is smallest by content volume (177 venues/741 events vs. HeyAustin's 233/1,212) and in a different market than the Austin cluster, so a mistake there would have been more contained. Worth remembering if HeyAustin's build surfaces problems — CrestedButte remains the fallback "prove it small" option.

Phases

A. Data migration (no user-facing change yet) ETL script pulls all HeyAustin content via the existing REST APIs (already reverse-engineered during recon — listar/v1/place|event|blog/list plus wp/v2/rental) into the new Supabase schema. Read-only against the live site, same as all recon so far — see the standing isolation constraint: the live WordPress install is never written to. Run repeatedly/idempotently during development, not as a one-shot script, since it needs to re-sync as the live site keeps changing during the build.

B. Build against real migrated data New Next.js frontend + admin portal stood up on a staging domain (not the real domain yet), pointed at the migrated Supabase data. This is where Tasks 1-5's designs actually get built and become verifiable against real content instead of hypothetical.

C. Ingestion pipeline shadow mode Before trusting the AI ingestion pipeline on real content, run it in parallel with the existing Facebook Events importer for a couple weeks without publishing anything — compare its output against what's already live, measure false-positive/miss rate. Don't cut over the platform and trust an unproven automation pipeline in the same step.

D. SEO validation (before DNS changes)

E. Cutover DNS switch during a low-traffic window, TTL lowered in advance so a revert is fast. Old WordPress stack stays warm and read-only (not deleted) for a defined rollback window — recommend 2-4 weeks — so reverting DNS is a real option, not a one-way door.

F. Observation period 4-6 weeks watching Search Console (crawl errors, ranking movement) and analytics before calling the pilot done and moving to the next site.

G. Roll out to remaining 3 sites Same playbook, informed by whatever the pilot actually broke. Since HeyAustin went first (the highest-stakes brand, not the lowest), the remaining 3 are comparatively lower-risk by content volume and traffic — LakeTravis, CrestedButte, and 6thStreet (6thStreet last, given its migration needs extra work regardless: no REST-accessible events, a different plugin stack, and the venue/rental dedup against HeyAustin from the data audit).

H. Mobile apps Both apps get pointed at the new /v1 API — planned as its own workstream since app store review adds lead time apps' backend teams don't control. Can happen per-brand alongside each site's web cutover, or batched at the end; worth deciding once you know how the two apps are actually built (same codebase per brand, or genuinely separate apps?).

I. Decommission Once all 4 sites + both apps are stable on the new stack: retire the WordPress installs and their AWS resources. This is also where the current ~$400/mo cost actually changes — expect to run both stacks in parallel (temporarily higher combined spend) through the observation periods, with savings only realized after decommission, not at cutover.

Rollback plan

What "done" looks like for the pilot before moving on