What happens when you re-import a package
A SCORM package is an archive: the LMS unzips it, hosts it and launches it. Updating the module therefore means replacing the archive. On paper, it is a two-minute job. In practice, three questions come up every time, and the answer depends on the LMS and how it is configured.
What happens to existing completions? Some LMSs keep them on the same course, some create a new version of the course with its own tracking, others ask you to create a new course and re-enrol learners.
What happens to learners in progress? A module stores the point where the learner stopped. If the structure of the content has changed, that position may no longer point to anything. Depending on the case, the learner restarts from the beginning, resumes in the wrong place, or stays on the old version until they finish.
Who is allowed to do it? Importing is often restricted to an administrator. In a group, that means a request, a delay and a different person for each environment.
The problem multiplies with the number of LMSs
A regulatory module rarely lives in one place. You find it in the head-office LMS, in the LMS of a subsidiary that kept its own tool, on a partner network portal and, for a publisher, at every one of its clients.
Each revision then triggers as many re-imports as there are environments. They are never done on the same day, and sometimes never done at all. Between the first and the last, two populations take two different pieces of content under the same title, and nobody has an overall view of where each environment stands.
For general-interest content, that is an annoyance. For a safety procedure or a compliance module, it is a gap you will have to explain.
Three methods, and their limits
| Method | What it gives you | Its limit |
|---|---|---|
| Manual re-import | No extra tooling | Delays, omissions, no overall view |
| Link to hosted content | A single copy to update | The LMS no longer receives tracking |
| Lightweight package to a single source | A single copy, tracking preserved | Depends on the availability of the source |
1. Manual re-import, with a checklist
This is the default method, and it remains reasonable for one or two environments. It needs a list of where each module is published, an owner per environment and a record of the date of every re-import. Without that discipline, you no longer know which version is running where.
2. A link to content hosted elsewhere
You can take the content out of the LMS, host it on a server and leave only a link in the LMS. Updates become immediate everywhere. But content opened through a plain link no longer talks to the LMS: completion, score and time spent stop being reported. For mandatory training, that is exactly what you could not afford to lose.
3. A lightweight package that points to a single source
The third method combines the two. The content is hosted once. Each LMS imports, once, a small SCORM package that does not contain the module but knows where to fetch it, then relays tracking to the LMS as a regular package would. For the learner and the administrator, nothing changes. For the team that manages the content, an update happens in one place.
What to check before you choose
The third method is not magic. Before adopting it, put these questions to the tool you are evaluating, and test them in your own LMS.
- Does tracking really come through? Completion, success, score and time spent must appear in the LMS as before.
- What happens to a learner in progress at the moment the version changes?
- Are your formats supported? SCORM 1.2 and 2004 do not behave the same way, and you may also have cmi5 or xAPI content.
- Does your network let the content through? The learner’s workstation must be able to reach the source. In a bank, that is validated with IT.
- Who decides when the new version is served? An instant update everywhere is only an advantage if it is decided, not imposed.
Where Sajay Dispatch fits
Sajay Dispatch uses the third method. Your modules are hosted once, your LMSs import a lightweight package, and a revision no longer needs any re-import. SCORM 1.2 and 2004, cmi5 and xAPI are supported.
The difference lies in the fifth point of the list: the new version is not pushed automatically. You choose which version is in force, you can go back to the previous one, and every launch stays tied to the version actually served.