Most SIS integration projects that go wrong do not fail because of code. They fail because of messy source data, unclear ownership, and assumptions about how rosters change mid-term. This checklist is for school IT leads, university registrars, and product teams at edtech platforms who are about to connect a student information system to an LMS, assessment tool, or analytics product.

Work through it before development starts. It will save weeks of rework.

1. Scope and ownership

  • [ ] Define which system is the source of truth for students, staff, courses, sections, enrolments, and grades
  • [ ] List every downstream system that needs SIS data (LMS, assessment, library, transport, fees, analytics)
  • [ ] Name a data owner on the school side and a technical owner on the vendor side
  • [ ] Decide what flows one way and what flows both ways (typically rosters out of the SIS, grades back in)
  • [ ] Agree on the go-live date relative to the academic calendar; avoid switching during term start or exams

2. Standards and connection method

  • [ ] Confirm which standards the SIS supports: OneRoster 1.1/1.2 (REST or CSV), Ed-Fi, or a proprietary API
  • [ ] Confirm which standards the target platform supports; mismatches mean you need middleware
  • [ ] For tool launches inside an LMS, confirm LTI 1.3 / LTI Advantage support, including Names and Role Provisioning Services (NRPS) and Assignment and Grade Services (AGS)
  • [ ] Decide sync frequency: nightly batch, several times a day, or event-driven via webhooks (event-driven costs more to build but removes most "student missing from class" tickets)
  • [ ] Check API rate limits and whether the SIS vendor charges for API access

3. Data quality audit (do this first)

  • [ ] Every student and staff member has a unique, stable ID that never gets reused
  • [ ] No duplicate student records from re-admissions or transfers
  • [ ] Course and section codes follow one naming convention across campuses
  • [ ] Terms and grading periods are defined consistently, with correct start and end dates
  • [ ] Teacher-to-section assignments are complete, including co-teachers and substitutes
  • [ ] Email addresses exist for everyone who needs SSO, and they match the identity provider
  • [ ] Custom fields (houses, streams, electives) are documented with a data dictionary

4. Identity and single sign-on

  • [ ] Choose the identity provider (Google Workspace, Microsoft Entra ID, Clever, ClassLink, or institutional SAML/OIDC)
  • [ ] Map SIS IDs to identity provider accounts with a matching rule that handles name changes
  • [ ] Define what happens to accounts when a student withdraws, graduates, or transfers
  • [ ] Parent/guardian access: decide whether guardians get accounts and how they are linked to students

5. Enrolment lifecycle scenarios to test

  • [ ] New student joins mid-term
  • [ ] Student changes section or elective
  • [ ] Student withdraws and later re-enrols
  • [ ] Teacher leaves and a substitute takes over a section
  • [ ] Section is merged or split
  • [ ] Term rollover at year end, including archiving last year's courses

6. Grade passback

  • [ ] Map grade scales (percentages, letters, GPA, CBSE/ICSE or other board scales) between systems
  • [ ] Decide which assessments sync: final grades only, or every assignment
  • [ ] Define who can override a synced grade, and whether overrides flow back
  • [ ] Lock grades after the reporting deadline so late syncs do not overwrite approved marks

7. Privacy, security, and compliance

  • [ ] Share only the fields each system needs (data minimisation)
  • [ ] Signed data processing or data sharing agreement with every vendor that receives student data
  • [ ] Encryption in transit and at rest; access logs retained
  • [ ] Compliance with the applicable law: FERPA for US institutions, GDPR in the EU, and India's DPDP Act, including verifiable parental consent for children's data
  • [ ] Clear data deletion process when a contract ends

8. Monitoring and support

  • [ ] Sync dashboard showing last successful run, records changed, and errors
  • [ ] Alerts to a named person when a sync fails or error counts spike
  • [ ] A runbook for manual re-sync
  • [ ] Budget 4–8 weeks of integration testing with real (anonymised) data before launch

Red flags

  • The vendor promises "plug and play" without asking to see your data
  • No sandbox SIS instance for testing
  • Grade passback is "on the roadmap"
  • Nobody can explain how withdrawn students are removed

How to use this checklist

Run sections 1 and 3 in a workshop with registrar, IT, and academic leads. The data quality audit usually surfaces the real work. Use sections 2 and 6 as questions for your vendor or development partner, and section 5 as your user acceptance test script.

How Syslabs helps

Syslabs builds and maintains SIS-to-LMS integration for schools, universities, and edtech platforms, from API integration and middleware to grade passback and sync monitoring. We also help teams review student data privacy obligations before any data starts to flow.