Most migration pain starts here. A spreadsheet row looks simple, but it often combines class data, household assumptions, and payment notes in one place. Classia separates these into explicit records so they can be validated and scoped safely. This guide shows how to map fields once, then enter data with less rework.
Open with one mapping rule
If one source column contains two business meanings, split it before entry.
Example: Parent / emergency contact in one cell is not one field in Classia. It may map to:
- adult contact record,
- family linkage,
- responsible-adult context for child enrolment.
Trying to force it into one destination field creates downstream errors.
Entity map to anchor your migration
Use these destination anchors:
- Account
- Term
- ClassGroup
- Studio
- Teacher
- Participant (participant profile used by the app)
- Adult
- Family
- Enrolment
- Payment profile assignment intent
If a source column cannot be tied to one anchor, pause and classify it before entry.
Example mapping patterns
Pattern 1: timetable sheets
Source columns:
Class name,Day,Time,Venue,Level,Max spaces
Destination:
- ClassGroup + Studio + Term with schedule fields and capacity.
Pattern 2: child register sheets
Source columns:
Child name,DOB,Parent name,Parent email,Phone,Household
Destination:
- Participant + Adult + Family links.
Add responsible-adult assignments at enrolment stage for under-18 participants.
Pattern 3: payment tracker sheets
Source columns:
Billing method,Installments,Due date,Paid,Arrears note
Destination:
- Payment profile configuration intent and due-item lifecycle context.
Do not paste historical arrears notes into live profile names.
Upgrade-ready asset: migration worksheet structure
Use a worksheet with these columns:
- Source tab
- Source column
- Example value
- Destination entity
- Destination field
- Transformation rule
- Required at go-live? (
yes/no) - Owner
- Verification status (
unchecked/checked/blocked) - Notes
Add one worksheet section each for:
- account/profile,
- terms/classes,
- participants/families/adults,
- enrolments/statuses,
- payments.
This structure is strong enough to become a future downloadable migration worksheet without rewriting content.
Transform rules to decide early
Define rules before entry starts:
- name normalisation (capitalisation and spacing),
- email normalisation (lowercase, duplicate handling),
- date format conversion,
- phone format cleanup,
- status mapping dictionary.
If you skip transform rules, two admins entering the same data can produce different results.
Safeguarding mapping checks
Where children are involved, mapping quality directly affects safeguarding.
Check that mapped data supports:
- family linkage for under-18 participants,
- responsible-adult assignment eligibility,
- clear parent/guardian contact routes,
- no accidental public exposure fields.
Ambiguous guardian fields should be resolved before go-live, not during approval queues.
If you are migrating from spreadsheets
Keep one source snapshot and never map against a moving file. Lock a copy for migration and track any post-snapshot changes in a delta tab.
For a studio with 85 active participants, this usually prevents 20 to 30 duplicate corrections in first two weeks.
Avoid these slips
- Mapping composite columns into single unrelated fields.
- Allowing each staff member to invent their own status mapping.
- Ignoring duplicate emails in adult or participant columns.
- Mapping child contacts without preserving family context.
- Forcing unresolved fields into convenient but wrong destinations.