Student Information System Market Scan RFQ

MICHIGAN VIRTUAL REQUEST FOR QUOTE

Student Information System Market Scan

I. Introduction

Michigan Virtual is issuing this Request for Quote (RFQ) to engage a qualified vendor to run discovery on its Student Information System needs, conduct an independent market scan of available Student Information Systems (SIS) against those needs, and, if Michigan Virtual chooses to proceed, develop an issue-ready Request for Proposal (RFP). By issuing this RFQ, Michigan Virtual makes no guarantee of any award of work to any respondent now or in the future.

Michigan Virtual retains full discretion over vendor selection and over the relative weight of each criterion. All work products produced under any resulting engagement become the property of Michigan Virtual upon delivery and acceptance.

II. Background of Michigan Virtual

Michigan Virtual is a 501(c)(3) nonprofit established by the State of Michigan in 1998 to expand the use of learning technologies for the K-12 community. It operates as a statewide, multi-district online provider rather than a single district, which makes its enrollment, delivery, and data needs different from those of a conventional district buyer.

The Student Learning Portal (SLP) supports K-12 online course enrollment and delivery statewide, serving districts, schools, guardians, and homeschool families.

The full current-state details for this system, including its users, integrations, data dependencies, and requirements, are provided in Appendix A.

III. Description of the Request

Michigan Virtual seeks a vendor to run discovery, capturing current and future needs, then conduct a market scan and analysis of available systems against those needs. Based on the findings, Michigan Virtual may then commission the vendor to develop an issue-ready RFP. No outcome is presumed; the scan may show that the market serves Michigan Virtual's needs well, partially, or poorly, and each is a legitimate finding. A single vendor performs the discovery, the scan, and any RFP.

IV. Scope of Work

The Work

1. Discovery: current and future needs. Conduct discovery to capture Michigan Virtual's needs and requirements for this system, both existing and future. Focus the discovery sessions on how the work operates today from a procedural standpoint, not on documenting the current system, and on surfacing unmet and future needs the current system does not serve. Include data flow mapping. Output: a documented set of current and future requirements and a data flow map.

2. Market scan and analysis. Conduct a market scan of available systems and vendors, evaluating against the needs and requirements identified in discovery. For each option, deliver detailed vendor information, pricing, and an assessment of how fully it meets Michigan Virtual's requirements, noting where it fits well and where it falls short. Provide a comparison scorecard across options and a written analysis of the findings, including where the market can meet Michigan Virtual's needs, where it cannot, and the opportunities each option would open.

3. RFP development (if commissioned). If Michigan Virtual chooses to proceed after the scan, develop an issue-ready RFP built from the needs and requirements identified in discovery, including recommended evaluation criteria and vendor questions.

4. Selection support (optional). An optional, separately priced phase supporting the RFP process once it is issued, including project management, a scoring framework, and facilitation of vendor presentations.

System Evaluation Criteria (applied in the scan)

The vendor evaluates each available system against the following, noting where each would strengthen or limit Michigan Virtual's position:

• Interoperability and open standards (OneRoster, Ed-Fi).

  • Readiness to connect to the Michigan Data Hub without custom development.

• API depth.

  • Broad REST endpoints across core objects (students, enrollments, sections, terms, grades, financials), for read and write.

  • Public, well-documented APIs.

  • Webhooks or event subscriptions for key events (enrollments, drops, grade changes).

  • Bulk and batch operations.

  • Sandbox or test environment for building and validating integrations.

• Security posture.

  • SOC 2 Type II report.

  • Privacy policy review.

  • 1EdTech TrustEd Apps certification.

  • Encryption of data in transit and at rest.

  • Access controls: single sign-on, MFA, role-based, least-privilege access.

  • Vulnerability management: regular third-party penetration testing.

  • Incident-response documentation, including breach-notification commitments and timelines.

  • Secure handling of sensitive records (special-education documentation and student data) consistent with FERPA and IDEA.

• Data availability.

  • Real-time data access.

  • Database export availability.

  • System reporting.

  • Database querying and/or extensive custom report building.

