Voctus
ServicesProcessWorkPricingInsightsAbout REQUEST_PROPOSAL →
12 June 2026

SCORM 1.2 vs SCORM 2004: which to ask your vendor for

SCORM 1.2 runs correctly in effectively every LMS; SCORM 2004 adds sequencing and richer reporting but support is uneven. The decision rule, the differences that matter, and the test to demand before handover.

Ask for SCORM 1.2 unless you have a verified reason not to. It is the most universally supported e-learning standard, runs correctly in effectively every LMS including Moodle, and covers what most corporate training needs: launch, progress, score, completion. SCORM 2004 adds sequencing rules and richer status reporting — but LMS support for those additions is uneven, and a 2004 package that exercises them can fail in platforms that nominally accept it.

That is the whole decision for most buyers. The rest of this guide is the detail behind it, because “which SCORM?” is a question vendors answer suspiciously fast.

What actually differs

Status reporting. SCORM 1.2 carries one status field with mixed meanings (completed, passed, failed…). SCORM 2004 splits it into two — completion status and success status — so a learner can be recorded as completed but failed, which auditors and retake policies sometimes genuinely need.

Sequencing. SCORM 2004’s headline feature: rules that control the order learners move through course sections, prerequisites, and what happens after a failed assessment. Powerful on paper. In practice it is the least-consistently implemented part of the standard, and the source of most “works in the demo, breaks in production” stories.

Data limits. 1.2 allows a famously small space for suspend data (the bookmark that lets a learner resume mid-course); 2004 raises it dramatically. Long courses with many interactions can hit 1.2’s ceiling — a real reason to step up, and one your vendor should detect at design time, not after learners lose their place.

Everything else is the same. Both are LMS-launched packages with a manifest file; both report to the LMS through a JavaScript API; both are decades old and going nowhere — which for compliance infrastructure is a feature.

The decision rule

  1. Default: SCORM 1.2. Maximum compatibility, fully sufficient for completion tracking, scores, and audit evidence.
  2. Step up to 2004 only when you need completed-vs-passed separation, sequencing rules your LMS demonstrably supports, or suspend data beyond 1.2’s limit — and your vendor has verified 2004 behaviour in your actual platform, not just promised it.
  3. Multi-LMS estates ship 1.2. If subsidiaries run different platforms, the lowest common denominator is the deliverable that works everywhere. One white-label client pattern we see repeatedly: a 2004 package built for the head-office LMS, quietly failing in two regional ones.

The test to demand

Whatever version you choose, require evidence of testing in SCORM Cloud — the industry’s reference implementation — before handover: launch, progress tracking, scoring, resume, and completion, not just “the file uploads”. A package that behaves in SCORM Cloud and then misbehaves in your LMS has isolated the problem to the platform’s quirks, which are fixable; a package never tested against the reference leaves you debugging both ends at once.

If a vendor cannot tell you how they test conformance, that is your answer about the rest of their process too.


Voctus delivers SCORM 1.2 by default, 2004 where platform support is verified, and tests every package in SCORM Cloud before handover — details on the SCORM & LMS delivery page.

Share one document.
Receive a scoped proposal.

Send any representative training asset — a deck, a manual, a recording. Within one business day you will receive a fixed statement of work, timeline, and delivery plan. Asynchronous by default; a call is available when your process requires one.

Request a proposal or write to hello@voctus.studio