Why migration breaks courses that were fine
A SCORM package is not truly portable; it is portable in theory and platform-dependent in practice. A course that ran for years on one LMS can misbehave on another because the two implement the runtime differently — different commit timing, different strictness on suspend data, different handling of a missing score, different launch mechanics. Nothing in the package changed, but the platform reading it did. Migration is where all of these differences surface at once, which is why "we just moved LMS and half the courses show incomplete" is such a common story. It is preventable with a bit of process.
Inventory what you actually have
Before moving anything, list every course with the facts that matter for migration: which SCORM version it is, whether it is a single SCO or multi-SCO with sequencing, how much suspend data it uses, whether it carries a quiz and how completion is defined, and where the source lives if you need to rebuild. Courses whose source you no longer have are the risky ones — if a package breaks on the new platform and you cannot rebuild it, your only options are to fix the zip by hand or re-author. Find those now, not during cutover.
Re-validate every package against the new platform
Do not assume a package that imported on the old LMS will import on the new one. The new platform may validate the manifest more strictly, reject data model elements the old one tolerated, or launch SCOs in a frame the content does not expect. Run each package through a test player configured to match the new platform's behaviour, and read the runtime log for the things that commonly differ: does Initialize still succeed under the new launch method, does the bookmark still save, does completion still land. This is exactly the pre-upload testing described in testing before upload, applied to your whole catalogue.
Decide what happens to completion history
This is the decision people forget until it is too late. SCORM completion records live in the LMS, not in the package. When you move platforms, that history does not come with the courses unless you deliberately export and import it — and the two platforms may not represent it the same way. Decide early: are you migrating historical completions, starting fresh, or keeping the old LMS read-only as a system of record for a period? Each is defensible; discovering the question during cutover is not. If completions are compliance evidence, involve whoever owns that requirement before you move.
Watch the runtime differences that bite
The specific behaviours that most often change between platforms:
- Commit throttling. The new LMS may drop rapid commits the old one accepted, causing final completions to vanish. See why completions go missing.
- Suspend-data strictness. A course near the 4 KB SCORM 1.2 limit that was tolerated on the old platform may be truncated on the new one, breaking resume.
- Status-order sensitivity. The new platform may lock the record on first completion and ignore a later score.
- Launch method. New window vs. iframe changes where the content finds the API; a course that assumed one may fail on the other.
A saved profile per platform makes this testable: replay a course's session against the new platform's profile and the failures show up before a learner finds them.
Use dispatch to decouple content from the platform
If you migrate LMS often, or you distribute the same courses to several platforms, consider not putting the real package in the LMS at all. A dispatch is a thin launcher that the LMS imports while the actual course stays hosted on your side. When you move platforms, you import the launchers into the new LMS and the content does not move; when you update a course, every platform gets it without a re-import. Dispatch adds a live-connection dependency and hosting responsibility, so it is not right for every case, but for a catalogue that moves between platforms it turns migration from a re-import project into a re-launch.
A migration checklist
- Inventory every course: version, SCO count, suspend usage, completion rule, source location.
- Flag courses whose source is missing; decide their fate before cutover.
- Re-validate each package against the new platform's profile; read the runtime log.
- Decide the fate of completion history: migrate, reset, or keep the old LMS read-only.
- Test the four common runtime differences: commit throttling, suspend strictness, status order, launch method.
- Pilot with a representative subset and real learners before moving the whole catalogue.
- Consider dispatch for content you expect to move or update again.
Migration goes wrong when courses are treated as portable black boxes. Treated as packages with known runtime dependencies, tested against the destination before cutover, it is routine. The tooling that makes it routine — validation, runtime logs, platform profiles, and a source you can rebuild from — is the same tooling that makes any SCORM delivery reliable.