You have already decided. The spreadsheets have to go and something proper takes their place. What nobody warns you about is that migrating from spreadsheets to a school management system has almost nothing to do with the software you chose — it is about the years of data sitting in files nobody has read end to end since two directors ago.
This is the project guide, not the business case: what to audit first, what to migrate and what to archive, how to handle the students who exist three times under slightly different names, when in the academic year to cut over, and how long to run both systems side by side. It includes the parts that are genuinely unpleasant, because those are the parts that derail migrations.
Step one: audit what you actually have
Ask an institution how many spreadsheets it runs on and you will hear "three or four". Then you sit down and count.
This year's enrolments. Last year's, kept in case someone asks. The master student list. A class list per level. Attendance. The teacher timetable. Teacher hours, which feeds payroll. Payments received. Outstanding balances, which is a different file and does not quite agree with it. Exam results. Agent commissions. Parent contacts.
That is a dozen, and it does not count the WhatsApp groups where half the operational decisions actually happen.
One of those files is load-bearing: if it were deleted this afternoon the institution would stop — not slow down, stop. It is rarely the one people name first. Usually it is the master student list, because it holds the only column connecting a person to a level and a fee.
Go file by file. Record what it holds, who edits it, and two answers: if this disappeared today, what stops, and who is the only person who fully understands it? Flag the files that duplicate each other, because loading them all produces contradictory imports, and the columns nobody can explain, because every long-lived workbook has a code or a colour-coded row whose meaning left with someone.
Then flag the data that is not in a file at all: the payment plan agreed by email, the student billed differently because of a deal made two years ago, the level someone was moved into mid-week and never recorded. That is what turns up three weeks after go-live as "the system is wrong".
Step two: decide what moves and what gets archived
The instinct is to bring everything. Resist it. Everything you bring is something you have to clean, and something that can be wrong in the new system.
What you need in order to operate on Monday, migrate. Active students, current enrolments, classes and timetable, open balances, results in progress.
What you only need in order to answer a question, migrate as a summary and archive the detail. Past students, their enrolment dates and final results, yes. Every individual attendance mark from six years ago, almost certainly not.
What you keep only because deleting it felt wrong, archive.
If an accrediting body or your national data protection authority sets rules about what you must keep and for how long, that is the one input you cannot decide internally. Ask them, not your software vendor, before you draw the line.
Archiving properly means more than leaving the old files where they sit. Export to a stable format, store them in one named location, restrict who can open them. An archive everyone can still edit is a second system with no rules.
Step three: clean the data before it moves, not after
Cleaning in the spreadsheet is fast: find-and-replace, sort, filter, and a team already fluent in the tool. Cleaning after the import means fixing records one at a time, in a system nobody knows yet, while it is live.
Four things need fixing. One column, one meaning — the column called "Notes" holding a payment arrangement, an allergy and a complaint about a teacher. Names — given and family name in separate columns, two family names handled consistently, one decision about nicknames versus the legal name on the certificate. Dates and statuses — a column mixing day-first and month-first rows imports silently and wrongly, and "Active", "ACTIVE", "yes" and a blank cell that also means active have to become one vocabulary. Money — amounts stored as text with the currency symbol attached, and balances adjusted by hand that no longer equal invoices minus payments.
The duplicate student problem
Every institution has duplicates and underestimates how many. A student left, came back two years later and was typed in fresh. One arrived through an agent and also enquired directly. Two campuses each created a record.
No vendor can do this part for you. Same name and same date of birth might be one person entered twice, or two cousins in the same programme. Software that merges automatically on a match destroys history silently — attendance attached to the wrong person, a payment credited to a student who never made it. A duplicate is annoying; a bad merge is a dispute you cannot unpick.
The approach that works is unglamorous. Build a candidate list by sorting on several keys — family name, email, phone, date of birth — because each sort surfaces a different set of pairs. Put a human on each pair: someone who knows the institution, not whoever has the most free time. Choose which record survives before you import. Then decide what happens to the history hanging off the losing record, because attendance, payments and results either move with it deliberately or are dropped deliberately.
Budget real time for this. It is the most time-consuming task in the migration, it cannot be delegated, and it quietly determines whether the new system gets trusted.
Step four: choose your cut-over point
You have two calendars, academic and financial, and the cut-over needs to be quiet in both. They rarely line up.
If you run terms, the end of one is the obvious window. Class lists get rebuilt anyway and results for the closing term are final, so the new year starts clean in one place.
If you run rolling intakes, there is no quiet month, and pretending otherwise is how these projects go wrong. Two honest options: go live in the trough and accept that your first heavy intake lands on a system a few weeks old, or go live right after your peak so the team has a long stretch of low volume to become fluent, at the cost of one more busy season on spreadsheets. The second is usually the better trade, and the one people talk themselves out of.
Whatever you run, cut over on a billing boundary. Migrating mid-cycle leaves invoices for the same month split across old files and new. Bring open balances across as balances; archive the payment history that produced them rather than rebuilding it. And rule out an inspection window, an audit, or the fortnight before reports go to families.
Step five: run parallel, and set the date you stop
Running parallel means entering the same data twice on purpose, for a bounded period. It is insurance, not a phase of the project, and one billing cycle or one complete intake is usually enough. During it, check three things rather than everything: does the enrolment count match on both sides, does money collected for the period match, and does a class register produce the same names? If those three agree, the rest almost always does.
Then the part that matters more than the parallel run itself: name the stop date before you start, put it in writing, and tell everyone. Parallel running without an end date does not end, it decays. People quietly stop updating one side — usually the new one, because the old file is faster for them — and you finish with two systems that are both wrong.
On the stop date, make the spreadsheets read-only. Not deleted, read-only. It costs nothing, it removes the temptation, and it is the single most effective action in the whole migration.
What "done" looks like
Not the day you go live. Done is a set of observations:
Nobody has opened the old files for real work in a full billing cycle.
A new enrolment is entered once and shows up in class lists, attendance and finance without anyone re-typing it.
You can answer "how many are enrolled right now" and "who owes us money" from one screen.
The load-bearing spreadsheet has been read-only for weeks and nobody has asked for it back.
That last one is the real test.
The parts that are genuinely painful
Nobody says these out loud in a sales call.
Double entry, for weeks. The parallel period is extra work on top of a normal workload, and the main reason teams lose enthusiasm halfway. Plan for lower output rather than being surprised by it.
The duplicate decisions. Hours of judgement calls, one pair at a time, made by someone senior enough to be busy already.
The person whose workbook it was. For the colleague who built and maintained those files for years, a migration can read as a verdict on their work. Somebody senior should say early and in person that it is not. Their knowledge of which students are billed differently and which rules have exceptions is the most valuable input the project has, and they will withhold it if it feels like a criticism.
The private copy. Someone will keep their own version of a sheet "just in case". It stops when the new system is faster than their copy, not when you ban it.
Something will be wrong after go-live. A missing cohort, a fee imported at the wrong amount, a class with the wrong teacher. Schedule a fix window in the first weeks and tell staff it exists, so problems get reported rather than worked around.
None of this is a reason not to migrate. It is a reason to plan for it.
What this looks like with a proper system
The mechanical half — mapping columns, loading students, classes and balances, checking totals — is the vendor's job. KMPUS onboarding includes data migration from your spreadsheets or a previous system, so nobody on your team writes an import script. The decisions in steps two and three stay yours.
What changes once the data is in one place is the re-typing. An enrolment submitted through the admission process creates the student, and that same record then carries attendance, evaluations and academic history and the balance and account statement the family sees. One entry point, no reconciliation between files.
If you run continuous intakes rather than fixed terms, check how the platform handles rolling intakes before committing to a date. NED College across Dublin and Limerick, and Erin School of English across Cork and Dublin, both did this at multi-campus scale; their customer stories are published.
Frequently asked questions
How long does migrating from spreadsheets take?
It depends on the state of your data far more than the size of your institution. The import is quick; the audit, the cleaning and the duplicate decisions are the long part — and the part you control.
Do we have to migrate all our historical data?
No, and you probably should not. Migrate what you need to operate, archive what you only need to answer occasional questions. Where an accrediting body or your national data protection authority has retention requirements, check with them before deciding what to leave behind.
Can the vendor just do the migration for us?
They can do the import, and a good one will. They cannot decide which of two similar records is the same student, what a legacy column meant, or what you are willing to leave in the archive.
Do we have to pause enrolments during the switch?
No — that is what the parallel period is for, which is also why it should be short and have a fixed end date.
If your data is in better shape than you fear, or worse, the fastest way to find out is to load it: start a free KMPUS trial — no credit card, and migration from your existing spreadsheets is part of onboarding.
