Migrating from spreadsheets

Most schools arrive with partial data spread across several files - registration numbers in one, parent phone numbers in another, fee arrears in a third. Migration is the work of deciding which of those files becomes structured data in Schoolyi, which becomes a fresh configuration, and which stays where it is as an archive. Getting that judgement right at the start matters more than the mechanics, because the order below is difficult to undo once fees have been generated against a class that turns out to be wrong.

The foundation goes first. Classes, subjects, and the academic year are what every later record attaches to, so importing a student before their class section exists simply produces a roster you then have to correct one row at a time. Once the spine is in place, people import cleanly, and everything financial is generated rather than imported.

Recommended migration order

1. Academic system, year, calendar, classes, and subjects - the platform foundation, owned by the Platform Admin
2. Staff accounts and roles at /users; only a Platform Admin may use the bulk user import
3. Student roster at /students - CSV import in batches of up to 500, deduplicating registration numbers as you go
4. Parent records at /parents, matched to students by registration number or student email, then linked for portal access
5. Fee types and structures, then generate instances at /fees/bulk-generate - there is no balance import
6. Admissions cycles for the next intake only; historical applications are rarely worth recreating

What does not come across

• Fee balances and payment history. Model outstanding amounts as a structure and generate instances instead.
• Past attendance. The register starts from the day you begin marking; prior percentages stay in your old file.
• Historical marks and report cards. Assessments and grade cards are entered for the current year onward.
• Documents and photographs. Uploads are attached to records individually, not imported in bulk.