Tools
Templates for choosing and migrating
A vendor-neutral RFP structure, a migration checklist sequenced by dependency, and a data-readiness worksheet. Full text on the page, no form, usable in an evaluation we are not part of.
Three templates
Which one you need depends on where you are
Start with data readiness if you have not shortlisted. Start with the RFP if you have. The migration checklist matters once you have chosen.
School software RFP structure
A short RFP that produces answers you can distinguish between, organised around workflows rather than features.
Who fills it in: The person writing the requirements document, usually a business manager or IT lead, before vendors are approached.
Migration checklist
Sequenced by dependency rather than urgency, because the shortcuts here are the ones paid for twice.
Who fills it in: The internal project owner, from contract signature to the end of the first full term.
Data readiness worksheet
A short audit of your existing data, because migration risk is almost entirely a function of what you already have.
Who fills it in: Whoever owns the current data, ideally completed before vendors are shortlisted.
Template 1
School software RFP structure
A short RFP that produces answers you can distinguish between, organised around workflows rather than features.
How to use it
- Resist length. A 200-line feature matrix produces vendor responses that tick every line and tell you nothing, because almost everything on it is technically true of almost every platform. The questions below are fewer and harder to answer generically.
- Ask for demonstration rather than confirmation. Where a question asks a vendor to show something, say so in the RFP and hold them to it during the evaluation, because "yes" and "yes, here it is" are different answers.
- Include your three or four awkward cases verbatim. The mid-year transfer with partial history, the discount rule you find hardest to explain, the student taking a subject with another year group. These separate platforms; generic requirements do not.
- State your go-live term and your must-have phase one. A vendor who cannot meet the date should tell you now, and one who claims they can meet an unrealistic date has told you something useful.
Section 1 — Our school, briefly
Half a page. Vendors need scope, not history. Everything here changes the shape of a proposal.
- Enrolment, number of campuses, and whether they would run on one platform.
- Curricula taught, including where more than one runs alongside another.
- Whether tuition is charged, in which currency, and through which payment methods today.
- Current systems by workflow, including which are spreadsheets.
- Target go-live term, and which workflows must be live for that term.
- Internal owner for the project, and how much of their time is allocated.
Section 2 — Workflows we need to see demonstrated
Frame each as a task to perform in a demo, not a capability to confirm. Add your own; these are the ones that reliably differentiate.
- Move an accepted applicant to a live student record, class placement, fee ledger, and guardian portal access. Show every step.
- Configure our fee structure, including the discount rule we find hardest to explain, and generate an invoice and a receipt.
- Enrol a mid-year transfer and show where their previous academic history lives.
- Take one class register, including a covering teacher who is not the timetabled teacher.
- Enter a full class set of marks, timed, by someone who has not used the system before.
- Generate a report card for one student against our template, then correct a published result and show what a parent sees before and after.
- Show a guardian with children in two year groups signing in once and seeing both.
- Show a withdrawn student disappearing from current registers while remaining in academic history.
Section 3 — Data, migration, and exit
The section most RFPs underweight and most projects are decided by. Ask for specifics, not assurances.
- What data will you migrate, and what will you not? Name the exclusions.
- How is duplicate detection handled during import for students and guardians?
- Where do academic records for former students live after migration, and who can issue a transcript?
- How are fee opening balances established, and who signs them off?
- How do we export our own data while we are a customer? Show the export, not the policy.
- What happens to our data if we leave, and in what format do we receive it?
Section 4 — Access, security, and hosting
Short and specific. A long security questionnaire produces boilerplate; these produce answers.
- Describe the permission model. How would you model a person who holds two roles?
- Where is data hosted, and is on-premise or a specific region available?
- Is single sign-on against our identity provider supported? If not, say so plainly.
- How is platform activity logged, and can we export those logs into our own monitoring?
- If AI features exist, where does the model run and what data reaches it?
- What is the backup and recovery position, and who is responsible for it?
Section 5 — Integrations and interoperability
Ask about implementation status, not availability. "Supports" covers a wide range of realities.
- Which payment gateways are implemented and in production with other schools today?
- How is transactional email sent, and from whose domain?
- Are SMS and messaging automated, or does a staff member send them?
- Is there a connection to accounting software, or is it a file handoff?
- Is there an API a third party could integrate against, with its own credentials?
- For each of the above: implemented, roadmap, or not available? Answer per item.
Section 6 — Commercials and implementation
Ask for the configured total, not the entry price, and make the exclusions explicit.
- Quote for the configuration described in Section 1, itemised, including every module needed for those workflows.
- Implementation, data migration, and training, priced separately.
- What we are expected to provide: staff time, data preparation, hardware, and gateway onboarding.
- Renewal terms, and how price changes as enrolment grows.
- Support hours, response commitments, and the escalation path.
- Two reference schools of comparable size and curriculum, contactable directly.
Section 7 — Scoring
Decide the weighting before you see the responses, and write it into the RFP. Post-hoc weighting is how a shortlist gets rationalised rather than decided.
- Weight the Section 2 demonstrations most heavily. They are the least fakeable part.
- Score data and exit separately from features; a strong feature set behind a weak exit position is a risk, not a bargain.
- Score honesty explicitly: a vendor who answers "not available" to something is more useful than one who answers "supported" to everything.
- Record who scored what and why. In twelve months someone will ask why you chose this platform.
Template 2
Migration checklist
Sequenced by dependency rather than urgency, because the shortcuts here are the ones paid for twice.
How to use it
- Work top to bottom. The order is dependency order: each stage relies on the one above being correct, and starting with the workflow causing the most pain before the roster is trustworthy means doing the work twice.
- Assign a name to every line, not a team. Lines owned by "the office" are the ones still open in week six.
- Do the data preparation before contract signature if you can. It is the longest-lead item, it does not depend on the vendor, and it is where the project either becomes calm or does not.
- Set the date the old process is switched off when you plan each stage. A parallel period without an end date becomes permanent, and staff learn to trust whichever system they typed into.
Stage 0 — Before anything moves
Unglamorous and decisive. Every hour here saves several later.
- Name the internal owner and confirm how much of their time is allocated, in writing.
- Deduplicate students in your source data. Expect to find more than you think.
- Deduplicate guardians and establish payer-of-record per child, including split families.
- Confirm what your board, state, or accrediting body requires you to retain, and for how long.
- Decide what is being retired rather than migrated, and get that decision agreed rather than assumed.
- Agree fee opening balances per family in writing. This is the most disputed data in any school migration.
- Inventory any customisations or local workarounds in the current system; decide per item whether it becomes a requirement or is dropped.
Stage 1 — Foundation
Nothing downstream can be correct until these two are. Do not proceed past this stage on a promise.
- Configure the academic year, terms, and class structure.
- Configure the academic calendar: working days, holidays, and closure days. Verify against last year’s actual calendar.
- Import students, and verify enrolment count against your own figure before continuing.
- Import guardians and verify the links, including guardians with children in more than one year group.
- Design the permission model, including how a person holding two roles is represented. Do this now; taking permissions away later is far harder.
- Verify that an attendance percentage calculated for a sample student matches a hand calculation.
Stage 2 — Phase one workflows
Usually admissions and fees. Both, not one, because fee ledgers attach to the records admissions creates.
- Configure fee heads, instalment schedule, discounts, and late-payment rules.
- Complete payment gateway merchant onboarding. This has its own lead time and is frequently the critical path.
- Run a full fee cycle in test mode: invoice, payment, receipt, reconciliation.
- Configure SMTP and verify with a live test. Check SPF, DKIM, and DMARC alignment.
- Run one real admission end to end, from offer to portal access, with the registrar performing it.
- Set and communicate the date the previous fee process stops.
Stage 3 — Teaching operations
Timetable before attendance, because registers are generated from it. Portal last.
- Build the timetable, including subject option groups that cut across sections.
- Verify that a mid-term timetable change reaches the affected register and the affected teacher.
- Train teachers on marks entry and register taking; time a real class set.
- Confirm registers are accurate before teachers see them. An inaccurate register is why teachers keep private lists.
- Only then open the family portal, and only once fee and attendance data are right.
- Communicate to families what the portal shows and what it does not.
Stage 4 — Assessment and reporting
Last, because it aggregates everything above. Run a full cycle against real data, not a sample.
- Configure assessment structure, weighting, and grading scales against your published policy.
- Verify GPA or aggregate calculation against a hand calculation for three students.
- Build report card templates and generate a full cohort, not one student.
- Test correcting a published result, and confirm what a parent sees before and after.
- Confirm attendance figures on the report card match the portal figure.
- Write the internal procedure for the reporting cycle. It is performed termly by someone who last did it three months ago.
Stage 5 — After go-live
The stage most projects skip, and the reason problems surface a year later.
- Review permissions three months in. Look specifically for accounts that acquired administrator rights as a workaround.
- Check whether any team is still maintaining a spreadsheet for a workflow that moved. If so, find out which task got slower.
- Verify the year-end promotion process before you need it, not during it.
- Confirm exports work and take one, so data portability is tested rather than assumed.
- Record what went wrong in the first six weeks. It is the most valuable thing you can hand your successor.
Template 3
Data readiness worksheet
A short audit of your existing data, because migration risk is almost entirely a function of what you already have.
How to use it
- Fill this in against your actual data, not your impression of it. Run the counts. The gap between the two is the finding.
- Complete it before shortlisting. It changes which questions matter in an evaluation, and it is the single best predictor of how the first term goes.
- Share the results with vendors. A vendor who responds usefully to bad data is telling you something; one who says it will not be a problem is telling you something else.
- Anything marked as unknown is a task, not an answer. Unknowns discovered in go-live week are the expensive kind.
Students
Run these as counts against your current records.
- Total enrolled students, and whether that figure agrees between the office and finance.
- Number of students appearing more than once under any spelling or identifier.
- Number of students with a missing date of birth, admission date, or class placement.
- How mid-year joiners and leavers from the last three years are represented.
- Whether withdrawn students are distinguishable from enrolled ones, or simply absent.
- Where academic history for students who have left currently lives.
Guardians and families
The most common source of downstream problems, and the least audited.
- Number of guardian records, and how many are duplicates of the same adult.
- Number of children whose payer-of-record is unclear or unrecorded.
- How siblings are linked, and whether sibling discounts depend on that link.
- Number of families with more than one contact email, and which is authoritative.
- How split families and legal guardianship arrangements are currently recorded.
- Whether contact details have been verified in the last twelve months.
Fees and finance
Establish these before migration, in writing, with finance sign-off.
- Total outstanding balance, and whether the office and finance figures agree.
- Number of families with a manually adjusted invoice, and whether the reason is recorded.
- Fee heads, instalment structures, and every discount rule, written out in full.
- Number of receipts issued outside the current system, on paper or by hand.
- How refunds and credit notes are currently recorded.
- Which payment methods are in use, and the share of collection by method.
Academic data
Determines whether assessment can move in phase three or needs longer.
- Where marks for the current year live, including any held on personal devices.
- Assessment structure and weighting, written out, and whether it matches the published policy.
- How many years of historical results exist and in what format.
- Whether report card templates exist as documents or only as an established habit.
- Which curricula and grading scales are in use, including where more than one runs alongside another.
- Whether any published result has been corrected, and how that was handled.
Staff, timetable, and operations
Shorter, but the omissions are the same kind.
- Staff records, and whether teaching and non-teaching staff are held together.
- Current timetable format, and whether subject option groups are represented.
- How covering teachers and substitutions are currently recorded.
- Attendance records for the current year, and their format.
- Any statutory payroll obligations and the formats they require.
Readiness verdict
Total the unknowns and the duplicate counts. That total, not enthusiasm, sets your realistic go-live term.
- Duplicate students and guardians: a combined count above about two per cent of enrolment means data cleaning is a project stage, not a task.
- Unclear payer-of-record on any family: resolve before fee migration, without exception.
- Unknown location of historical academic records: resolve before contract signature if retention is a statutory obligation.
- Assessment structure not written down: write it down before evaluating any platform, because you cannot test what you cannot state.
- No named internal owner with allocated time: this is the strongest single predictor of a difficult rollout.
Template questions
Why they are not gated, whether the RFP is slanted, and which to start with.
Why are these not gated behind a download form?+
Because a template a search engine cannot read ranks for nothing, and a school that has to give up an email address to see a checklist usually finds another checklist. The full text is on the page. If it is useful, use it, including in an evaluation where we are not on the shortlist.
Is the RFP template written so that Schoolyi wins?+
It is written so that you can distinguish between vendors, which is not the same thing. Several sections ask questions our own answer to is no — single sign-on, automated SMS, accounting integration, third-party API credentials. An RFP only we can answer well would be worthless to you and obvious to anyone who has read one.
Can we edit and reuse these?+
Yes. Copy them, cut what does not apply, add your own awkward cases. They are a starting structure, not a standard, and the sections you add for your own school are usually the most valuable part.
Which of the three should we start with?+
The data readiness worksheet, before you shortlist. It changes which questions matter in the evaluation, and it is the best available predictor of how your first term goes. Most schools do it last, which is why data cleaning becomes a go-live-week emergency.
How long should an RFP process take?+
Long enough to run the Section 2 demonstrations properly with your registrar and a teacher present, which is usually two sessions per shortlisted vendor. Compressing that is the false economy: the time saved is small and the demonstrations are the least fakeable part of the whole process.
Send us your completed RFP
Including the awkward cases. We would rather answer the hard version than present the easy one.
Already using Schoolyi? Sign in