Importing Student Data From Spreadsheets

The spreadsheet you already have is usually enough

Schools moving to new software often assume the data migration is the hard part — that they need some special export from their old system, or a consultant to reformat everything, before they can even start. In practice, the spreadsheet your office already keeps — the one with admission numbers, names, classes, sections and guardian contacts — is usually enough to work from. It does not need to be perfect. It needs to be clean in a handful of specific ways, and once it is, importing it is a matter of minutes rather than days.

The goal of this guide is to get you from "the spreadsheet we already have" to a fully imported student body without creating duplicates, losing mandatory fields, or having to redo the whole thing because one column was misread.

Clean these five things first

Before you import anything, work through your spreadsheet for these five issues. They cause the overwhelming majority of import problems, and every one of them is faster to fix in the spreadsheet than to untangle after import.

• Inconsistent date formats. A date-of-birth column with some rows as 12/03/2015 and others as 2015-03-12 will import inconsistently unless you standardise it first. Pick one format for the whole column and convert everything to it.
• Trailing spaces. A name entered as "Ananya " with a trailing space looks identical on screen to "Ananya" but will not match it in a search or a duplicate check. Trim every text column.
• Merged cells. Merged cells are a formatting convenience for reading a spreadsheet, and they are a reliable way to break an import — the data underneath a merge often exists in only the first cell, leaving the rest blank. Unmerge everything before you import.
• Duplicate admission numbers. If your admission numbering has ever been reused, restarted, or assigned inconsistently across sections, this is where it surfaces. Sort by admission number and look for repeats before you import, not after.
• Missing mandatory fields. Decide up front which fields are non-negotiable — admission number, name, class and section, at minimum — and find every row missing one of them before the import, rather than discovering it as a rejected row during the import itself.

Decide what a duplicate means for your school

Every import system needs a rule for what counts as "the same student" — otherwise a student who is already in the system risks being created a second time. The reliable choice is the admission number as a unique key: it is assigned once, deliberately, and should never legitimately repeat.

Name plus date of birth, which some schools reach for instead, is not reliable. Picture a school with a few hundred students on the roll: it takes only two students sharing a common name and, by coincidence, a birth month, for a name-plus-date-of-birth check to either merge two different students or fail to catch a genuine duplicate. Worse, a name can be entered with a typo, a middle name included one year and dropped the next, or a spelling variant that a human reader accepts instantly but a duplicate check does not. Admission number as the unique key sidesteps all of this, provided your admission numbering has been clean and non-repeating — which is exactly why the duplicate check in the previous section matters.

Mapping your columns to the system's fields

Your spreadsheet's column headers almost certainly do not match the system's field names exactly — your sheet might have "Adm No" where the system expects "Admission Number", or "DOB" where it expects "Date of Birth." Column mapping is the step where you tell the import which of your columns corresponds to which field, once, rather than renaming your original spreadsheet to match.

Take this step seriously rather than rushing through it. A column mapped to the wrong field does not usually fail loudly — it succeeds, silently, with the wrong data in the wrong place, and that is a much harder mistake to notice and fix later than an import that fails outright.

Import one class before you import the school

This is the single most useful habit in the entire process: before you import your whole school, import one class. Pick a class you know well — ideally one whose data you could sanity-check from memory — map its columns, run the import, and check every field against what you expect.

Doing this surfaces problems while they are cheap to fix: a misread date format, a column mapped to the wrong field, a section name that does not match what the system expects. All of these are a five-minute correction when they show up in thirty student records. They are a much larger cleanup exercise when they show up in your entire school at once, because by then the incorrect data may already have been acted on — attendance marked, communications sent — before anyone notices the underlying import was wrong.

Once one class imports cleanly and you have checked it thoroughly, the same mapping applies to the rest of the school with far more confidence.

Reviewing the preview before you confirm

A well-built import shows you a preview before anything is written to the system — a table of exactly what will be created, row by row, against the mapping you set. Read it, do not skim it. Specifically check:

• That names, classes and sections read correctly, not just that the columns are populated.
• That rows flagged as possible duplicates are genuinely duplicates, and not two different students who happen to share a common name.
• That the row count matches what you expect — if your spreadsheet had 340 students and the preview shows 335, five rows were dropped somewhere, and you want to know why before you confirm, not after.

Confirming an import is far easier to get right than reversing one, so the review step is where your attention should go.

What to do when something imports wrongly

Even with careful preparation, something occasionally imports wrongly — a column that mapped correctly for most rows but not all, or a spreadsheet issue that survived the cleanup pass. When it happens, the answer is the same as diagnosing any data problem: isolate it to specific rows, check the original spreadsheet against what actually appears in the imported records, and correct those specific rows directly rather than re-running the whole import and risking new duplicates on top of the ones you are trying to fix.

This is also the best argument for the "one class first" habit above: an import error caught in thirty records is a quick correction. The same error caught only after importing the whole school is a much larger one to unpick — which is exactly why it is worth the extra care up front.

Moving your student records is the first real step in setting up e-SchoolBase — once they are in cleanly, everything else in the system builds on top of them.