Move SCORM courses to a new LMS: a migration checklist

To move SCORM courses to a new LMS, collect your original packages, check that the destination supports their format, and test a representative course before opening access. Treat learner accounts, enrolments, historical results and saved attempts as separate migration tasks. Uploading a SCORM ZIP does not establish that any of those records moved with it.

The awkward part of an LMS migration is often a question that sounds simple: “Will everything come across?” Your course screens might, while a client’s completion record stays in the old platform. A useful migration plan gives each part a destination and a test. You can then decide what must move, what needs a separate archive, and what can start fresh.

Separate the five things you are moving

Start with a small inventory rather than a bulk upload. A SCORM package is the published module you deliver. Your editable authoring project is another file or workspace. The people taking the module, their access and their learning records need their own checks.

A SCORM ZIP is one part of an LMS migration.

This distinction follows the standard’s own scope. SCORM defines course packaging and communication between a running module and its LMS. Rustici’s technical overview describes those as separate parts. Do not treat a course file as a backup of the whole learning platform.

Collect the files you can maintain

For each module, record its title, current version, authoring tool, SCORM format, owner and last content review. Mark whether you have the editable project as well as the published ZIP. If you only have a package supplied by a contractor, ask for the source project before the contractor becomes difficult to reach.

Articulate’s guidance distinguishes Storyline project files from published output and recommends keeping project versions and backups. It also says the files and folders in the published output must keep their structure. Keep a clean copy of the exported package rather than rebuilding it from an LMS download folder by guesswork.

Check the permission to reuse each course in the new school. For licensed training, ask the supplier whether the agreement covers a new LMS, your intended audience and any hosted media the module calls. An upload that works does not answer those questions. Record the supplier’s answer beside the package so the next administrator can find it.

Avoid changing the content and the platform at the same time unless the change is necessary. First move the known version and prove that it works. Then make the content update as a separate change. If an unexpected score appears, you will have fewer possible causes to investigate.

Map the course and the access rules

Decide where each package belongs before importing the library. A module named “Introduction” is understandable inside its old programme and rather less helpful in a folder of forty ZIPs. Give each one a source course, destination programme, section, lesson title and person responsible for checking it.

Keep a second mapping for access. Who receives the programme? When does access begin and end? Does finishing one activity unlock the next? Do a company buyer and an individual client receive the same content? Rebuilding the visible course outline does not prove that its access rules match the old school.

For example, you could be moving a client onboarding programme with a discovery module, a practical assignment and a coaching call. The SCORM ZIP carries the authored discovery activity. The assignment, community discussion and appointment belong to the wider programme you rebuild around it. Review those parts explicitly rather than expecting them to appear after the import.

Choose a policy for history and unfinished work

Ask the destination provider for a concrete answer about historical records: which fields can be imported, how identities are matched, and how an imported completion is labelled. If there is no supported path, agree where the archive will live and who can retrieve a record. A spreadsheet can be useful evidence without becoming a learner’s live progress inside the new LMS.

As one example of the distinction, SCORM Cloud provides a separate registration-results export containing completion, pass/fail, score and total time. A results export and a course package serve different jobs. Check what your current LMS provides rather than assuming it exports the same fields.

Give unfinished attempts a deliberate policy. You might let active clients finish in the old school, move them at a clear checkpoint, or ask them to restart a short module in the new one. Tell them what happens to their current answers. Only promise exact resume continuity when the source, destination and actual package have been tested together.

If completion evidence matters to your organisation, involve the person who owns those records before closing the old account. Agree the retention period and access process with them. Do not use a migration deadline as the moment to discover that no one can retrieve last year’s certificate.

Pilot one course before moving the library

Choose a pilot that includes your real constraints: a scored quiz, a long module with resume behaviour, or the browser and phone your clients use. A very simple sample is useful for checking the upload control, but it will not test the difficult parts of your course.

1. Open the module: check the first screen, internal navigation, media and any links to other resources.
2. Leave and return: move through a few screens, save an answer, leave the lesson and sign in again. Check the expected position and answer.
3. Try a failed attempt: if a passing score is required, finish below the threshold and check that access or completion does not advance incorrectly.
4. Pass the module: meet the intended rule, then check both the module result and the LMS lesson status.
5. Check the next action: open the following lesson, assignment or resource with an ordinary member account.

Write down expected and observed results, the package version and the device. A screenshot of a finished quiz proves less than the quiz and the destination lesson agreeing about completion. Keep evidence from the same attempt so you can compare the two without guessing which test produced which result.

Moving SCORM modules into SchoolMaker

SchoolMaker is an option when you want to bring existing SCORM activities into a programme with course lessons, practical work, coaching and community. It accepts SCORM 1.2 and SCORM 2004 ZIP imports. You continue editing the module in its authoring tool, then import the published package into a SCORM lesson.

Batch import in a local SchoolMaker test school. Each selected package becomes a lesson in the chosen section.

For a library, SchoolMaker can import up to 50 packages into a new or existing section in one operation. Each package becomes a separate lesson. This saves lesson setup; it does not move learner accounts, old completions or saved attempts from the previous LMS. Use the SchoolMaker SCORM import guide for the detailed upload and acceptance checks.

Check the package structure against the supported SCORM scope. SchoolMaker plays the first launchable learning object in a package; full SCORM 2004 sequencing across several SCOs is not implemented. If your existing course relies on that structure, test it before choosing the destination or ask the author to prepare an appropriate export.

The wider programme is where you can give an imported module a useful next step. Follow a discovery activity with a client interview assignment, a community discussion about what happened, or a coaching session for feedback. Reuse the authored activity and deliberately design the support around it.

Keep your own package archive after the move. When content export is enabled, the SchoolMaker owner can retrieve the original SCORM packages individually or together. This retrieves uploaded files; it does not convert native SchoolMaker lessons into SCORM or transfer learner history to another LMS.

Plan the switch and a way back

Set a short freeze window for changes in the old course. Otherwise, someone can update a quiz after you export it and before you open the new school. Record the final package version and take the agreed history export at a known time. Give one person responsibility for confirming that the new library matches the inventory.

Before inviting everyone, send a small pilot group through the full experience, including sign-in and access. Keep the old school available for the agreed overlap period. Decide what would make you pause the move: missing content, the wrong clients receiving access, or completion failing in the pilot are useful reasons.

If you need to pause, stop adding new learners to the affected course and give existing clients clear instructions about where to continue. Avoid asking people to alternate between two copies of the module without explaining which one holds their current result. Reconcile the pilot’s records before resuming the wider rollout.

Your migration is ready when you can answer four practical questions: where is the editable source, does the imported package work, can the correct client access it, and where will you find that client’s old results? An upload confirmation answers only one part of that list.