A learning management system is not a one-term purchase. Once teachers have built courses in it, students have submitted work through it and parents have learned where to find grades, switching is slow and expensive. Many institutions keep the same platform for years, so a few extra weeks spent choosing well pay for themselves quickly.
This guide sets out a process that works for K-12 schools, universities and training teams alike. It is deliberately vendor-neutral: follow it and you will make a better decision whichever platform you choose.
Start with the problems, not the features
Before you look at a single product, write down what is not working today. Talk to teachers, the registrar, IT and a few parents or students. You are looking for concrete, recurring pain, for example:
- Teachers rebuild the same course every year because materials live in personal drives.
- Parents phone the office to ask about grades because they cannot see them online.
- Exams run on a generic form tool with no time limits and no protection against copying.
- Final grades are typed into a spreadsheet, then typed again into transcripts.
- Arabic-speaking staff work in an interface that was designed only for English.
Rank these problems by how often they happen and what they cost in time, errors or reputation. The top three to five become your yardstick. If a product does not solve them, a long feature list will not save it.
Build a small team with the right people
An LMS is not only an IT purchase. Teachers use it every day, the registrar depends on its records, and families judge the school by it. Give each group a voice, but keep the core team small enough to make decisions.
| Who | Why they need a seat | What they focus on |
|---|---|---|
| Academic lead (head of school, dean, director of learning) | Owns teaching outcomes | Course design, assessment, reporting |
| Two or three teachers, including a sceptic | Use it every day | Speed of marking, posting and messaging |
| IT lead | Runs and secures it | Sign-in, integrations, data, security |
| Registrar or student affairs | Owns official records | Enrolment, final grades, transcripts |
| Finance or procurement | Pays for it | Pricing model, contract terms, total cost |
| Students and parents (feedback group) | Live with the result | Ease of use on phones, clarity of information |
Five to seven people is a workable core team. Name one person who owns the timeline and the final recommendation. Committees without an owner tend to drift until a contract renewal forces a rushed choice.
Write requirements by role
Generic requirements such as “must have quizzes” do not separate vendors, because every LMS has quizzes. Write each requirement as a task a named person must be able to do, for example: “A maths teacher can write a question with a fraction and an exponent without installing anything.” Tasks like this can be tested in a demo.
Teachers
- Build a course once and reuse it next year, with version history.
- Create quizzes with the question types they actually use, including maths.
- Mark written work against a rubric and return feedback quickly.
- See which students are falling behind without exporting data.
Students
- See everything due this week in one place.
- Complete lessons and quizzes on a phone without zooming.
- Understand their grades and the feedback behind them.
Parents and guardians
- Follow each child's progress and grades from one login.
- Contact the right person at school without phoning the office.
Administrators and registrars
- Enrol students in bulk by grade, section or cohort.
- Confirm, override (with a recorded reason) and lock final grades.
- Produce transcripts and certificates without retyping anything.
- Report across campuses, departments or business units.
IT
- Use single sign-on with existing Google, Microsoft or SAML accounts.
- Assign role-based permissions and review audit logs.
- Export all data in usable formats, and integrate through a documented API.
Label every requirement as must-have, important or nice to have. A must-have is something you would reject a vendor over. If your must-have list runs to fifty lines, it has not been prioritised yet.
Narrow the field to three or four vendors
Start with a long list from peer recommendations, analyst lists and your own research, then cut it with knock-out questions you can answer from documentation or a short call:
- Language: does the full interface work in the languages you teach in, including right-to-left if you need Arabic?
- Fit: is the product built for your kind of institution, whether that is a K-12 school, a university or a training team?
- Data: can the vendor meet your data-protection and hosting-region requirements?
- Sign-in: does it work with the accounts your staff and students already have?
- Budget: is the likely price within range for your number of learners?
Three or four finalists is enough. With more, evaluators lose track of who showed what. With fewer, you lose bargaining power. Send finalists the same written questionnaire; our LMS RFP checklist has 60 questions you can adapt.
Run demos on your scripts, not theirs
A vendor-led demo shows the smoothest path through the product. A scripted demo shows whether it can handle your day. Send every finalist the same scenarios a week in advance and ask them to perform each one live, in the real product, not on slides.
- A teacher builds a short lesson with a video, an equation and a three-question quiz.
- A student completes the quiz on a phone and submits an assignment after the deadline.
- The teacher marks the assignment with a rubric, the late policy applies, and feedback goes back to the student.
- A parent signs in, sees the new grade and sends the teacher a question.
- An administrator enrols a new student mid-term into every course for their grade.
- The registrar confirms final grades and issues a transcript and a certificate.
- The same flows again with the interface switched to Arabic, if you need it.
Score each scenario straight after the demo, while it is fresh, using the same scale for every vendor. Our LMS evaluation scorecard gives you weighted criteria and a 0–3 scale you can use as it is.
Pilot before you commit
Demos show what is possible. A pilot shows what is practical. Ask your top one or two vendors for a time-limited pilot with real users and real work.
- Scope: two to four teachers and one or two classes for four to six weeks.
- Real work: teachers run actual lessons and assessments, not test data.
- Success criteria agreed in advance: for example, time to set up a week of lessons, number of support requests, and teacher and student feedback.
- Include the sceptic: if the most doubtful teacher is won over, others will follow.
- Test support: raise genuine questions and note how fast and how well they are answered.
Watch what people do when nobody is checking. If teachers quietly drift back to the old tool by week three, that tells you more than any survey.
Understand the pricing models
LMS prices are rarely comparable at first glance, because vendors count different things. These are the models you will meet most often:
| Model | How it works | Watch out for |
|---|---|---|
| Per enrolled user | You pay for every account in the system | Paying for alumni, inactive staff and parent accounts |
| Per active user | You pay for people who actually use the platform in the period | How “active” is defined and counted |
| Site or campus licence | A flat fee for an institution of a given size | Large jumps at the next size band |
| Tiered plans | Feature bundles at different price points | Must-haves such as single sign-on locked in the top tier |
| Open source, self-hosted | No licence fee | Hosting, upgrades, plugins and staff time |
Ask every finalist to price the same scenario: your learner, staff and parent numbers, the modules you need, over three years. Only then can you compare like with like.
Calculate the total cost of ownership
Over the life of a contract, the licence fee is often not the biggest cost. Build a three-year view that includes:
- Subscription or licence fees, including expected increases at renewal.
- Implementation, setup and configuration.
- Migrating courses, users and historic grades from your current system.
- Training for administrators, teachers, students and parents.
- Integrations with your student information, finance or HR systems, and their upkeep.
- Add-ons such as video hosting, plagiarism checking, proctoring or extra storage.
- Internal staff time to run the platform day to day.
- Exit costs: getting your data out at the end of the contract.
That last line deserves a direct question before you sign: how do we export everything, in what format, and at what cost?
Red flags to watch for
- The demo avoids your scenarios or falls back on slides and recorded videos.
- A must-have is “on the roadmap” with no date and no written commitment.
- Arabic support turns out to be translated menus on an English layout that breaks when you switch language.
- There is no clear answer about where data is hosted, who can access it and how it is backed up.
- Pricing rises sharply after year one, or essential features are sold as add-ons.
- Data export is missing, partial or only available in a proprietary format.
- References are nothing like your institution, or the vendor cannot offer any.
- Support is email-only with no response-time commitment.
Make the decision and plan the rollout
Combine demo scores, pilot results, reference calls and three-year cost using weights you agreed before the demos began. Agreeing weights early stops the decision being swayed by whichever vendor presented last. Summarise it on one page for leadership: the problems, the options, the recommendation, the cost and the main risks.
Then roll out in stages: administrators and the pilot group first, then all teachers, then students, then parents. Time the switch to your academic calendar, ideally in the weeks before a new term and never in the middle of exams.
Where Ilmoria fits
Ilmoria is a learning platform built for English and Arabic from the start and used every day by Ithraa School, an online high school. It covers courses, assessments, the gradebook, transcripts, certificates, the parent portal and admissions in one place, which suits schools that want fewer systems to connect. If it makes your shortlist, book a demo and send us your scenarios first. We will run them live.
Want to see this guide applied to your institution? We will walk you through it on Ilmoria.
Book a demo