This checklist is for the week before go-live, when confidence can be high but hidden gaps still exist. It focuses on what must be true for safe operations, not what looks tidy in a spreadsheet. You can run it with one admin, but it works best with a second reviewer for safeguarding and payments. If this list fails, delay launch and fix it now, not during class changeover.
Readiness starts with ownership
If nobody owns each area, readiness checks become wishful thinking.
Assign named owners for:
- class and term structure,
- participant and family links,
- enrolment status accuracy,
- payment setup and communication,
- cutover messaging.
A single person can own multiple areas, but each area needs an explicit decision owner.
Data readiness checks (current term only)
Before go-live, verify:
- current terms and class groups are created,
- class schedule and age ranges are current,
- active participants are present,
- adults and families are linked correctly,
- under-18 records have valid guardian context,
- active enrolments reflect real attendance intent.
Do not block launch because 2019 archived notes are imperfect. Block launch if active records are uncertain.
Example: class structure ready, people links not ready
A studio completed terms and class setup, but 14 under-18 participants still had incomplete family links. They delayed cutover by two days to fix these. It prevented week-one approval failures and parent confusion.
Safeguarding readiness checks
Safeguarding readiness is non-negotiable where children are involved.
Confirm:
- under-18 participant records are family-linked,
- responsible adults are valid and active,
- public enrolment pathways respect parent/guardian rules,
- team knows who handles sensitive corrections.
If you cannot answer these clearly, do not launch public pathways yet.
Example: readiness caught a hidden risk
A martial arts club found that one child-heavy class had public visibility on, but guardian communication notes were outdated. They corrected notes and consent wording before launch, avoiding misleading enrolment expectations.
Payment readiness checks (UK)
For live classes, verify:
- assigned payment profiles are active,
- profile method/scope rules match intended enrolment types,
- provider verification and capability states are checked,
- staff wording for Direct Debit and card paths is ready.
Families care less about your internal setup and more about clear timing: what is due, when it is collected, and how to pay if one method is unavailable.
Example: payment wording fixed before launch
A dance school changed onboarding text from "pay instantly" to clear method-specific wording because Direct Debit timing would not be instant. Support tickets dropped in the first week.
Operational readiness checks
Cutover fails when teams keep editing old sheets after launch.
Set before go-live:
- final source data freeze time,
- cutover window,
- issue logging channel,
- rollback fallback for critical data only,
- stop date for legacy-sheet edits.
Without a stop date, dual-system drift starts immediately.
If you are migrating from spreadsheets
Add a "confidence score" column to your readiness list by area:
- Green: ready to launch.
- Amber: launch only with owner sign-off.
- Red: block launch.
This helps teams avoid optimistic launches based on partial confidence.
Avoid these slips
- Declaring readiness because classes are visible, while family links remain incomplete.
- Letting multiple staff edit legacy sheets during migration week.
- Treating payment verification as a post-launch activity.
- Using generic parent communication instead of method-specific timing.
- Launching without a rollback and ownership plan.