Ask why a school's software rollout failed and you will rarely hear that the software was bad. You will hear that they never finished putting the data in.
It is the most predictable failure in this market. A school signs up in August, someone is handed a blank template and asked to type in six hundred students, three weeks of term start happen instead, and by October the school is still running the old exercise books with a half-populated system sitting beside them. Everyone quietly stops mentioning it.
The mechanical work of typing records is where rollouts die. Here is how to avoid doing it.
Why manual entry fails, specifically
It is worth being precise about this, because "it takes a long time" undersells the problem.
The volume is worse than it looks. Six hundred students is not six hundred entries. It is six hundred students plus their classes, plus guardians, plus guardian phone numbers, plus dates of birth. Realistically several thousand fields.
It lands at the worst time of year. Nobody migrates in the middle of a quiet term. They migrate at term start, which is when admissions, fee collection and timetabling are all happening.
It falls to the person you can least spare. The staff member who can be trusted to type records accurately is the school secretary or the bursar, and they have a term starting.
Typed data is wrong in ways that matter. Transposed digits in a phone number are invisible until an alert does not arrive. Names entered inconsistently make duplicates that surface a term later.
Nobody can see progress. Half a database is not half a working system. It is a system nobody trusts, running in parallel with paper, which is the state most abandoned rollouts die in.
The three ways records actually exist
Ghanaian schools hold their student data in one of three states, and each needs a different route in.
Already in a spreadsheet
The best case. An export from Excel or Google Sheets goes straight in.
The things worth getting right before importing: one row per student, names split into surname and other names rather than one column, a class column whose values match your class names, and guardian phone numbers in a consistent format. If you are importing a class at a time, the class can be set for the whole batch rather than repeated on every row.
Spend the time on phone numbers. They are the field with the highest downstream cost when wrong, because every alert, every fee notification and every parent app login depends on them.
Collected through a form
Many schools have run admissions or a data-collection exercise through Google Forms, which leaves the data in a sheet with the form's own column names rather than tidy ones.
This imports too, and it is worth checking before you rekey anything. A form response sheet from last year's admissions exercise is usually a better starting point than the office's own records.
On paper
The common case, and the one that used to mean typing.
A printed class list, a handwritten register, an admissions ledger: photograph it, and the image can be read into student rows. Names, gender, date of birth, class, and guardian name, phone and email where the sheet has them.
This is not magic and should not be treated as such. Handwriting varies, some columns are ambiguous, and the output needs a human pass. But reviewing and correcting a screen of extracted rows is a fundamentally different job from typing them, and it takes an afternoon rather than a fortnight.
Reviewing before committing
Whatever the route in, nothing should save until somebody has looked at it.
The review step should show the rows as they will be created, let you fix what is wrong, and check for duplicates against students already on the system before anything is committed. That last part matters most on the second and third import, when a school is adding a class at a time and it becomes easy to import the same children twice.
Two things to check properly in the review:
Class assignment. A child in the wrong class is wrong on the register, wrong on the fee schedule and wrong on the report card. It is the single highest-consequence field.
Guardian links. A student with no guardian attached generates no notifications and cannot be paid for through the parent app or by USSD. It is easy to import six hundred students and discover later that a hundred of them have nobody linked.
The sequence that works
Get the class structure in first. Classes have to exist before students can be assigned to them, and creating them as you go produces near-duplicates like "Basic 5" and "Basic5".
Import one class as a test. Not six hundred students. Thirty. Check what came out, look at how names and phone numbers landed, fix the source sheet, then run the rest. A problem found on thirty rows is an edit. The same problem found on six hundred is a cleanup.
Then the rest, class by class. Class by class rather than all at once, because it keeps the review manageable and each batch inherits its class without needing a column.
Verify phone numbers before anything else goes live. Before turning on notifications or the parent app, confirm the numbers. The fastest check is to send one low-stakes announcement and see what fails.
Then finance. Once students and guardians are right, load fee items and any outstanding arrears. Generating the first bills and comparing the total against what the school believes it is owed is the most valuable reconciliation you will do, because it is where you find out which of your old records were wrong.
What to ask a vendor
Data migration is quoted vaguely more often than any other part of a school software purchase. Three questions make it concrete:
Who does it? If the answer is "you do", that is two to three weeks of your staff time and belongs in your cost comparison. We go through this and the other lines that get left out of quotes in what school management software actually costs in Ghana.
What formats do you accept? Excel and Google Forms exports should both be routine. If the answer is a rigid template with mandatory columns your data does not have, somebody is retyping.
What happens with paper records? Most schools have at least some. A vendor whose answer is "type them in" is quoting you a lower price than you are actually agreeing to.
How SwiftSapp handles it
Student records import from Excel and Google Sheets exports, including Google Forms response sheets, with classes resolved from a column in the sheet or applied to a whole batch when importing class by class.
Paper records import by photograph. A printed or handwritten class list is read into student rows covering surname, other names, gender, date of birth, class, and guardian name, phone and email, presented for review and correction before anything is saved.
Duplicate checking runs against existing students before a batch is committed. Guardian records are created and linked as part of the same import rather than as a second exercise, and phone numbers are normalised on the way in so that a number entered three different ways ends up in one consistent format.
Assisted onboarding is included at no cost, which in practice means we do the migration rather than sending you a template.
If you are looking at a term of typing, book a demo and bring a photograph of one of your class lists. We will import it on the call.
