The Illusion of Cheap EdTech: Why Fragmentation Costs More Than You Think
July 2, 2026
Where Is Your School Entering the Same Data Twice? A Workflow Audit
October 21, 2026
How do you choose a student information system?
To choose a student information system (SIS), define your school's essential workflows, test them in vendor demonstrations, review reporting and integration requirements, and compare privacy terms, implementation responsibilities, total cost, and data-export options. Use a consistent scorecard and resolve unanswered launch requirements before making a decision.
This K-12 SIS evaluation checklist turns that process into 15 questions. Use them to structure your vendor conversations and demonstrations, then record the evidence behind each answer.
This guide is designed for superintendents leading a selection process, with questions to bring to IT, operations, and school leadership colleagues. If you lead a small district or charter school, pay particular attention to who will own each implementation task.
Start with your school's requirements
If you are exploring providers, you can also review EduSchool's 2026 K-12 student information systems guide. This article focuses on evaluating fit and documenting evidence for your selection decision.
1. Which problems are we asking a new system to solve?
Name three specific priorities before scheduling demonstrations. For example, you might want to review how attendance corrections reach the office, how staff reconcile reports, or how families submit forms. Treat these as possible workflows to investigate, not assumptions about what is wrong with your current system.
For each priority, write down the current process, its owner, and what an acceptable improvement would look like.
2. What must work on launch day?
Separate requirements into three groups: essential for launch, useful after launch, and optional. Ask the vendor to identify what is available today, what requires configuration or another product, and what is planned.
A roadmap item should have its own line in your evaluation. Do not score it as an available capability.
3. Can staff complete our actual tasks in a demonstration?
Prepare a short script using fictional records. Ask a teacher to enter and correct attendance, an office colleague to update a record, and an administrator to review a report. Choose tasks relevant to your school.
Record the steps, permissions, and questions that arise. Ask to see the complete workflow rather than only its final screen.
4. Does the system support our school structure and policies?
Bring examples of your grade levels, calendars, grading policies, schedules, and staff assignments. Ask which settings your team can manage independently and which require vendor assistance.
For a small school, identify who will maintain those settings. For a district or school network, ask how shared policies and permitted school-level differences are handled.
Check the data and technical fit
5. Which systems must exchange information with the SIS?
List the learning platforms, identity services, assessment tools, and reporting destinations your school needs to connect. Ask for documentation for each required connection, including the data exchanged, update frequency, responsible party, and additional fees.
Do not accept a general statement that a vendor supports integrations as evidence for a specific connection.
6. How will our reporting requirements be tested?
Identify the reports and submission formats your school must produce, along with deadlines and review responsibilities. Ask the vendor to demonstrate the relevant outputs and explain how corrections are handled.
For a New York school, include your regional information center or other reporting partner in the review when applicable. Confirm your own school's requirements with that partner rather than assuming every school follows the same process.
7. What is included in data migration?
Ask which historical records, attachments, custom fields, and relationships can be moved. Request a written division of responsibilities for extraction, cleanup, mapping, import, and validation.
Agree on how your team will compare sample records and totals before accepting the migration. Ask what happens when a record cannot be imported correctly.
8. How are access, backups, and service interruptions handled?
Request documentation describing account permissions, authentication options, audit records, backup practices, and recovery procedures. Ask who receives incident notices and how your team can obtain support during an interruption.
Have your IT lead evaluate the answers against your school's requirements. A confident demonstration is not a substitute for technical documentation.
9. What privacy terms govern our student information?
Request the proposed contract, data privacy agreement, and information about other providers that may handle school data. Ask what information is collected, how it is used, how long it is retained, and how it is returned or deleted.
The U.S. Department of Education provides a model terms-of-service resource to help evaluate how online educational services collect, use, and transmit information. Use it as one input to your review, alongside your school's specific requirements. Source: U.S. Department of Education, Model Terms of Service.
When a school relies on FERPA's school-official exception for an outside provider, conditions apply, including school control over the use and maintenance of education records and limits on the use and redisclosure of personally identifiable information. Ask your privacy or legal team to assess the proposed arrangement and applicable state requirements. Source: U.S. Department of Education, School-Official Guidance.
Plan the cost and the transition
10. What is the full cost over the proposed contract term?
Request an itemized proposal covering licensing, setup, migration, training, integrations, support, optional modules, and renewal terms. Estimate your own staff time separately.
Ask which prices are fixed, which depend on enrollment or usage, and which could change at renewal. Compare proposals using the same assumptions.
11. Who owns each implementation task?
Ask for a plan naming both vendor and school responsibilities. Include data preparation, configuration, testing, training, launch approval, and support after launch.
Check the plan against your team's actual availability. If one employee will cover several roles, make that constraint explicit before agreeing to dates.
12. How will training and ongoing support work?
Request a training plan by role, not simply a number of sessions. Ask about practice environments, written guidance, new-employee onboarding, support hours, escalation routes, and any service commitments in the contract.
Identify who at your school will answer routine questions and who can escalate an unresolved issue.
13. Can we test the fit before committing to a full rollout?
Ask whether a demonstration environment, limited pilot, or staged implementation is available. Define the scope, cost, duration, and success criteria in writing.
Start with fictional data where possible. Before using identifiable student information, complete the required privacy and security review. Agree on what happens to pilot data if you decide not to proceed.
14. What evidence can we review from a comparable school?
Ask whether the vendor can arrange a reference conversation with permission. Look for relevant similarities in school size, workflows, staffing, and reporting needs.
Ask what the school implemented, how much work it required, what remains difficult, and how support has performed. Treat a reference as one source of evidence, not a guarantee of your own results.
15. What happens if we decide to leave?
Before signing, ask how you can export records, attachments, and historical information. Request details on formats, fees, timing, contract notice requirements, and data deletion after termination.
Include an exit process in your comparison. Your team should understand how it would recover its information before deciding where to put it.
Use one scorecard for every vendor
Copy this table for each provider. Assign an owner and deadline to every unanswered question.
| Evaluation area | School requirement | Evidence reviewed | Status | Owner and next step |
|---|---|---|---|---|
| Daily workflows and school policies | Define required tasks | Demonstration and configuration details | Meets / Partial / Unverified / Does not meet | Record follow-up |
| Integrations and reporting | List required connections and outputs | Documentation and sample outputs | Meets / Partial / Unverified / Does not meet | Record follow-up |
| Migration and implementation | Specify records, roles, and timing | Written migration and project plans | Meets / Partial / Unverified / Does not meet | Record follow-up |
| Privacy and security | Specify review requirements | Contracts and technical documentation | Meets / Partial / Unverified / Does not meet | Record follow-up |
| Cost, training, and support | Define budget and support needs | Itemized proposal and service terms | Meets / Partial / Unverified / Does not meet | Record follow-up |
| Pilot, references, and exit | Define evidence and exit needs | Written terms and reference notes | Meets / Partial / Unverified / Does not meet | Record follow-up |
Resolve essential requirements before combining scores. A strong result in an optional area should not erase an unanswered launch requirement.
Bring your requirements to an EduSchool walkthrough
Use the same questions when evaluating EduSchool. Bring your priority workflows, required connections, and implementation constraints, then ask which requirements can be demonstrated today and which need further confirmation.