How to Split a SCORM Course into Separate Modules

Splitting is the mirror image of merging, and it comes up just as often. Maybe you inherited one giant course and want to reuse just the safety module on its own. Maybe a multi-SCO package needs to become five separate catalog entries so different teams can be assigned different modules. Either way, "split this SCORM course" hides two genuinely different operations.

Two kinds of split

1. Splitting a multi-SCO package into separate single-SCO packages

If your package already contains several SCOs, each is largely self-contained. Splitting means: pull each SCO’s folder out, give it its own manifest with a single organization and item, rewrite any paths that assumed the multi-SCO layout, and repackage each as a standalone valid SCORM zip. This is the cleaner case because the content boundaries already exist.

2. Splitting a single course (one SCO) by slides

Harder, and more common with Storyline output, where the whole course is one SCO. Here "split" means choosing which slides go into each output and producing several smaller courses. Because the content was never designed to be cut, you have to repair everything the slides referenced — and this is where it goes wrong.

Why naive slide-splitting breaks the course

Storyline courses hard-code forward navigation: each slide stores the specific ID of the next slide to play, not a relative "next." When you split a course, the last slide of module A still points at the first slide of module B — which is no longer in the package. The learner hits a dead end, or the player throws an error.

To split safely you have to, for each output module:

• Repoint the forward jump on the final kept slide so the module ends cleanly instead of pointing into another module.
• Rebuild the menu/outline tree so it only lists slides that are actually present.
• Keep only the media each retained slide uses — but reference-count at the file level first, because the same media file is often shared across multiple slides under different asset IDs.
• Preserve caption tracks for the slides you keep; many players preload all listed captions at startup, so a missing-but-listed caption 404s immediately.
• Produce a fresh, valid manifest for each module with the file at the archive root.

Tracking after a split

Each new module becomes its own SCO, so it tracks its own completion and score independently. That is usually what you want — but it also means a learner’s progress in the original combined course does not carry over to the new separate modules. Splitting is a content operation, not a record migration; plan re-enrollment accordingly, and never assume old completions transfer to the new packages.

Test every output module

1. Play each module end to end and confirm there are no dead-end jumps and no missing-media 404s.
2. Check that the menu only shows slides present in that module.
3. Upload each module to a test LMS or SCORM Cloud and confirm it reports completion and score on its own.

A clean split is invisible to the learner: each module starts at the beginning, ends at the end, and reports completion as if it had always been its own course.

Splitting without hand-editing

ScormEdit splits courses in the browser. For a multi-SCO package it carves out each SCO into its own valid package; for a single Storyline course it lets you pick which slides each module keeps, then automatically repairs navigation jumps, prunes only safely-unused media, preserves caption tracks, and emits a valid SCORM zip per module with the manifest at the root. You upload one course and download several working ones — no XML, no minified JavaScript, and a record of exactly how it was divided.