How does student data get from a SIS into other school systems?

The four ways data leaves a SIS

CSV export is the oldest and still the most universal. Every SIS can produce files of students, staff, schools, courses, sections, and enrollments, usually on a nightly schedule to an SFTP location. It is unglamorous, it works everywhere, and it fails silently — a job that stops running produces yesterday's file forever, and nobody notices until a teacher's roster is empty in October.

OneRoster is the standards-based answer. It defines both a CSV file format and a REST API covering the same entities, so an application that speaks OneRoster can consume data from any compliant source. Version 1.1 is the version most widely implemented in the field, and 1.2 is the newer revision. When a vendor says they support rostering, OneRoster is usually what they mean.

Rostering brokers — Clever and ClassLink are the dominant ones — sit between the SIS and applications. The district connects the broker to the SIS once, then authorizes individual applications to receive specific data through the broker. This is genuinely convenient and it is why they are so widely adopted: the alternative is negotiating a data connection with every vendor separately.

Direct SIS API integration is what you use when you need something the standards do not carry. PowerSchool, Infinite Campus, and Skyward all expose APIs with more detail than a OneRoster feed — attendance, discipline, contact records, custom fields — and a device or help desk system often wants a field that rostering standards never defined.

What each approach costs you

Brokers are the least work to set up and the most constrained. The data an application receives is whatever the broker's schema carries and whatever the district authorized in the sharing settings, and that is often less than the application could use. Districts regularly discover that the field they need — a building code, a grade-level nuance, a guardian email — is either not in the broker's model or not in the share.

Brokers also introduce a dependency and a latency. Data flows on the broker's schedule, and troubleshooting a missing student means working out whether the problem is in the SIS, the broker's sync, the share configuration, or the application. That is three parties on a call instead of one.

Direct API integration gives you the full field set and immediate control, at the cost of building or buying a connector per SIS and maintaining it through the vendor's upgrades. For a system that is central to district operations, this is usually worth it; for a single classroom app, it is not.

OneRoster sits in between: standard enough to be portable, rich enough for most identity and roster needs, and supported by essentially every SIS either natively or through an export. If you are choosing an integration approach for a new system and it supports OneRoster, that is generally the lowest-regret option.

A note on CSV: it is fine as a mechanism and dangerous as an operating model, because failure is silent. Whatever consumes the files should alert when a file is missing, when it is stale, or when the row count changes dramatically overnight — a student file that shrinks by forty percent should stop the sync, not apply it.

The problems that actually bite

Identity matching is the perennial one. The same student may exist with a state ID in the SIS, a different ID in the broker, an email address in Google, and a locally assigned number in your device system. Pick one field as the join key, ideally the SIS's own student identifier, and carry it everywhere. Matching on names is the road to two records for every student whose family uses a nickname.

Mid-year moves are the second. A student who transfers between buildings within the district generates an enrollment change that many downstream systems handle badly — they either keep the old building assignment or create a second account. This matters for device custody specifically, because a checkout that still points at the old school makes the outstanding list wrong.

Withdrawals and the end-of-year rollover are the third and hardest. When a school year turns over, section enrollments change wholesale, some students leave, and grade levels advance. Systems that treat a missing student as a deletion will happily wipe records you needed; systems that never remove anyone accumulate years of ghosts. The correct behavior is usually to deactivate rather than delete, keeping the historical record while removing access.

Staff data is consistently worse than student data. SIS staff records are often incomplete because the SIS is not the system of record for employees — HR is. Districts frequently end up rostering students from the SIS and staff from Active Directory or Entra ID, which is a reasonable design as long as it is deliberate.

And deletion timing deserves an explicit policy. How long after a student withdraws does their account close, and how long after that is their data purged? This is a records-retention question with legal weight, not an engineering preference.

Serving roster data onward

Once a system has clean roster data, it can be a source rather than only a consumer. A district system that itself serves a OneRoster 1.1 API gives you a place to point other applications, which is useful in a few specific situations.

If your SIS's own OneRoster support is weak or its API is rate-limited, an intermediate system that syncs once and serves many is easier on everyone. It also gives you one place to control what each downstream application can see, which is a meaningful privacy improvement over granting each vendor SIS access.

It helps with data you have enriched. If your roster is joined to building assignments, device custody, or identity attributes that the SIS does not carry, serving that combined view is more useful downstream than the raw SIS export.

And it gives you leverage during a SIS migration. Districts that change SIS vendors — which happens — discover that every downstream integration was wired directly to the old system. A layer in between means you rebuild one connector rather than thirty.

The caveat: whatever serves that API is now infrastructure. It needs monitoring, an access model with real tokens and scopes, and someone who owns it. That is a reasonable trade for a central district system and an unreasonable one for a side project.

A workable setup for most districts

Sync from the SIS directly where you can, using the SIS's own API or its OneRoster feed, into whichever system is central to your operations — identity, devices, and help desk all need the same roster.

Keep the broker relationship for the classroom applications that require it. Clever and ClassLink are entrenched for instructional software and there is no benefit to fighting that; import from them where a vendor only speaks broker.

Run the sync nightly, outside school hours, and alert on failure and on suspicious deltas. The alert matters more than the schedule. A sync that has not run in nine days is a much bigger problem than one that runs at the wrong hour.

Make the sync inspectable. When a principal asks why a student is missing, the answer should come from a sync log showing what arrived and what was skipped, not from a database query. Districts that can answer roster questions in a minute stop having roster arguments.

And document the field mapping once, in writing: which SIS field becomes which field downstream, what the join key is, and what happens on withdrawal. This document is what makes the system maintainable by the next person, and it is almost never written.