Import Students From a Spreadsheet

Upload the student spreadsheet you already have. EduCRM proposes the column mapping, validates every row, then imports in bulk.

How the import works

In short

Upload your spreadsheet. EduCRM proposes each column's mapping with a confidence level, you correct anything wrong, and it validates every row (required fields, email format, duplicates) before writing. Students are then created in bulk with sequential IDs.

Step 01
Upload and parse
The file is read in your browser. Headers and rows are extracted locally.
Step 02
Mapping proposed
Only the column headers and a few sample rows are sent. Each suggestion comes back with high, medium or low confidence.
Step 03
You confirm
Change any mapping, or mark a column to be ignored. Nothing has been written yet.
Step 04
Validate
Required fields, email format and duplicates are all checked. Problems show before the import, not after.
Step 05
Import
Rows are written in batches, and each student gets a sequential ID.

Why the confidence level matters

A tool that silently guesses is worse than one that asks. `Email` is obvious; `Contact 2` could be a second parent, a guardian or the student's mobile. Confidence tells you where to look.

What is sent, and what is not

The full file never leaves your browser. Only headers and a few sample rows are used for the mapping. The rest is parsed locally and written straight into your workspace.

Clean before you import

The mapping is handled for you. Data quality is not. Half an hour in the spreadsheet first saves much more afterwards:

Worth doing first

One row per student. Merge duplicates added twice under different spellings.
Split combined fields. A cell holding a student name, a parent name and a phone number maps to one field and loses the other two.
Use one date format. Mixed formats are the most common cause of a bad import.
Standardise country and university names, so `UK`, `U.K.` and `United Kingdom` are not three values.
Delete columns nobody has filled in for a year rather than mapping them.

The wider migration order (active students first, then open applications, then outstanding payments, and no history) is in moving from spreadsheets to a CRM.

What gets imported

Student records: contacts, parent and guardian details, school and year group, target countries, and the other profile fields. Applications, sessions and payments come afterwards, because only the open ones are worth moving.

And getting back out

Data export is included on Premium. Confirm an export path with any vendor before you commit. The CRM buyer's guide makes that point about every product, including this one.

Try it with ten students

The free plan covers 10 students, enough to rehearse an import first.

Get started free Migration guide

Student Management

One record per student: contacts, sessions, applications, documents, payments and notes.

CRM vs Spreadsheets

When a spreadsheet is enough, where it starts to cost you, and what changes if you move.

AI Features

What the AI does, which provider processes what, and why nothing is sent on your behalf.

CRM Buyer's Guide

Features that matter, questions to ask vendors, and a checklist for comparing systems.

What file formats can I import?

A spreadsheet export from whatever you use today. It is parsed in your browser, and you confirm the mapping before anything is written.

Will the import create duplicate students?

Duplicates are identified during validation, before any rows are written.

Is my whole spreadsheet uploaded to an AI service?

No. Only the column headers and a few sample rows are used to propose the mapping. The full dataset is processed locally.

Can I import applications and payments too?

The bulk importer covers student records. Open applications and outstanding balances are usually added afterwards, since closed ones are not worth migrating.

Import your students from the spreadsheet you already have