Members and contact details
Migration
Move your club
without losing
the schedule.
Switching tools feels risky because the schedule, staff habits, and payment references all move at once. Lobby treats migration as an operations project, not a CSV upload.
Import preview
Prove the files
before launch.
A staging tenant shows exactly what was imported, what was skipped, and what still needs a staff decision. No public switch happens from an unreviewed import.
book.club.example/admin/importDry run
Import preview
Demo Club · dry run
All checks pass12s
| Source field | Target field | Rows | Status |
|---|---|---|---|
| Playtomic.members | lobby.users | 1 842 | ✓ ok |
| Playtomic.bookings | lobby.bookings | 18 204 / 24 mo | ✓ ok |
| Playtomic.memberships | lobby.clients | 412 | ✓ ok |
| Playtomic.coupons | lobby.coupons | 38 | ✓ ok |
| Stripe.customer_ids | preserved | 1 842 | ✓ ok |
| Stripe.past_payouts | reference-only | — | read-only |
20 496 rows mapped · 0 conflicts · 0 droppedrun.id · mg-2026-04812
The cutover board
Export, import,
verify, launch.
The board is intentionally practical. Every step has an owner, an artifact, and a stop condition.
01
Export
Pull members, courts, classes, bookings, products, and reference payment records from the current tool.
02
Import
Run the files into a staging tenant and keep a written mapping of accepted, skipped, and corrected rows.
03
Verify
Staff check the live week, member samples, class rosters, and payment references before launch.
04
Train
The booking desk runs through create, move, refund, cancel, and member lookup flows.
05
Soft launch
Lobby opens for controlled booking while the previous tool remains available for reference.
06
Public launch
DNS, links, staff scripts, and member communications switch when the operator signs off.
Soft launch
One write target.
One source of truth.
During soft launch, Lobby becomes the write target. The old tool remains available for lookup until the operator signs off on the public launch.
book.club.example/admin/cutoverSoft launch
Parallel run · diagram
liveWrites accepted
Lobby only
Double-bookings
0
Cutover window
04:00 — 04:15
Imported fields
What moves
into Lobby.
Court inventory and court types
Future bookings and recurring bookings
Classes, capacity, and rosters
Membership names and status
Reference payment records where exported
Risk register
Known risks,
named early.
Risk
Dirty member data
Deduplicate in staging and keep skipped rows visible before launch.
Risk
Schedule mismatch
Compare the next operating week manually with staff before cutover.
Risk
Payment references missing
Import reference records only where the source system exposes usable IDs.
Risk
Staff uncertainty
Keep the first launch window staffed and leave rollback instructions in writing.
Deeper playbook
Spreadsheet
migration details.
The migration article turns this cutover model into concrete export, staging import, verification, and soft-launch checklists.
Migration playbook
Migrate from spreadsheets to online bookings without losing the week
Export scope, skipped rows, staff verification, and write-target rules for launch.
Operator questions
The switch,
without mythology.
- Will we lose our schedule?
- No cutover proceeds until staff verify the upcoming schedule in staging. If the schedule does not match, the launch does not happen.
- Can every source system export the same data?
- No. Lobby imports what the current tool can export. Gaps are logged before launch so the operator can decide whether to proceed.
- Is there a rollback plan?
- Yes. The previous tool stays available during the soft-launch window, and public links do not switch until operator sign-off.
- What is the pilot for?
- The pilot proves the import, the staff flow, and the member-facing booking path before the paid rollout starts.
Migration pilot
Bring the export.
Test the cutover.
Pilot before paid rollout, rollback plan in writing