Do You Need an LMS? What a Learning Management System Actually Records

An LMS is not a folder of presentations and a list in a spreadsheet. Once enrolment, completion and expiry have to be proved, the system begins to pay for itself — and when they do not, it is an expensive spare part.

Picture a shared folder holding seven presentations, two videos and one procedure named “training_FINAL_v2_use_this_one.pdf”, and beside it a spreadsheet in which someone in HR ticks off by hand who has watched what. With twenty people and a single course that arrangement works perfectly well and costs nothing, which is why nobody is in a hurry to change it — so do you need an LMS at all? The folder holds right up to the moment somebody asks whether one particular person really did sit through last year’s refresher, and the only answer you have is a spreadsheet row that nobody can corroborate and anybody could have retyped. A learning management system is software whose one serious job is to turn that row into a record with an origin, a date and an author.

What an LMS is, and what it gets confused with

A learning management system does four things: it enrols people on courses, delivers the content, checks what has been learned and keeps the record of what happened. The first and the fourth are the reasons anyone actually buys one; the second and the third are the ones the demonstration dwells on, because they are the easier pair to show on a screen. Take the record out of that list and what remains is a file store with a better interface, and your organisation almost certainly owns at least two of those already.

Which is precisely why an LMS is not a video platform, not a webinar tool and not a course marketplace, even though all three can present material just as well or better. A video platform knows that a file was played; it does not know that it was played by the person who had to complete that particular course by a particular date, that they got there on the second attempt, and that in a year the whole thing has to happen again from the beginning. The difference is not a row in the feature table that procurement builds, but the question the system can still answer two years later, when none of the people originally involved still works in the organisation.

The word “platform” misleads more than it helps here, because it covers both the systems that account for obligations and the ones that offer freely chosen material, and the same people sell both. The practical division is nonetheless simple and holds in every case: if somebody else decides what you have to learn and somebody checks that you did, that is a learning management system. If you choose for yourself and nobody follows up, it is a library — both can be useful at the same time, but only the first answers an auditor’s question, and it is usually that question which leads to a project.

The demand for that kind of accounting is not a peculiarity of any one country, and it is not small either: according to Eurostat, in the first quarter of 2025, 16% of people in the EU aged 16 to 74 had taken an online course during the previous three months, so learning on a screen surprises nobody any more. What does surprise is how rarely an organisation can say which of those courses was mandatory, which one was finished and how long the result stays valid, because those three questions are exactly what a system solves and exactly the ones nobody asks until the first inspection.

When do you need an LMS? Proof, not convenience

Most organisations arrive at a learning system not because the training grew harder but because proving it grew expensive. British law states the duty but never a number: the Health and Safety at Work etc. Act 1974 obliges an employer to provide the information, instruction, training and supervision necessary, and the Management of Health and Safety at Work Regulations 1999 add the occasions — on recruitment, and on exposure to new or increased risks from a transfer, new responsibilities, new work equipment, new technology or a new system of work — with training to “be repeated periodically where appropriate”. While the headcount is small and the deadline single, that is tracked in somebody’s head or a calendar. At two hundred employees with different start dates, and an interval you must justify rather than read off a page, error stops being a possibility and becomes a certainty.

The EU framework directive 89/391/EEC, which those regulations transposed and which still governs employers across the Union, requires training on recruitment, on transfer to other work, on new work equipment and on a change of technology. Each of those events creates a fresh deadline for a fresh group, and it is that combinatorics rather than the teaching material which starts to demand a system: the deadlines do not coincide, the groups overlap and none begins on the first of January. In regulated professions the threshold is lower still — a nurse or midwife on the UK register revalidates every three years and has to show 450 practice hours, 35 hours of continuing professional development of which at least 20 were participatory, five pieces of practice-related feedback and five written reflective accounts — and somebody has to count it and produce it on demand.

The scale is easier to grasp from how ordinary the need is: Eurostat’s figures show that in 2020, 67.4% of EU enterprises with ten or more employees provided staff with continuing vocational training, so this is the majority rather than a rare case, and the only variable is how each accounts for it. The honest reason for implementing an LMS therefore sounds unromantic: you need to know who has been trained, when it happened, how long it stays valid and what falls due next quarter, and you need it without telephoning a colleague on leave. If no such question exists and nobody is about to ask it, the system solves a problem you do not have, and that is the one kind of project no amount of good implementation rescues.

When it is not needed, and why that is rarely said out loud

