SIS Integration Architecture for K-12 School Districts

Every K-12 school district runs on a Student Information System (SIS) — PowerSchool, Infinite Campus, Skyward, or similar — as the authoritative record of who a student is, which school and section they're enrolled in, and which staff member teaches them. That single fact would be simple to manage if the SIS were the only system that needed it. In practice, a mid-sized district commonly connects its SIS to twenty, forty, or more downstream applications: a learning management system, several assessment and intervention platforms, a single sign-on layer, state and federal reporting pipelines, library systems, food service, special education case management, and a rotating cast of subject-specific tools that teachers adopt each year.

Each of those systems needs to know, continuously and accurately, who the students and staff are, what sections they belong to, and when that changes. Enrollment isn't static — students transfer schools mid-year, sections get reshuffled at semester breaks, staff move buildings, and every one of those events needs to propagate correctly and quickly to every connected tool, or teachers end up teaching rosters that don't match reality. This is, in the industry's own shorthand, "the rostering problem," and how a district architects its solution to it has downstream consequences for data privacy, vendor risk, IT staffing load, and classroom usability alike.

Table of Contents

• The Rostering Problem: Why a Single Source of Truth Isn't Automatically Consistent
• OneRoster and Ed-Fi: The Two Dominant Data Standards
• SFTP/Batch vs. API/Real-Time Sync
• SSO and Identity Federation: Clever, ClassLink, and Direct SAML/OIDC
• FERPA and Data Governance Across a Multi-Vendor Ecosystem
• Why Point-to-Point Integration Breaks Down at Scale
• Architecting a Rostering and Integration Hub
• Operational Considerations: Monitoring, Reconciliation, and Change Management

Key Takeaways

• The SIS should be the single authoritative source for enrollment data, but "single source of truth" is a governance policy, not something that happens automatically — it typically requires an integration layer that enforces it.
• OneRoster is generally the pragmatic default for classroom-tool rostering and grade passback, while Ed-Fi is more commonly favored for state-level and cross-domain data warehousing use cases; many districts end up supporting both.
• SFTP-based batch rostering (commonly a nightly "OneRoster CSV" export) remains widespread because of its simplicity and vendor ubiquity, but it introduces sync latency that is typically measured in hours, which causes real classroom friction during add/drop periods.
• Point-to-point integration between the SIS and each individual application tends to scale poorly past roughly a dozen connected tools; districts that consolidate onto a rostering/integration hub commonly reduce both the engineering burden and the number of vendors holding raw student PII.

The Rostering Problem: Why a Single Source of Truth Isn't Automatically Consistent

The rostering problem is deceptively simple to state and genuinely hard to solve well: every application that touches a student's coursework, grades, or communications needs an accurate, current copy of that student's identity, enrollment, and section membership, and the SIS is supposed to be the one place that data originates. The difficulty is that "supposed to be" requires enforcement. Without an integration layer actively pushing SIS data outward on a defined schedule and format, individual tools drift — a teacher manually adds a student to an LMS course that the SIS never authorized, a section gets renamed in the SIS but not in three other systems, a student withdraws and their account lingers active in an assessment platform for months.

In our experience, the technical challenge is less about moving data once and more about handling the lifecycle events correctly: new enrollments, drops, transfers between schools within the district, section changes at marking-period boundaries, and staff reassignments. Each of these needs to be expressed as a deterministic transformation that every downstream system can consume the same way, which is exactly what data standards like OneRoster and Ed-Fi exist to formalize.

OneRoster and Ed-Fi: The Two Dominant Data Standards

OneRoster, maintained by 1EdTech (formerly IMS Global), defines a compact data model — orgs, users, enrollments, classes, and courses — along with a REST API specification and a CSV file format for the same entities. It was designed specifically for the classroom-tool rostering use case: getting a teacher's class list, with correctly identified students, into an LMS or assessment platform. OneRoster also defines a gradebook/results endpoint for passing grades back to the SIS, which is commonly the second half of the integration once rostering is working. Because of its narrow scope and CSV fallback option, OneRoster has become close to a lingua franca for K-12 edtech vendors; most mainstream LMS and assessment tools support it out of the box.

Ed-Fi, by contrast, is a broader data standard originally built for state and district-level data warehousing, analytics, and compliance reporting. Its data model covers far more than rostering — attendance, discipline, assessment results, special education services, staff qualifications — and it's typically exposed through a full REST API (the Ed-Fi ODS/API) rather than flat files. Ed-Fi tends to show up where a district or state needs a unified longitudinal data store across many domains, not just classroom rostering. It's common for a district to run both: OneRoster feeds for day-to-day classroom tool rostering, and an Ed-Fi ODS as the backbone for state reporting and internal analytics, with the integration hub responsible for keeping both in sync with the SIS and, ideally, with each other.

