SCORM vs xAPI vs cmi5: choosing the right eLearning standard

SCORM vs xAPI vs cmi5 comes down to where learning happens and how much data you need. SCORM packages a course so any compliant LMS can launch it and record completion, score and time, but only inside a browser session run by that LMS. xAPI records almost any learning activity as a simple statement ("Priya completed Fire Safety Module 3") and sends it to a Learning Record Store (LRS), whether the learner is in an LMS, a mobile app, a simulator or offline. cmi5 sits between them: it is a set of rules on top of xAPI that tells an LMS how to launch content, manage a session and decide when a learner has completed or passed.

LTI 1.3 is often thrown into the same conversation, but it answers a different question. LTI securely launches an external tool (a coding lab, a video platform, a publisher's courseware) from inside your LMS and, through LTI Advantage services, can send grades back and read the class roster. It does not describe how to package or track content.

This guide explains each standard in practical terms, compares them in one table, and gives scenario-based recommendations and migration tips from an integration engineer's point of view.

SCORM 1.2 and SCORM 2004: the incumbent

SCORM (Sharable Content Object Reference Model) was created under the US Department of Defense's Advanced Distributed Learning (ADL) Initiative. A SCORM course is a zip file with an imsmanifest.xml describing its structure. The LMS unpacks it, launches the content in a browser window or frame, and the content talks to a JavaScript API the LMS exposes to set values such as lesson status and score.

SCORM 1.2

SCORM 1.2 is the simplest and most widely supported version. It reliably tracks what practitioners call the "big four": completion, score, time and satisfaction. Its main technical limit is the suspend_data field used for bookmarking and resume state, which is capped at 4,096 characters. Long, interaction-heavy courses exported from authoring tools can exceed that, which is a common cause of learners losing their place.

SCORM 2004

SCORM 2004 (the latest edition is the 4th Edition) raises suspend_data to 64,000 characters, separates completion status from success status, records richer interaction and objective data, and adds sequencing and navigation rules so a course can control what a learner sees next. That power comes with complexity, and LMS support is uneven. For example, Moodle's own documentation states that core Moodle passes the ADL conformance tests for SCORM 1.2 but does not support SCORM 2004, and points to third-party plugins for it.

The structural limits of SCORM apply to both versions: content must run in a browser launched by the LMS, the data model is fixed, and tracking stops the moment the learner leaves that session.

xAPI and the Learning Record Store

xAPI (the Experience API, originally known as Tin Can) was designed to remove those limits. Instead of a JavaScript API inside an LMS frame, content and systems send JSON statements over a REST web service. Each statement has an actor, a verb and an object, plus optional result and context data. Statements go to a Learning Record Store, which can be a standalone service or built into an LMS.

Because any system that can make an HTTPS request can send statements, xAPI can track mobile apps, simulations and VR, performance support tools, instructor observations, and learning that happens with only occasional connectivity. In 2023 xAPI was approved and published as IEEE 9274.1.1-2023, often referred to as xAPI 2.0. Rustici Software's guidance is that vendors will support 1.0.x and 2.0 side by side for a long time, so there is no need to rush an upgrade.

The catch is that plain xAPI says nothing about how an LMS should launch content, authenticate it or decide it is "complete". Two xAPI courses from different vendors can report very different verbs and structures, which makes consistent reporting hard. That gap is exactly what cmi5 fills.

cmi5: xAPI with rules for the LMS

cmi5 is an xAPI profile: a set of extra rules for the specific case of a learner launching content from an LMS. The work started at the AICC and moved to ADL, which now maintains it. The production release is the Quartz edition. In practice cmi5 defines:

• Course structure: a course structure file lists the assignable units (AUs) and their launch URLs, so content can be hosted anywhere, not just unzipped on the LMS server.
• Launch and authentication: the LMS launches each AU with parameters that let it fetch a short-lived token and write statements to the LMS's LRS endpoint.
• Session rules: a fixed set of "cmi5 defined" verbs such as launched, initialized, completed, passed, failed and terminated, so every conformant course reports the same way.
• Completion logic: a moveOn criterion per AU (for example completed, passed, or completed and passed) that the LMS uses to decide when the unit and course are satisfied.

Beyond those defined statements, content can still send any additional xAPI data it needs. Think of cmi5 as SCORM's job done with xAPI's plumbing.

Where LTI 1.3 and LTI Advantage fit

LTI (Learning Tools Interoperability), maintained by 1EdTech, connects an LMS (the platform) to an external application (the tool) so learners do not log in separately. LTI 1.3 replaced the older OAuth 1.0 signing with a security framework built on OAuth 2.0, OpenID Connect login and signed JSON Web Tokens. LTI Advantage adds three services on top:

• Deep Linking so instructors can pick specific content inside the tool and place it in a course.
• Assignment and Grade Services (AGS) so the tool can create gradebook columns and post scores.
• Names and Role Provisioning Services (NRPS) so the tool can read the course roster and roles.

The key distinction: SCORM, xAPI and cmi5 describe content and tracking; LTI describes a secure tool launch. The tool keeps its own data and only returns what AGS allows, typically a score. Moodle's documentation, for instance, now labels LTI 1.1 and 2.0 as deprecated and recommends publishing through LTI Advantage.

SCORM vs xAPI vs cmi5 vs LTI: side-by-side comparison

Which standard to choose, scenario by scenario

• Compliance courses from an authoring tool, delivered in one LMS: SCORM 1.2 is still the lowest-risk export. Choose SCORM 2004 only if you need its larger suspend data or sequencing and you have tested it on your LMS.
• New course library you want to future-proof: cmi5, provided your LMS and authoring tool both support it. You keep LMS-driven launch and completion while gaining xAPI data and remote hosting.
• Simulations, mobile apps, field or on-the-job learning: xAPI with a standalone or embedded LRS, and a written statement design (agreed verbs, activity IDs and context) before anyone writes code.
• Cross-system analytics: xAPI statements from every source into one LRS, then into your BI tool. Many teams pair this with an xAPI log exporter on the LMS itself.
• Third-party tools such as labs, assessment engines or publisher content: LTI 1.3 with Advantage services. Do not try to force these into SCORM wrappers.
• Selling content to many client LMSs: ship SCORM 1.2 for reach, offer cmi5 where clients support it, and consider an LTI tool if you need central control over content and data.

If you are also choosing a platform, standards support belongs on the requirements list alongside everything else; our Moodle vs Canvas comparison covers how two popular platforms differ.

Migration and compatibility tips

1. Inventory before you convert. List every package with its standard, version, authoring tool and whether source files still exist. Packages without source are the hardest to modernise.
2. Test on the target LMS, not on a generic player. Resume, retake, score rounding and status mapping (for example "passed" vs "completed") differ between LMS implementations.
3. Map historical records explicitly. When moving platforms, decide how SCORM attempts map to completions and certificates in the new system. We cover the usual traps in LMS migration mistakes.
4. Design xAPI statements like an API. Fix verb IRIs, activity ID patterns and required context fields in a short profile document; inconsistent statements are expensive to clean later.
5. Plan the LRS as infrastructure. Size it for statement volume, set retention rules, and secure its credentials; statements often contain personal data.
6. Do not wrap SCORM in LTI without a reason. It works, but you add a second system to maintain. Use it when you need central hosting across many LMS tenants.

How we can help

We implement and troubleshoot SCORM, xAPI, cmi5 and LTI 1.3 across Moodle, Open edX, Canvas and WordPress-based LMSs, including LRS setup, custom launch and grade passback, and content conversion during migrations. If you are deciding how your content should be packaged and tracked, see our LMS integration services and LMS migration services, or talk to an engineer about your stack.