The regulations ask for a record and say nothing about software, and that distinction matters more than it looks. The same Management of Health and Safety at Work Regulations require an employer with five or more employees to record the significant findings of the risk assessment, and prescribe no format, medium or system for keeping it; an attendance sheet with a date and signatures on it is a complete record and survives an inspection exactly as well as a screenshot from a platform. For fifteen people, one course and one deadline a year, a learning system adds maintenance, version upgrades and one more place to log in, and adds not one answer you were previously missing.

We also advise against a learning system when the organisation has no content yet, and that is the commonest case in which the project is better postponed. An empty system is not an investment in the future but an expense waiting for somebody to find time to write the courses — and after go-live that time is no easier to find than before. It is cheaper and quicker to write three courses as text and video first, distribute them however you already know how, watch which ones people genuinely use, and only then buy somewhere to put them. Done the other way round, the project more often ends with a platform holding two courses and no regular users.

The third case in which the answer is no is when the real need is not training but answers. If staff are looking not for a course but for one paragraph in an internal document — how to handle a particular customer case, what the procedure is in a particular situation — a learning system will not solve it, because it is built for sequential study with a check at the end rather than for a quick lookup in the middle of the working day. What helps there is search across the company’s own documents, which we wrote about separately in the article on a RAG solution for business documents — the two look confusingly alike in a demonstration, since both have a search box and both hold company content, yet they solve entirely different problems and rarely replace one another.

What the system actually records

Recording is where learning systems differ from one another most, and simultaneously the part that gets the least attention in a demonstration, because it looks dull. Enrolment answers who had to take the course; progress answers how far the person got; the completion record certifies that the conditions were met; the expiry date says how long all of it stays valid. The fourth is what cheap systems most often lack, and it is the one you will need every day, because the reminders, the recertification and the report to the board all rest on it.

In practice that means the system has to tell “watched the video” from “passed the assessment”, and both of those from “valid until”, in one view rather than in three separate reports. If it stores only the first, it is an activity log rather than a competence register, and in an audit it proves nothing beyond the fact that a file was opened. Ask the demonstration to show you one named person with one course passed, a second overdue and a third whose validity has run out, then watch how easily those three states can be told apart without a commentary.

The second commonly misunderstood part is that a learning management system is not a personnel record system and never becomes one. It knows about courses and results, but the job title, the department and the start date of the employment reach it from elsewhere, and it is that integration which decides whether enrolment happens automatically or by hand. If a new starter has to be enrolled manually, the system has not been implemented to the end — it has merely moved the same work out of a spreadsheet into a new interface, and in a year somebody will again ask why the two lists do not agree.

There is a further side to the record that gets less thought: the data frequently arises outside the system itself. If part of the training happens in an external tool — a simulator, a language platform, a manufacturer’s own learning environment — the question is whether the result finds its way back into your record automatically or somebody retypes it by hand. That is exactly what LTI (Learning Tools Interoperability) exists for, letting an external tool be attached without a separate login and returning a grade to the course, and exactly why a procurement is worth asking not only for the name of the standard but for which parts of it the supplier has implemented and how that was tested.

The standards that decide whether you can walk away

The question that looks technical at the start of a project and turns out three years later to have been commercial is this one: who owns the content and the records if you decide to change platform. It is answered not by a contract clause about returning data but by the formats in which the content and the records are actually held. SCORM is the oldest of them and still the commonest way to package a course so that it can be loaded into a different system; xAPI (Experience API) is a newer layer that describes not a package but events — who did what, and with what result — and keeps them in a separate repository called a learning record store (LRS).

Here is a nuance you will not find in a sales deck, and one that has changed the shape of the question in recent years: the ADL Initiative — the United States Department of Defense programme that created SCORM and published xAPI — has been closed, and its GitHub organisation, which GitHub verifies as the owner of adlnet.gov, states it plainly: “The ADL Initiative has been shut down.” That does not mean SCORM suddenly stops working, since the format is published and systems go on reading it, but it does mean there is no longer an active maintainer developing it behind the brand. The data model the SCORM run-time rests on is and remains an IEEE standard, though: IEEE 1484.11.1-2022 is active and was published on 15 April 2022.

xAPI has travelled in the opposite direction: it is standardised as IEEE 9274.1.1-2023, published on 6 October 2023, so it has a maintainer, and records created in that format stay readable even when the product around them changes. The third standard worth asking for by name is LTI, which allows an external tool to be attached without a separate login, and 1EdTech ended support for every version before LTI 1.3 after 30 June 2021 — which is why “we support LTI” without a version number has stopped being an answer. Moving an entire course is what Common Cartridge is for, and that is the one worth asking to see demonstrated rather than discussed.

