Is SCORM Dead?

I thought it might be helpful to explain a bit about how the SCORM standard is used and some of its pros and cons.

Is SCORM Dead?

I think every few months I see someone on social media telling me ‘SCORM is dead’.

But what is SCORM, and why would it be dying?

I’m not particularly technical, so I won’t try to explain that much about how the SCORM standard works, but I thought it might be helpful to explain a bit about how it’s used and some of the pros and cons, when it comes to working with an organisation’s learning management systems. (The other reason SCORM might be dying is that it’s possible to host online learning outside these systems. But that’s a topic for another post.)

A SCORM package, from my perspective, is a zipped folder containing a self-contained HTML website. Inside it are settings that can be read by a SCORM-compatible database, like a learning management system. When we upload a SCORM package to a learning management system, the users of the learning management system can launch the mini-website and interact with it. It can contain quizzes and other interactions that create data, like quiz results, which the learning management system can track.

So if we want to make a learning experience that consists of online interactions and that produces data around how the users have worked with those interactions, a SCORM package will do that.

Some common SCORM authoring tools are Articulate Storyline, Articulate Rise, Chameleon, and Adobe Captivate. Learning designers work with these tools, just like graphic designers work with tools like Indesign and Illustrator, and then they export the SCORM files, just as graphic designers export PDFs and images from their tools.

Can’t the learning management system do that, though?

Yes. I think this is one of the main reasons I keep seeing ‘SCORM is dying/dead’ posts.

Many learning management systems, like Totara, Talent, and Moodle, can provide pretty much the same functions as a SCORM package: images, text, videos, audio files, quiz questions, branching scenarios, and so on. And they keep getting better. Version 18 of Totara (which was the latest version in 2024) didn’t have anything like as good course navigation as Version 19 does.

With this the case, we have to wonder why we would bother making special zip files full of the same stuff that the main system can do anyway.

Why are SCORM packages handy?

There are four main reasons I know of for SCORM packages being used. Three are very sensible. The fourth, not so much, unless an organisation is outsourcing a lot of learning design.

  1. Because it’s a self-contained website, the learning designer can plan a good flow of activities with good UX. Often in learning management systems, the options for moving from one activity to the next are limited by the system, and it may not be that easy for the learner to follow. If you’ve ever walked through a door and completely forgotten what you were going there for, you’ll know what sort of effect asking learners to think about navigation while they’re trying to learn can have. People lose their focus if the navigation becomes distracting. So building a single SCORM packages allows the learning designer to manage the learning experience to keep the learners’ focus where it will help them.
  2. We don’t always keep the same systems forever. If all the learning modules are built as SCORM packages, then an organisation can change learning management systems more easily. Because SCORM is a standard used across many systems, all the modules will still work if they’re imported into the new system. And they’re already zip files, so uploading them is fairly quick.
  3. Depending on your system, it’s also very likely that the review process will be a lot easier if you are building in a SCORM authoring tool like Rise, Storyline, or Chameleon, since learning management systems don’t really have review functionality built in, and these tools do.
  4. Finally, if an organisation is working with an external supplier to source an e-learning module, developing it as a SCORM package means the supplier can just hand over the zip file. Otherwise, there is a decision that must be made about who will build the module in the learning management system, another decision about how to ensure security of the learning management system, and a risk that the system might not function exactly how the external supplier expects, since different organisations have different settings, even if they have the same learning management systems. Building as SCORM makes it much easier to purchase modules.

So which do I prefer?

It really depends on the system.

The lack of review functionality in Totara and Talent (as far as I can tell), is very frustrating. For both, it’s mostly just ‘publish’ or ‘don’t publish’ — there is no good commenting option for reviewers. If I was designing a learning solution for a client who had very low knowledge of e-learning, I might want to use SCORM just so they’d have a way to do reviews effectively.

The way learning management systems restrict navigation options is definitely not ideal for me. Neither is the way SCORM packages in Totara and Moodle have to open in new windows or new tabs (unless you have programmers available to create and maintain custom plugins).

However, this needs to be considered against the much, much better options for activity types, evaluation, and assessment that can be found in Totara or Moodle. Because Totara and Moodle have systems for human marking and for creating blended learning that integrates online and face-to-face learning, it is possible to design a broader range of learning activities that go much deeper than a machine-marked SCORM package can handle.

Overall, I’m really enthusiastic about building directly in the system where the learners are going to be working.