Use this as your starting point when you are a studio owner or operations lead handling migration after teaching hours, often with limited time. It explains how to move from spreadsheets or another system into Classia without breaking daily delivery. The emphasis is phased migration, clear ownership, and safety where children and guardian records are involved. If you run this well, you can start a term in Classia without spending every evening fixing data.
Start by narrowing scope, not widening ambition
The most common migration failure is trying to move everything at once.
In real studios, first-term success usually comes from moving only what the team needs to run classes this month:
- account profile and public settings,
- terms, classes, studios, teachers,
- active participants and families,
- active enrolments and statuses,
- payment setup used by live classes.
Leave low-value history until your day-to-day operation is stable.
What Classia migration looks like in practice
Classia is designed around explicit records and relationships, not one large spreadsheet row. That means migration is a mapping and validation task more than a copy task.
Typical record path:
- account and settings,
- terms and class groups,
- participants (participant profile used by the app), adults, and families,
- enrolments with status and dates,
- payment profiles and schedule outcomes created through approval flows.
This is more work than pasting rows, but it produces data you can trust in week six.
A realistic migration timeline for a small UK studio
For a studio with 12 classes and around 80 to 100 active pupils, a practical timeline is:
- Week 1: clean source sheets and assign migration owners.
- Week 2: load structure and current participants/families.
- Week 3: validate enrolments, payment setup, and public links for go-live.
Some teams compress this into one week, but only when source data is already clean.
Migration scenarios
Example: dance school with sibling-heavy enrolments
A school in Leeds had 92 active participants and many siblings across classes. They migrated terms/classes first, then family and adult links, then participant records. Enrolments came after responsible-adult checks. fewer child record errors in approvals and fewer parent portal issues.
Example: martial arts club with mixed adult and child classes
A club in Kent migrated only active classes and active participants first. Adult self-managed participants and under-18 participants were split clearly during enrolment validation. support team could explain responsibilities cleanly from day one.
Safeguarding controls during migration
Migration is a safeguarding task when children are involved.
Before go-live, verify:
- under-18 participants are linked to at least one family,
- under-18 enrolments have a valid responsible adult,
- responsible adult is active and in the same account and family context,
- public enrolment settings are deliberate, not accidental.
Do not leave these for "after launch". That is when the queue is busiest and error cost is highest.
UK payments during migration
Payment changes create the biggest parent confusion if you over-communicate too early.
Use this rule:
- configure and verify payment readiness first,
- communicate billing method and timing second,
- invite payer actions third.
For UK families, be explicit about Direct Debit timing windows and card fallbacks where used. Avoid saying "all set" if capability or verification checks are still pending.
Migration governance that works in small teams
You do not need a formal PMO. You do need clear ownership.
Assign:
- one migration owner,
- one safeguarding checker,
- one payments checker,
- one sign-off checkpoint before cutover.
If the same person must do all roles, run them in separate sessions so review still happens.
If you are migrating from another software tool
The same phased logic applies. Export quality is rarely perfect, and field names often hide assumptions.
Use Classia entity language as the destination model:
- Participant
- Adult
- Family
- Class
- Term
- Enrolment
- Payment profile / schedule context
Map each source field once, then test on a pilot class before full rollout.
First-term split that keeps pressure manageable
Teams that migrate everything together usually lose momentum by day three. A phased split is calmer and more reliable:
- Phase A (live delivery essentials): terms, classes, studios, teachers, active participants, family links, active enrolments, live payment setup.
- Phase B (stability improvements): inactive enrolments still referenced by staff, archived participants still relevant for safeguarding context, priority legacy notes.
- Phase C (historic tidy-up): older-year data and low-value legacy tabs.
For studios planning Autumn, Spring, and Summer terms, this often means launching Autumn operations first and migrating older history after the first two weeks of stable delivery.
Decision matrix: migrate now or defer
Use this quick matrix in planning calls:
- Is this record needed to run a class this week?
- Is this record needed for a safeguarding or guardian decision?
- Is this record needed for payment decisions this month?
If all answers are no, defer.
If one answer is yes, migrate now with named owner sign-off.
If answers are mixed, mark the record group amber, assign an owner, and set a date before expanding public promotion.
This prevents teams from polishing low-value history while active classes still need reliable enrolment, attendance, and billing records.
A practical rule for small teams is to cap migration admin at two hours per evening during go-live week. If unresolved records exceed that window, park them in a dated backlog and continue only with records that affect tomorrow's classes.
What this is not designed for
This approach is not designed for one-click bulk import expectations, unowned data cleanup, or undefined cutover dates. If you need full historical migration, run it as a second phase after live operations are stable.
Related guides
- Migration readiness checklist
- Mapping spreadsheet columns to Classia entities
- Go-live cutover with minimal disruption
- Getting started
- Entities and record relationships
- Participants, families, and responsible adults
Related feature
FAQ
Does Classia have one-click spreadsheet import for all records?
Not as a complete one-click migration flow. Most studios migrate in phases using existing record screens and controlled checks.
What should be migrated first?
Current-term essentials first: terms, classes, active participants, linked families, responsible adults, and live enrolments.
How long does migration usually take for a small UK studio?
Many studios complete a reliable first-phase migration in one to two focused admin weeks, depending on data quality.
Should we migrate historical data before going live?
Usually no. Bring in current operational data first, then add history only where it supports active decisions.
How do we avoid safeguarding errors during migration?
Verify under-18 family links and responsible-adult assignments before approving enrolments or opening public links.
When should we stop using the old spreadsheet?
After a defined cutover checkpoint where attendance, enrolment status, and payment visibility are stable in Classia.