Why “supports the standard” is not the same as “works”

The name of a standard in a specification and the behaviour of that standard in a particular system are two different things, and the best example is public in Moodle’s own documentation, which means it can be checked without any supplier’s help. It states that Moodle supports SCORM 1.2 and passes the ADL conformance tests for it, and that Moodle does not support SCORM 2004. A higher version number does not mean better support here — it means nothing until somebody has tested it — and a supplier who does not say so either does not know or is counting on you not to check.

From which follows a practical test that costs nothing, takes about an hour and tells you more than any testimonial: take one real course in the format your content already exists in today, and ask for it to be uploaded into a test environment during the demonstration rather than after the contract is signed. If the answer is that this will be handled during implementation, you have already learned the answer, and it is the cheapest information you will acquire in the whole project. The same applies to export: ask for the course to be taken back out and loaded into a different system, because that is precisely the operation that will one day be needed in a hurry.

A supplier’s claims about interoperability can also be checked entirely independently of the supplier. 1EdTech maintains a public TrustEd Apps directory of the products that have passed certification, and states clearly that a product not in the list has either not passed certification or has allowed it to expire. Five minutes in that directory says more than a fifty-slide deck, and it is practically the only source in this field the seller did not publish. A product’s absence from it is not a prohibition on buying, but it is a question worth having answered in writing.

The same caution applies to version numbers, which people are inclined to read as a measure of quality. LTI 2.0 looks newer than 1.3 by its number, yet 1EdTech lists it precisely among the earlier versions whose support was ended, so a proposal citing that number as an advantage is in practice offering an obsolete and unmaintained way of connecting. If a proposal carries no version number at all, it is worth demanding one in writing, because that is the single line which later decides whether integrating the next tool takes an hour or a project of its own.

LMS and LXP: what the difference actually is

Sooner or later a conversation about learning systems produces the abbreviation LXP, and it is worth an explanation, because it carries less weight than it sounds. An LMS assumes the organisation decides what each person has to learn and accounts for completion; a learning experience platform (LXP) names an approach in which the learner chooses the material and the system recommends, so the emphasis moves from obligation to interest. As a difference of emphasis it is real and occasionally useful — for voluntary professional development, accounting for obligations genuinely is not the point, and a list of compulsory courses rather gets in the way.

What the distinction does not have behind it is a standards body, or any technical boundary that could be tested. The term was announced publicly in September 2018 by the HR technology analyst Josh Bersin as his own coinage — “I coined the phrase ‘Learning Experience Platforms,’ and the name really stuck”, as he put it — and it has been used ever since mainly to segment the market. Two products wearing the same label can therefore differ as much as any two products without it, and a comparison by category name tells you nothing about what you will receive, so in the procurement table that column remains an empty space under a heading which produces a feeling of rigour without stating one testable requirement.

What is worth comparing is what remains in the database once the demonstration is over. The record layer both categories refer to is standardised — xAPI is IEEE 9274.1.1-2023 — and it is that layer which determines whether in three years you can still say what people learned, even if the product by then is a different one. If a supplier mentions the name of the category more often than the format in which records will be stored and retrieved, the conversation is about marketing, and it is worth saying so while everybody is still in the meeting.

In practice it is tested with two questions that can be asked in any demonstration. First: what determines that a particular person has to complete a particular course by a particular date, and where in the system is that decision visible? Second: in what format is the fulfilment of that obligation stored, and how is it retrieved if the product is replaced? If the answer to the first is that the system recommends but does not impose, then whatever the category is called, what you have is a library, and accounting for obligations will have to be solved somewhere else.

Where the learning system ends and another one begins

The boundary that projects cross most often is the one between the learning system and the student or personnel information system. The first manages courses, the second manages people: admissions, contracts, groups, job titles and status. A list of people can be typed into a learning system, which creates the temptation to use it as a register as well, and it is that temptation which produces the situation where two different versions of the truth exist simultaneously in two places about who is still an employee and in which department.

There is one practical principle and it is simple: a person is created where the organisation creates them, and only afterwards enters the learning system. If the employee register lives in the HR system, enrolment comes from there as well, while the learning system hands back the result and the expiry date. If that flow has not been defined in the requirements, it is almost always resolved with a monthly spreadsheet that somebody assembles by hand — and it is precisely the spreadsheet the project started from.