SFTP/Batch vs. API/Real-Time Sync

The most common rostering pattern in production K-12 environments today is still batch file transfer: the SIS or an intermediary hub generates a OneRoster-formatted CSV export — typically nightly, sometimes multiple times a day — and drops it on an SFTP server that each vendor polls or is pushed to. This approach is popular because it's simple to reason about, works with vendors of widely varying technical sophistication, and fails in an obvious, debuggable way (a missing or malformed file, rather than a silent API error).

The tradeoff is latency. A nightly batch means a schedule change made by a registrar at 9am doesn't reach the LMS until the next overnight run at the earliest, and often later if a vendor's ingest job runs on its own separate schedule. During the first weeks of a school year, or around semester changes when enrollment churn is highest, this lag is where most rostering-related help desk tickets originate. API/real-time sync — vendors polling a OneRoster or Ed-Fi REST endpoint, or the hub pushing webhook-style updates — closes that gap substantially, commonly bringing propagation down to minutes rather than hours. The cost is added complexity: API integrations require more careful authentication (OAuth client credentials are typical), better error handling on both sides, and generally more sophisticated engineering from smaller edtech vendors who may not have invested in it. Most districts run a hybrid: API sync for high-priority systems like the LMS and SSO layer, batch SFTP for lower-priority or legacy tools where latency is tolerable.

SSO and Identity Federation: Clever, ClassLink, and Direct SAML/OIDC

