Ask a school how many places a student’s phone number is stored. The answer is usually somewhere between four and eight, and nobody can say with confidence which one is right.
It is in the student information system, entered at enrolment. It is in the finance system, entered separately for invoicing. It is in the messaging tool, imported from a spreadsheet at some point last year. It is in the trip consent form. It is in a WhatsApp group. And it is in the class teacher’s phone. When the family changes number, some subset of those gets updated. Which subset depends on who was told and what they remembered.
This is a data silo, and it does not usually announce itself as a technology problem. It announces itself as a parent who did not get the message about the closure, an invoice sent to a disconnected number, and a safeguarding call that could not be made because the number on file was two years old.
Silos form for understandable reasons, which is why exhortation does not fix them. Each system was bought separately, to solve a real problem, at a different time, often by a different person. None of them was wrong to buy. The silo is what happens by default when nothing connects them, because the alternative — a member of staff maintaining the same record in five places — is not a system anyone designed, it is what people do when there is no other option.
The costs compound in three directions. There is duplicated work, which is the obvious one and the smallest. There is divergence, where the copies disagree and nobody knows which is authoritative — considerably worse, because now the data is not merely duplicated but unreliable. And there is the analysis that never happens: nobody asks whether attendance correlates with late fee payment, because answering it would mean manually reconciling two systems, so the question is not asked and the pattern is not found.
The instinctive fix is consolidation — one platform for everything. It is appealing and it is usually a trap. Schools that pursue it end up with a system that does the student record well and finance badly, or communications well and timetabling badly, because no vendor is genuinely best at everything. They also take on an enormous migration to get there, and discover eighteen months later that a department has quietly bought a specialist tool for the thing the all-in-one does poorly. The silo is back, with a bigger contract underneath it.
The more durable approach is to accept multiple systems and fix the connections. That starts with a decision most schools have never explicitly made: for each kind of data, which system is authoritative? Where does a phone number live such that everywhere else is a copy? This is not a technical question and it does not require any software to answer. It requires someone to decide, write it down, and tell people. A surprising amount of divergence disappears once staff simply know where to make the change.
Then connect the copies to the source. This is where standards matter, and in schools the relevant one is OneRoster — a specification for exchanging student, staff, class and enrolment data that most major student information systems support. It means an integration built once works across vendors: the same connector pointed at a different endpoint. Where OneRoster is not available, a scheduled export into a system that consumes it is unglamorous and works.
Two design decisions are worth getting right. Prefer one-way sync from the system of record outward. Bidirectional sync sounds better and doubles the failure modes, because now two systems can both change the same field and something has to arbitrate. One-way is boring, safe, and sufficient for most of what schools need. And make the sync observable: if it fails silently at 3am, you will discover it through a parent who did not get a message. A log showing what synced, what did not, and why is the difference between an integration you can trust and one you merely hope is working.
A practical starting point that avoids a large project: pick the single piece of data that causes the most trouble when it is wrong. In most schools that is guardian contact details. Decide where it lives, connect the systems that need it to that source, and stop maintaining the copies. That one change removes a disproportionate share of the pain, and it is a week of work rather than a year.
This is the thinking behind Skoolia’s integrations: a OneRoster connector that treats your existing student information system as the system of record and consumes from it, rather than asking you to migrate. One-way inbound by default, with an audit log of every sync. Your SIS stays authoritative; the workflows it was never built for happen elsewhere without a second copy of the truth.
The goal is not one system. It is one place per fact, and everything else knowing where to look.