How to convert PowerPoint to SCORM without losing the tracking that makes it worth doing

What conversion actually produces

A PowerPoint deck converted to SCORM is a single SCO: one HTML page, usually with a slide viewer, wrapped in a manifest. The viewer shows slides in order, and somewhere in its JavaScript it calls the SCORM API to record where the learner is and whether they finished. That last part is the entire reason to convert rather than upload the PPTX to a shared drive, and it is the part most converters get vague about. Before choosing a tool, decide what "finished" means for this deck and check that the tool will report exactly that.

Prepare the deck first

Conversion is faithful to the source, including its problems. Ten minutes on the deck saves an hour of rebuilding.

1. Put real titles on every slide. Converters build the course outline from slide titles. "Slide 14" as a section name is what you get when the title placeholder is empty.
2. Remove slide-level animations you rely on for meaning. Most conversion paths render each slide as a static image or a simplified HTML layer. Build-in animations are flattened; a slide that reveals four bullets one by one becomes a slide with four bullets.
3. Embed media, do not link it. Video linked from a local path will be missing in the package.
4. Check the notes pane. Speaker notes can become on-screen transcript or narration text. If they contain "remember to tell the joke here", edit them.
5. Mark the knowledge-check slides. A slide with a question and four options is just a picture to a converter unless it knows it is a question. Tools that detect questions will propose them as draft interactions; you still review them.

Decide the completion rule before you build

This is the decision that determines whether your LMS reports are useful. The common options:

• Viewed every slide. Simple, and what most decks need. The package sets completion when the last slide has been reached (or, more strictly, when every slide has been visited).
• Viewed every slide and passed a quiz. The package tracks slides for completion and a score for success. In SCORM 2004 these are separate fields; in SCORM 1.2 they collapse into one status, so "completed but failed" is not representable — the package has to pick.
• Minimum time. Rarely a good idea on its own; it rewards leaving the tab open. Combine it with slide tracking if compliance needs a time floor.

Write the rule down in one sentence, for example: "Completion when all 32 slides are viewed and the final check scores 80% or higher." That sentence becomes your test case.

Choose the SCORM version for the destination

Ask whoever owns the LMS which version they prefer. If they do not know, ship SCORM 1.2 — it imports on everything. Choose SCORM 2004 when you need completion and success reported separately, or when the deck is long enough that the bookmark and quiz state will exceed the 4 KB limit on cmi.suspend_data in 1.2. A 60-slide deck with a 20-question quiz can hit that limit; a 15-slide deck will not. The full decision rules are in SCORM 1.2 vs 2004.

Build, then read the conformance report

Import the deck, confirm the detected outline matches the slide titles, set the completion rule and the standard, and build. What you should get back is not just a zip but a report of what the package will do:

Manifest validates        imsmanifest.xml against SCORM 1.2 schema   ✓
Sequencing                n/a for 1.2                               —
Suspend data              2.1 KB of 4 KB                            ✓
Completion logic          cmi.core.lesson_status = "completed"
                          when slide 32 reached                     ✓
Score                     cmi.core.score.raw set before status      ✓
Commit frequency          every slide change                        ✓

If your tool does not show you something like this, you are trusting that it did the right thing. The two lines to look at hardest are suspend data (is there headroom?) and the order in which score and status are set (some LMSs freeze the record at the first "completed" and ignore a score that arrives later).

Test it like the LMS will

Open the package in a test player, go through the deck exactly as a learner would, and watch the runtime log. You are checking four things: the bookmark is written as you move, the course resumes at that bookmark when you close and reopen it, completion is set precisely when your one-sentence rule says it should be, and the final Commit and Terminate actually happen when you exit. Then replay the same session against the profile of the LMS you are shipping to — Moodle throttles commits differently from Cornerstone, SuccessFactors enforces suspend-data size strictly, and so on. A package that passes on the generic player and fails on the customer's platform is the most common support ticket in this field. Testing a SCORM package before the LMS does covers the full checklist.

What gets lost, and what to do about it

Be realistic about the trade-offs.

• Animations and transitions — flattened. If a build-up matters, split it into two slides.
• Embedded fonts — usually rasterised or substituted. Check any slide with unusual typography.
• Hyperlinks between slides — sometimes preserved as navigation, often not. Test them.
• Detailed interaction data — a SCORM 1.2 package reports the final score. If you need to know which question each learner missed, build for SCORM 2004 with interactions enabled, or emit xAPI statements alongside the package so they land in a learning record store.

None of this is a reason not to convert. A deck that reports completion reliably on the LMS it was meant for is worth far more than a perfect-looking one that loses half its completions. Get the tracking right first; the polish can come in the next build.