SCORM, xAPI, cmi5, and LTI get thrown around in LMS conversations like they're competing options for the same job. They aren't. Each one solves a different problem, and picking the wrong one to anchor a new build creates rework that shows up months later, not at launch.
This comes up constantly in early scoping conversations with edtech clients, usually framed as 'should we support xAPI,' when the real question is what the platform actually needs to track and integrate.
Key takeaways
- SCORM, xAPI, and LTI solve three different problems: SCORM packages and delivers courses, xAPI tracks what a learner actually does, LTI plugs external tools into your LMS. Picking one to cover all three usually means picking wrong.
- SCORM 2004 remains the most widely deployed standard despite being frozen since 2009, mainly because so much existing course content is already built for it.
- cmi5, an xAPI profile, brings back SCORM-style launch and completion rules while using xAPI's richer tracking underneath, the practical middle path for new content built in 2026.
- The real decision isn't which acronym to support, it's what you actually need to track, structured course completion, granular learner behavior, or third-party tool integration, and building to that, not to all four at once.
01What each standard actually does
According to eLearning Industry, a trade publication covering these standards for over a decade, the distinction is simple even though the acronyms rarely get explained clearly: SCORM and cmi5 are packaging standards, they package and deliver a course. xAPI is a tracking standard, it records what a learner actually did. LTI is a launch standard, it plugs an external tool into your LMS through something like an iframe.
SCORM 2004 4th Edition remains the most widely deployed e-learning standard even now, despite being frozen since 2009, mostly because a large volume of existing course content was already built against it and migrating it isn't free.
4
Distinct jobs these standards do: package (SCORM/cmi5), track (xAPI), integrate (LTI), and none of them substitute for the others
Picking the wrong standard to anchor a new build creates rework that shows up months later, not at launch.
02Where teams get this wrong
The most common mistake is choosing xAPI because it sounds more modern, then discovering it's meaningfully harder to configure correctly and requires a Learning Record Store the team wasn't planning to stand up and maintain. The second most common mistake is sticking with pure SCORM because it's familiar, then hitting a wall the moment the platform needs to track granular learner behavior SCORM was never built to capture.
cmi5, an xAPI profile, exists specifically to split the difference: it restores SCORM-style structured launch and completion rules while using xAPI's richer tracking infrastructure underneath. For new content built now, that combination is usually the more defensible default than either pure SCORM or raw xAPI alone.
03What we build
We start from what the platform actually needs to know, not from a standard picked in advance. If existing SCORM content needs to keep working, we build for that reality rather than forcing a migration the client never asked for. If granular behavioral tracking is the real requirement, cmi5 or xAPI gets scoped in deliberately, with the Learning Record Store decision made upfront, not discovered mid-build.
Where the platform needs to pull in third-party tools or content, LTI gets scoped as its own integration layer, not conflated with the tracking or packaging decision.
04What not to do
Don't commit to supporting all four standards from day one because it sounds thorough. Each one adds real implementation and maintenance surface area, and supporting a standard nobody actually needs yet is scope you'll maintain forever for no benefit.
We haven't built support for every legacy SCORM 1.2 edge case that exists in the wild. If you have a large existing content library, tell us its specific format early, that shapes the real migration scope.
05Which standard, when
A quick map from what you actually need to the standard that fits it.
| What you need | Standard | Why |
|---|---|---|
| Existing SCORM content to keep working | SCORM 2004 | Frozen but universally supported, migration has a real cost |
| Granular tracking of learner behavior | xAPI or cmi5 | xAPI tracks broadly; cmi5 adds SCORM-style structure on top |
| Pull in third-party tools/content | LTI | Purpose-built launch/integration standard, not a tracking or packaging tool |
06Getting started
Name what you actually need to track or integrate before picking a standard. The acronym follows the requirement, not the other way around.
Audit any existing course content for its current format before committing to a migration path. Compatibility, not preference, should drive that decision.
Scope the Learning Record Store decision explicitly if xAPI or cmi5 is in play. It is infrastructure you will maintain, not a checkbox in a vendor comparison.
Frequently asked questions
Not automatically. xAPI is the right call when you genuinely need granular tracking of learner behavior across platforms and are prepared to run a Learning Record Store. If structured course completion is all you need, SCORM or cmi5 may be simpler and sufficient.
xAPI is the underlying tracking standard. cmi5 is a specific profile of xAPI that adds SCORM-style launch and completion rules on top, giving you richer tracking with more structure than raw xAPI alone. For new content, cmi5 is generally the more practical default.
An honest inventory of your existing content format and a clear statement of what you need to track or integrate going forward. That combination determines the right standard, not which one is newest or most talked about.