Step 01
Export the data that runs the next week
Start with the data that can break operations if it is wrong. Historical cleanup can wait; the next bookable week cannot.
Courts, court groups, opening hours, closures, and class-only blocks
Future bookings, recurring bookings, class rosters, and waitlists
Members, contacts, membership names, status, and access notes
Products, prices, tax labels, coupon references, and payment IDs where available
Step 02
Run a staging import with visible skipped rows
A useful import preview shows accepted rows, corrected rows, skipped rows, and the reason behind every skip. Operators should not have to trust a silent migration job.
Map source columns into court, booking, user, membership, and payment-reference records.
Keep payment history reference-only unless the source exports processor-safe IDs.
Preserve skipped rows as an operator review list instead of hiding them in logs.
Step 03
Verify the calendar with staff before DNS changes
The desk team should compare the staged Lobby calendar against the old source for a normal operating week, including peak hours and recurring programs.
Open the same day in both systems and compare every court row
Create, move, cancel, and refund a test booking in staging
Look up three known members and confirm status, notes, and booking history
Confirm the member-facing URL, email sender, and staff launch script
Step 04
Make one system the write target during soft launch
Parallel systems are useful for lookup, not for writing. During soft launch, Lobby should become the write target while the previous source stays read-only for reference.
Freeze edits in the source tool before the final import.
Switch public booking links only after operator sign-off.
Keep rollback notes in writing for the first staffed launch window.