Rostering data (who's enrolled in what) and identity federation (how a user authenticates into a tool) are related but distinct problems, and districts commonly solve both through the same intermediary. Clever and ClassLink are the two dominant K-12-specific platforms that combine rostering distribution with single sign-on — they pull data from the SIS, normalize it, and then act as an identity broker so students and staff can log into dozens of tools with one district-managed credential, typically via a portal or app launchpad rather than separate logins per tool.

Under the hood, both platforms, and any district that builds its own identity layer, are typically implementing SAML 2.0 or OIDC as the actual federation protocol, with the SIS-derived roster data used to provision and deprovision accounts and group memberships in an upstream identity provider (often Azure AD/Entra ID or Google Workspace for Education, feeding through to the SSO broker). Direct SAML/OIDC integration, without an intermediary like Clever or ClassLink, is more common for larger or more technically mature districts that want tighter control over claims, session behavior, and vendor onboarding, but it also means the district's own IT team absorbs the integration and support burden per vendor rather than delegating it. A useful mental model: rostering answers "what should this account be able to see," identity federation answers "how does this person get in," and both need to be kept in lockstep with the SIS or accounts and access rights silently diverge from reality.

FERPA and Data Governance Across a Multi-Vendor Ecosystem

Every rostering feed is, functionally, an export of student PII — names, dates of birth, grade level, sometimes demographic or disability status flags — to a third-party vendor's infrastructure. Under FERPA, districts can typically share this data under the "school official" exception, provided the vendor is under the district's direct control, uses the data only for the contracted educational purpose, and is bound by a data privacy agreement (many states now standardize on a shared template, commonly referred to in the vendor-management space as a DPA or data sharing agreement). That legal basis, however, is only as good as the district's actual operational discipline around it.

In practice, data governance for a fanned-out edtech ecosystem means maintaining an accurate inventory of every vendor receiving student data, scoping each feed to the minimum fields that vendor actually needs (a math intervention tool rarely needs a student's full demographic record), enforcing signed DPAs before any feed goes live, and — critically — having a deprovisioning process that actually removes access and, where contractually required, triggers data deletion when a vendor contract ends or a student withdraws. This is where an integration hub earns its keep from a compliance standpoint: it's far easier to audit and control data flow through one governed choke point than to reconstruct, after the fact, which of forty point-to-point SIS exports a given vendor was receiving and whether it was scoped correctly.

Why Point-to-Point Integration Breaks Down at Scale

The naive architecture — the SIS exports directly to each connected application, one feed per vendor — is where almost every district starts, and it works fine at a small scale of maybe five to ten integrations. Past that point, the model tends to break down along several dimensions simultaneously. Each vendor has its own field mapping quirks, its own preferred format (some want OneRoster CSV, some want a proprietary flat file, some want an Ed-Fi API call), and its own schedule requirements, so the SIS team ends up maintaining a bespoke export job per vendor rather than one standardized process. When the SIS vendor changes its data model in an upgrade, every one of those bespoke jobs needs individual review and likely rework.

Point-to-point architecture also multiplies the governance surface described above: with N vendors each getting a direct feed off the SIS, there are N places where scoping mistakes, stale credentials, or forgotten deprovisioning can occur, and no single layer where an administrator can see the full picture of what's flowing where. It's common for a district technology director, on auditing a point-to-point environment for the first time, to discover feeds still running to a vendor whose contract lapsed a year earlier, simply because no one owned the job of turning it off.

Architecting a Rostering and Integration Hub

The pattern that most districts converge on once they outgrow point-to-point integration is a middle layer — a rostering/integration hub — that sits between the SIS and every downstream application. The SIS exports once, in one canonical format, to the hub; the hub owns transforming, filtering, and redistributing that data outward to each connected vendor in whatever format and schedule that vendor requires. This can be a commercial platform (Clever and ClassLink both function this way for rostering, not just SSO), a district-built middleware layer, or increasingly an Ed-Fi ODS/API instance configured as the canonical hub with connector logic layered on top.

Architecturally, the hub typically takes on several responsibilities beyond simple pass-through: field-level scoping per vendor (so a library system only receives grade level and name, not disability accommodations), format translation between OneRoster, Ed-Fi, and proprietary vendor schemas, identity resolution and matching (reconciling a student ID across systems that don't share a common key), and a single point of monitoring for feed health. The tradeoff is that the hub itself becomes a critical piece of infrastructure — its outages or misconfigurations now affect every downstream system simultaneously rather than just one — so it needs to be treated with the reliability and change-management rigor of core infrastructure, not a side integration project.

Operational Considerations: Monitoring, Reconciliation, and Change Management

Once a rostering architecture is in place, the ongoing engineering work shifts from building integrations to operating them reliably. Feed monitoring — alerting when an expected SFTP file doesn't arrive, or when an API sync job fails or returns an unexpectedly small delta — is commonly underinvested in relative to its importance, because a silent rostering failure doesn't throw an obvious error; it just means a teacher's class list is quietly wrong until someone notices and files a ticket. Reconciliation reporting, comparing record counts and key fields between the SIS and each downstream system on a recurring basis, is a practical way to catch drift before it becomes a support burden.

Change management matters just as much as the technical build. SIS version upgrades, state reporting schema changes, and new vendor onboarding all need a defined process for testing against a non-production rostering feed before touching live data, and a rollback plan when a change breaks a downstream system's ingestion. Districts that treat their rostering hub as a governed platform — with a change calendar, a documented vendor onboarding checklist, and clear ownership for both the SIS-side export and hub-side distribution — consistently report fewer rostering-related support escalations than those that treat each integration as a one-off project.

Getting SIS integration architecture right is foundational to almost everything else a district's edtech stack depends on, from classroom usability to state compliance reporting to the security posture of student data across dozens of vendors. For related reading, see our articles on LMS integration architecture in higher education and on student data privacy and FERPA/COPPA compliance for edtech. If your district is evaluating or rebuilding its rostering and integration architecture, contact Halkwinds to talk through your specific SIS environment and vendor landscape.

Frequently Asked Questions

Do we need both OneRoster and Ed-Fi, or just one?

Many districts end up supporting both, since they serve different purposes: OneRoster is typically sufficient and preferred for classroom-tool rostering and grade passback, while Ed-Fi is more commonly used for state reporting and cross-domain data warehousing. Smaller districts with modest reporting requirements can often get by on OneRoster alone.

Is Clever or ClassLink a full replacement for building our own integration hub?

For many districts, yes — both platforms handle rostering distribution and SSO federation together and are commonly sufficient without custom middleware. Larger or more technically mature districts sometimes outgrow their flexibility for edge cases like complex field-level scoping or non-standard vendor formats and build a supplementary or replacement hub.

How much sync latency is actually acceptable for classroom tools?

There's no universal number, but in our experience same-day propagation (a few hours at most) is the practical threshold below which teachers stop noticing rostering lag as a problem. Anything approaching a 24-hour batch cycle tends to generate visible friction during high-churn periods like the start of the year or semester changes.

Who is legally responsible if a vendor mishandles student data received through our rostering feed?

Under FERPA's school official exception, the district retains responsibility for ensuring vendors use shared data appropriately, which is why signed data privacy agreements and field-level scoping matter — they're the documented basis for the district's compliance position, not just a formality. This is a governance and contracting question as much as a technical one.

Should special education and health data flow through the same rostering hub as general enrollment data?

Typically yes, the hub is the mechanism, but with stricter field-level scoping and access controls than general rostering data — most vendors should never receive special education service details or health flags unless that data is specifically relevant to the tool's function, and this scoping decision should be made deliberately rather than defaulted to "send everything."