Cutover week is where good migration plans either hold or collapse. Use this page when running cutover week without burning the admin team or confusing families. It focuses on stop rules, owner-driven triage, and realistic communication during live classes. A calm cutover is less about perfection and more about controlled decisions.
Start with one non-negotiable: stop rule
If legacy spreadsheets stay editable without a stop rule, your data splits immediately.
Set this before cutover:
- final edit timestamp for old system,
- person allowed to authorise emergency legacy edits,
- exact timestamp when Classia becomes single live system.
Without this, teams spend week two reconciling two truths.
Cutover day sequence that works
Run the day in blocks:
- Final pre-launch validation (classes, families, enrolments, payment settings).
- Source freeze and confirmation message to staff.
- Open Classia for operational use.
- Run first-session attendance and enrolment checks.
- Log issues in one triage queue.
Do not mix validation and live edits in the same 10-minute window.
Launch-week issue triage model
Use one issue log with:
- severity (
critical,high,normal), - impact area (attendance, enrolment, safeguarding, payment, comms),
- owner,
- target fix time.
Fix order:
- child safeguarding and consent risks,
- class delivery blockers,
- payment misstatements and payer visibility issues,
- cosmetic and low-impact data tidy-ups.
Example: safeguarding-critical issue in first session
A child enrolment appears without correct responsible-adult link. Team pauses approval action, assigns safeguarding owner, fixes record link before class-end communication. Other non-critical issues wait.
Example: duplicate participant appears on register
A participant imported twice appears in attendance. Team marks one record for correction in high-priority queue, keeps live register usable, then resolves duplicate after class to avoid rushed in-session edits.
Example: parent payment visibility complaint
A parent cannot see expected due item on day two. Team verifies payer linkage and payment schedule scope, updates mapping where needed, and sends one clear status message with next step.
UK payments cutover communication
During cutover week, payment language must be exact.
Tell families:
- what method is expected (Direct Debit, card, or both),
- when they should expect status changes,
- what to do if payment view looks incorrect.
Do not send broad "everything has moved" emails without method timing context. That usually generates avoidable arrears and support traffic.
Dual-run strategy without operational strain
Short dual-run can help confidence, but only if tightly controlled.
Recommended model:
- Classia is operational source.
- Legacy sheet is read-only reference.
- Any emergency legacy update is mirrored into Classia immediately by named owner.
If the team starts updating both freely, stop and reset cutover controls.
Rollback criteria
Most issues should be patched forward in Classia. Use rollback only for defined critical failures.
Rollback triggers might include:
- class-critical schedule loss,
- unresolved child safeguarding integrity issue,
- widespread payment state failures that cannot be safely communicated.
If rollback happens, communicate clearly and time-box it. Silent rollbacks destroy confidence.
If you are migrating from spreadsheets
Plan one post-cutover review at 72 hours and another at end of week one.
At each review:
- compare active enrolment counts,
- verify child safeguarding links,
- verify attendance continuity,
- verify payment communication outcomes,
- close resolved issues and re-prioritise open ones.
This keeps cutover from becoming an endless "just one more fix" phase.
Avoid these slips
- Launching without a hard source-freeze timestamp.
- Keeping dual-write behaviour open to all staff.
- Treating all issues as equal during first week.
- Sending payment communications before verification checks are stable.
- Rolling back silently without clear owner and timeline.