• LMS integration.

  • Proven integration with Brightspace (D2L) and Buzz (Agilix), covering roster and enrollment provisioning, section setup, and grade sync.

• Payment, refund, and billing.

  • Credit card, purchase order, and consortium arrangements.

  • Integration into the ERP (Sage Intacct).

• Term and scheduling.

  • Ability to model many term types with varying start and end date combinations, enrollment-end cutoffs, and drop-for-refund deadlines, and to enforce the drop and refund rules (see Appendix A).

• Accessibility.

  • Student-facing experience meets WCAG standards.

Optionally, the vendor may provide a short, structured assessment of how well its solution supports Michigan Virtual's ability to grow and serve, scored against the strategic priorities. https://michiganvirtual.org/about/strategic-plan

Scope Notes

• If the analysis indicates that the market does not adequately meet Michigan Virtual's needs, the vendor may flag custom development as an option worth separate exploration. Analyzing or pricing a build is not part of this engagement.

• Migration and switching-cost analysis (data conversion, integration rebuild, retraining, and cutover risk) is not part of this engagement and remains with Michigan Virtual staff. Vendors may note where it will materially affect a decision but should not price it.

V. Deliverables

• A current-state process and integration or data-flow map.

• A documented requirements set traceable to Michigan Virtual's needs.

• A market comparison with a scorecard and a written analysis of findings.

• Indicative market pricing for commercial options.

• If Michigan Virtual commissions it, an issue-ready RFP.

• If engaged, a scoring framework and vendor-presentation facilitation (optional phase).

VI. Proposal Evaluation Criteria and Vendor Qualifications

Michigan Virtual will consider:

• Fit between the proposed approach and Michigan Virtual's operating model as a statewide, multi-district online provider.

• Experience with online or virtual-provider systems and with K-12 student information system selection.

• Quality and rigor of the discovery and current-state methodology.

• Strength and relevance of references for similarly scoped work.

• Completeness of the response and value delivered in proportion to fees.

VII. Response Instructions

To allow fair comparison, responses should be organized as follows:

• Cover letter and company overview.

• Qualifications and relevant experience.

• Proposed approach to discovery, the market scan, and RFP development.

• Key personnel: names, roles, and contact information, including any subcontractors.

• At least three references for similarly scoped work.

• Pricing. Provide pricing for each deliverable and phase. Price discovery and the market scan and analysis as the committed phases, and price RFP development and selection support separately as optional phases that Michigan Virtual may or may not exercise. Indicative market pricing for commercial options is expected as a scan output, not a full total-cost-of-ownership model.

• Submission. Submit one electronic copy of your response by email to the point of contact in Section IX, no later than the deadline in Section VIII.

VIII. Schedule

All dates below are placeholders to be set once the anchor date is fixed.

 IX. Confidentiality, Terms, and Contact

Contents of quotes, proposals, and any resulting contracts are confidential and will not be disclosed outside Michigan Virtual during or after the review. Michigan Virtual, as a private nonprofit corporation, is not subject to the Freedom of Information Act.

• Questions. Direct all questions by email to the point of contact below by the question deadline in Section VIII. Michigan Virtual will distribute responses to all participating vendors.

• Nondisclosure agreement: Vendors will be required to execute a nondisclosure agreement (NDA) prior to receiving confidential materials or submitting a quote. If required, the signed NDA must be returned along with the vendor's statement of intent to respond, as outlined in Section VIII. The NDA will govern the vendor's use and protection of any proprietary, financial, or system information shared as part of this RFQ process, and will remain in effect during and after the engagement, regardless of whether the vendor is ultimately selected.

Michigan Virtual reserves the right to award to the vendor of its choosing based on its understanding of its needs and the results desired, to make no award, and to cancel this RFQ at its discretion. Late or incomplete responses may not be considered.

Point of contact for this RFQ: Kristen Crain, Senior Director of Technology Operations, [email protected]

Appendix

• Appendix A: Student Learning Portal (SLP) Current-State Frame (attached as a separate document).