It is the same story with certificates and document handling: a learning system can issue a confirmation that a course was passed, but it is not a document management system, and long-term retention with legal significance usually belongs where the contracts and the orders already live, which is why the boundary between the two systems is drawn at the start of the project rather than on the day somebody first demands it. Drawn in good time, the list of integrations becomes shorter and cheaper; not drawn, a requirement nobody planned surfaces a year later, by which point the budget has been spent.

From which follows how to judge the reports, the thing procurement usually asks about last of all. A report is useful only if it answers a question somebody will genuinely ask — how many people in this department are overdue for their mandatory training, and when each one’s validity expires — rather than how many courses were opened this month. If the system receives its people structure from the personnel register, a report like that is one query; if it does not, it is a spreadsheet somebody assembles by hand every month out of two exports.

Moodle as an example, not as a recommendation

When the conversation reaches actual products, the name that comes up first is almost always Moodle, so it is worth saying what it factually is before the opinions start. Moodle is a learning management system developed and maintained by Moodle Pty Ltd, and it is freely available under the GPL. That means the source code is open and there is nothing to pay for the software itself, but it does not mean everything around it is free to use: the GPL covers the code, whereas the word Moodle and the logos are trade marks whose commercial use requires the owner’s prior written permission.

For the practical decision the maintenance rhythm matters more than the licence, because that is what sets the budget for the years that follow. Moodle publishes a release calendar with two major versions a year — April and October — and maintenance releases every two months; each major version receives twelve months of general support, an ordinary release gets security fixes for up to eighteen months, and an LTS release for up to thirty-six. Money and people are planned against that calendar, because a version whose support has ended is no longer a matter of taste but a matter of security, and it usually arrives at an inconvenient moment.

There are infrastructure requirements too, and they are worth checking before anything is promised: Moodle 5.2 requires at least PHP 8.3.0 and one of PostgreSQL 16, MySQL 8.4, MariaDB 10.11.0 or Microsoft SQL Server 2019. And one further thing is worth knowing before you read impressive adoption figures: the statistics published on moodle.org come from sites that registered themselves voluntarily, so they show the size of the community rather than a measured market share. Separately there is Moodle Workplace, available only through certified partners, and that is a different product with a different route to purchase.

None of the above should be taken as advice to choose this particular system, because the right answer depends on how many people, how many courses and how many expiry dates you actually have. Moodle is the example here because it is open and its documentation is public, which means every claim about it can be checked without a supplier’s mediation — and that is the property against which any candidate is measured, including a closed product whose documentation sits behind a login form.

What costs more than the licence

If the licence is free, the budget goes elsewhere, and it is far better to see where before the project than in the middle of it. The largest line is almost always content: writing the courses, recording the video, building the assessments, and maintaining that same content later, when procedures or regulations change. The second is migration, if something already exists — old Moodle versions, courses sitting in another system, participant history that has to be preserved because the validity periods are still running and the proof is still needed.

The third line is integrations and authentication, and this is where requirements differ most from one organisation to the next: single sign-on for the whole organisation, usually through SAML 2.0 or OpenID Connect against Microsoft Entra ID or Google Workspace, federated access through Jisc’s UK Access Management Federation in education, or a national eID scheme where the public sector requires one, plus the connection to the student or personnel register. The fourth, the one that appears in plans least often, is maintenance after go-live — version upgrades on the calendar described above, backups, user support and a small but unbroken flow of changes. We have written separately about how we cost such projects and in what order we carry them out on the Moodle development and maintenance page.

Before a conversation with any supplier it is worth reading what we have collected in the article on the commonest mistakes businesses make when commissioning development, because in learning system projects they repeat almost unchanged: undefined scope, an untested export and the assumption that content will somehow write itself. If you would like somebody to read your existing situation and say whether a system is the right answer here at all, write to us — sometimes the most honest answer is that what you already have is enough, and that the money is better spent on content than on a platform.

The fifth line, worth checking separately wherever the audience does not all read the same language, is localisation. The Moodle community has translated the system into more than 120 languages, but the completeness of those translations differs from one to the next, and it is publicly visible in Moodle’s own translation environment, which makes it checkable before the decision rather than after. In practice some of the less-used screens may still be in English when the interface is otherwise in the local language, and the choice between a complete translation and a partial one is yours rather than an accident — but only if you check it in good time.