How to choose school management software: checklist for heads

How to choose school management software: checklist for heads

Choosing your school’s management software is one of the most costly decisions to reverse — not in licence price, but in time, data loss and disruption when the system does not fit and you have to start again. In 2026, the Spanish market has solid options, but also solutions that sell modules nobody will use, promise integrations that do not exist, and conceal migration costs until the contract is signed. The antidote is an honest evaluation process, with your own criteria — not the vendor’s — a demo with your real data, and a three-year total cost calculation before you commit. This checklist gives you the framework for that process.

Before you search: define your real problem

Most schools start looking for “the best school software” without having defined their main problem. The result is a catalogue evaluation where the most polished presenter wins, not the best fit. Start by listing the five most frequent friction points for your admin team: billing and manual reconciliation? September enrolment peak on paper? Communication via WhatsApp without any record? Lost pupil files spread across three tools? That inventory is your buying criteria. If the software you are evaluating does not directly resolve at least three of those five friction points, with modules available today, it is not the right choice for your school.

Module checklist: must-have vs. add-later

Must-have in any setting:

• Unified digital pupil records with pupil data, family contacts, history and year groups.
• Recurring billing with invoices, direct debit, payment history and arrears management.
• Family portal or app with basic self-service (access to record, payments, basic communication).
• Onboarding and documented support: you cannot depend on a single tech contact to use your own tool.

Assess based on your setting:

• CRM with application pipeline, forms and statuses, if you have a waiting list or active recruitment campaign.
• Pro communication with push and read receipts, if message volume and criticality justify it.
• Cloud documentation module, if document volume is high or your regulation requires an audit trail.
• Extracurricular and shop modules, if you manage activities with their own places and billing.
• Task and notification automation, if you want to reduce manual work in repetitive processes.

Demo questions: what vendors do not always show voluntarily

• Can I see the complete flow from a place application to the first invoice, with my own data, not demo data?
• How is an arrears case handled: how many clicks, what automated actions and how is it recorded?
• How do I export all my data if I decide to change provider in two years?
• What happens if there is an error in an invoice already sent: how is it corrected without breaking the numbering sequence?
• Where is the phased migration plan: master data, billing history, documents?
• How many simultaneous users does today’s support handle? Is the response 24/7 or office hours only?
• Which modules are included in the base price and which have additional cost?

How to calculate the three-year total cost of ownership

The monthly licence price per pupil is just the first layer. Add:

• Migration cost: external or internal technical hours, data validation, system coexistence period.
• Training: not just the initial onboarding, but the cost of training every new team member going forward.
• Integrations: if you need to connect with payroll, external accounting or third-party applications.
• Modules not included in the base price that you will need in year two.
• Re-migration risk: if the system does not scale or the vendor changes their business model.

In most cases, a system that appears cheaper but forces you to use two external integrations ends up costing more than an integrated platform with modular pricing. Ask the vendor for a three-year projection with all those components, not just the monthly tariff.

Warning signs from a vendor

• Cannot demonstrate functionality with your data in the first session.
• Migration plan is “we’ll sort it during implementation” with no document.
• The exit contract does not specify how you recover your data in an open format.
• Support is office hours only for a service used 24/7.
• The “all-inclusive” price hides modules that “are not active on your base plan”.
• Cannot show verifiable references from schools with a similar profile to yours.

The recommended decision process

Week one: friction inventory and your own criteria. Week two: shortlist of three vendors, first demo with the catalogue. Week three: in-depth demo with your own data for the two finalists. Week four: TCO calculation, contract review (data portability, exit clauses, support) and decision. Pilot: start with the highest-friction process, measure at ninety days, then expand. Do not buy seven modules if you can only properly activate two in the first three months: software empty of usage is not investment, it is cost.

Frequently asked questions

How long does a complete software change take?

Between two and six months, depending on data volume, school complexity and internal team availability. A basic pilot (master data, first billing cycle, family portal) can be live in four weeks if there is a dedicated internal lead and the vendor has a defined migration plan.

Is it better to change software in summer or in January?

Summer reduces the impact on families and staff, but compresses validation time with live enrolment and billing data in motion. January is quieter for enrolment but coincides with year-end accounts. The answer depends on where your biggest pain point is: if it is the September enrolment intake, change in summer; if it is billing, consider doing it with a quieter month’s data.

Should I insist on a data portability clause in the contract?

Yes, always. Before signing, confirm you can export all your data (pupils, billing, records, documents) in an open format (CSV, JSON, Excel) at any time. If the vendor does not include that in the contract or makes it conditional on an additional fee, it is a warning sign.

Does it make sense to implement just before an enrolment peak?

No, unless the current situation is so critical that anything is an improvement. In the first two months of use, any system runs below its potential: the team is learning, processes are adjusting and issues emerge. If you can, go live in January or February, consolidate the workflow, and arrive at September enrolment with the system already bedded in.

What if the vendor pushes updates that break my workflow?

Require in the contract advance notice of disruptive changes (at least two weeks), a test environment before updating production, and an update note history in the support portal. A vendor that updates without notice is an operational risk.

Conclusion

Choosing your school’s software well is not about comparing product sheets: it is about defining your problem, running the demo with your own data, calculating the real cost and reading the contract. Edena is the platform that centralises pupil records, billing, enrolment, communication, documents and analytics with activatable modules matched to the school’s real needs, 24/7 support and change-process guidance. Request a demo, bring your five main friction points and in ninety minutes you will know whether it fits.