Almost every difficult student information system rollout has the same cause, and it is not the software. It is that the school's existing data was worse than anyone realised, and nobody budgeted time to fix it.
This guide is built around that fact. The sequencing, the parallel running and the go-live plan all follow from it.
The eight-week shape
A realistic outline for a single-campus school. Adjust the calendar, keep the proportions.
| Phase | Duration | What happens |
|---|---|---|
| Decide and extract | Week 1 | Pull everything out of the current systems. Decide what is authoritative. |
| Clean | Weeks 2 to 5 | The actual work. Deduplicate, standardise, fill gaps. |
| Import and configure | Week 6 | Load the clean data. Set up classes, fee heads, roles. |
| Parallel run | Week 7 | Both systems, same data, differences investigated. |
| Go live | Week 8 | Old system read-only. New system authoritative. |
Notice that cleanup is half the schedule. That is not padding. It is the honest proportion, and a plan that gives it a week is a plan that will slip.
Two scheduling rules worth holding to:
Do not go live during admissions, exams or results. Any of those weeks will absorb every hour you needed for the rollout.
Go live at a natural boundary, meaning the start of a term or an academic year. Mid-term migration means carrying part-completed records across the join.
The data cleanup nobody budgets
Here is what you will actually find. Every school finds most of these.
Duplicate students. The same child entered twice with different name spellings, or once in the admission register and again in the fee sheet under a shortened name. You cannot deduplicate reliably by name, so use date of birth and guardian phone number as the matching keys, and expect to make judgement calls by hand.
Inconsistent class naming. "Class 6", "VI", "6th", "Grade 6", sometimes across four files, sometimes within one. Decide the canonical form on day one and convert everything to it. This looks trivial and blocks every import until it is done.
Missing guardian contacts. Usually 5 to 15% of records, concentrated in older year groups. This one has to be fixed by contacting families, which takes calendar time rather than effort, so start it in week one, not week four.
Students who left and were never marked as leavers. They inflate your roll, and if you import them they will generate fee invoices. Reconcile against the current attendance registers, which are usually more accurate than the master list.
Historical fee records with no reliable link to a student. The most common reason to decide not to migrate history. See below.
Siblings sharing a phone number, entered inconsistently. One parent, three children, three slightly different spellings of the same name. Worth resolving, because the parent portal experience depends on it.
The rule that saves the most time: migrate balances and current state, not history. Bring in current students, current fee balances, current staff. Keep the old system available read-only for anything historical. Schools that try to import five years of transactions spend most of the project on data nobody will look at, and import errors in historical data are much harder to detect than errors in current data.
Sequencing inside the rollout
Even within one system, do not switch everything on at once.
Students first. Everything keys off the student record. Nothing else can be validated until this is right.
Then staff. Smaller, cleaner, and needed before roles can be assigned.
Then structure. Classes, sections, subjects, the academic year, fee heads.
Then roles and permissions. Who sees what. Do this deliberately rather than giving everyone administrator access "for now", because "for now" becomes permanent, and it is the finding in every subsequent access review.
Then the first operational module. Usually fees, because that is where the manual load is heaviest and where the value is most visible.
Then the daily modules. Attendance, marks, homework.
Everything else, including transport, hostel and library, can wait until after go-live. A module switched on before anyone needs it is a module nobody learns.
Running in parallel
One week, sometimes two. Both systems maintained, and the outputs compared.
The point is not to test the software. It is to find the assumptions in your configuration that nobody stated out loud: the fee head that applies differently to one section, the concession that was never written down, the class that is counted differently in two reports.
What to compare specifically:
- The roll. Same total, same per class, on the same day.
- A fee run. Generate invoices in both. Investigate every difference, including small ones, because a ₹200 discrepancy is usually a rule nobody knew about.
- An attendance day. Same absences.
Investigate every difference, however small. The temptation at this stage is to accept close-enough and move on. Every difference you wave through in week seven becomes a support question in month three, when nobody remembers the context.
Longer parallel running is not better. Two weeks maximum: beyond that staff maintain both systems badly rather than one system well, and the parallel period itself becomes the source of errors.
Go-live week
Day by day.
Monday. Old system to read-only. Announce it clearly, because the most common go-live failure is someone still updating the old spreadsheet in week three.
Monday to Wednesday. Someone visible and available for questions. Physically present in the staff room at break, not on a support email address. The questions in the first three days are small and would go unasked otherwise, and unasked questions become workarounds.
Wednesday. First real checkpoint. Is attendance being marked daily? Is anyone still using paper?
Friday. First week review. What is being worked around, and why?
Two things to have ready before Monday:
A rollback position. Not because you expect to use it, but because knowing it exists changes how the team handles the first problem. The old system read-only is the rollback.
A named person for questions. One name, communicated to everyone. Not "IT".
Training that works
Three principles, learned the hard way.
Train by role, not by module. A class teacher needs the register, marks and homework. They do not need the fee module, and including it makes the session twice as long and half as useful.
Train close to go-live. Training three weeks early is forgotten. Two or three days before is right.
Train again after a month. The second session is where the real questions come, the ones that only occur once someone has used the system for a term's worth of work. Schools that skip this get the same questions as support tickets for a year.
Keep sessions to under an hour and to the five things that person does daily. Everything else is documentation.
Year two is the real test
The most common failure is not a bad rollout. It is a good rollout with nobody accountable afterwards.
What happens without an owner: records drift, new staff are trained by whoever is free, half the modules go unused, someone starts a spreadsheet for something the system does not quite do, and two years later the platform holds a partial picture nobody fully trusts.
Name an owner before go-live. Someone accountable for data quality, who onboards new staff, who has a route to the vendor, and who has the authority to say a process should change. This is a fraction of a role and it is the difference between a system that compounds and one that decays.
Then run a short review once a term: what is being worked around, which modules are unused and why, who has access they no longer need.
Two things to confirm before you start
That you can get your data out. Before you put everything in. Ask for a sample export of realistic data during evaluation and check whether it is usable: complete, structured, not a PDF of a screen. In ScolaOS, exports of students, fees, attendance and results run as self-service background jobs producing CSV, XLSX and PDF. That is worth confirming with any vendor, and it is much easier to confirm before you have committed.
That you keep the old system. Read-only, for at least a year. Not as a backup, but as a reference for the historical data you deliberately did not migrate. Your own backup arrangements are a separate matter and remain your responsibility regardless of platform.
Frequently asked questions
How long does a student information system implementation take? Around eight weeks for a single-campus school, of which roughly half is data cleanup rather than software work. The variable is almost entirely the state of your existing records. Clean data imports in days, while records spread across inconsistent spreadsheets with duplicates and gaps stretch the cleanup phase considerably.
Should we migrate historical data? Generally no. Migrate current students, current balances and current staff, and keep the old system available read-only for history. Importing years of transactions consumes most of the project on data nobody consults, and errors in historical imports are far harder to spot than errors in current data.
When is the best time to go live? At the start of a term or academic year, and never during admissions, exams or results. Those weeks will absorb every hour the rollout needs, and they are also the weeks when a problem is least tolerable.
How long should we run the old and new systems in parallel? One week, two at most. The purpose is to surface undocumented rules in your configuration, not to test the software. Beyond two weeks staff maintain both systems badly rather than one well, and the parallel period starts generating its own errors.
What is the most common reason school software rollouts fail? Underestimating data cleanup, followed by having no named owner after go-live. The first causes the project to slip and confidence to fall early; the second causes a successful rollout to decay quietly through year two.
Who should be trained, and when? By role rather than by module, two or three days before go-live, in sessions under an hour covering only what that person does daily. Then run a second session about a month later, because that is when the questions that matter actually surface.
In summary
A student information system rollout is a data project with a software component. Budget half the schedule for cleanup, migrate current state rather than history, and sequence students, staff, structure, roles, then modules.
Run parallel for one week and investigate every difference. Go live at a term boundary with a named person visible in the staff room. Then name the owner for year two, because that is where good rollouts quietly decay.
To talk through a rollout for your school, explore the platform, read how other schools did it, or book a walkthrough.