The failure mode is not technical. Schools rarely fail to import a CSV.
What actually happens is that the school tries to move admissions, timetables, attendance, invoicing and payroll in the same fortnight, everything is half-entered, staff cannot find anything, and within a month someone has reopened the old sheet "just for now". Now you are running two systems, which is worse than either.
The fix is to move one thing at a time and to accept that for a few weeks the new system will be visibly incomplete.
Week one: students and parents only
Import the student list and nothing else. Names, dates of birth, parent name, parent email and phone, current status.
Do not import history. Not old attendance, not past invoices, not notes from two years ago. This is the single most common way a migration stalls: someone decides the archive has to come across, spends nine days cleaning it, and the project loses its momentum before anyone has used the software for real work.
Your old files still exist. They remain perfectly good for looking things up.
The one thing to insist on: parent email addresses. Without them there is no portal link and no progress report, and you will be back to filling them in one at a time for a year.
Week two: courses, classes and this term's timetable
This term only. Not last term, not the term you are planning for next year.
Build the courses, create the classes, enroll the students you just imported, then generate the sessions. At the end of this week the timetable on screen should match the timetable on the wall exactly. If it does not, fix it now — every later stage assumes this is correct.
This is also when clashes surface. Most schools discover at least one room double-booking they had been absorbing manually for months.
Week three: attendance goes live, and the sheet gets closed
Pick a Monday. From that Monday, attendance is taken in the new system by everyone, with no parallel copy.
This is the hardest week and the one that decides the outcome. A parallel copy feels safe and guarantees failure, because the moment something is quicker in the old sheet, the old sheet wins. There is no version of this that is comfortable; there is only doing it on a date everyone knows in advance.
Tell teachers a week beforehand, show them once, and be present that Monday.
Week four: invoicing
Start with the current billing cycle only. Issue this month's invoices from the new system; leave outstanding older invoices where they are and let them close out in the old records.
Trying to migrate an open receivables ledger is how migrations turn into audits. You will be reconciling two systems for a month and trusting neither.
After that: whatever is next
Payroll, approvals, the parent portal, the materials library, reporting. By now the daily work runs in one place, so each of these is an addition rather than a disruption, and it can wait for a quiet week.
Two rules for the whole thing
One person owns it. Not a committee. Somebody has to be able to say "we are doing attendance in the new system from Monday" and have it stick.
Do not start in the two weeks before a term begins. That is when your staff have the least capacity and the most to lose. Mid-term is unglamorous and much safer.
Four weeks is realistic for a single campus. Multi-campus groups should complete the entire sequence at one campus first, then repeat it — running the same stage simultaneously across three sites means three sets of problems arriving at once with nobody yet experienced enough to solve them.
If you want to try the order above with your own data, the trial runs fourteen days with every Growth feature and no card.