Course Versioning and Overwriting


Course overwriting allows users to directly overwrite internal course files on the filesystem. This power can be dangerous, as changing the course files themselves might mean that existing registrations are suddenly incompatible with the course.

For this reason, we recommend that only advanced users use the course overwriting feature. However, it is useful for simple typo fixes that do not affect the course structure or otherwise cause issues with existing registrations.

In the API, updateAssets can be used to update the course files directly on the filesystem. Note that this API call does accept a “sparse” zip file, in which case only files matching the paths of files in that zip file will be updated: this can be useful.

Overwrites can also be done directly through the SCORM Cloud UI. As mentioned in that article, overwriting via the UI can be useful for testing as well, since it prompts the user to reset all existing registrations if the manifest has changed.


The notion behind course versioning is that a user uploads a new version of a course. The old version(s) of that course, along with all of the historical data that goes with them, are still kept. New registrations that are created against that course will then use the latest version. This is useful for structural changes that impact existing registrations.

In the API, to create a new version of a course, simply call importCourseAsync with an existing course ID. To get a list of course versions through the API, call getCourseDetail.

Versioning can also be done directly through the SCORM Cloud UI.

Existing Registrations

As above, new registrations against a course will use the latest course version. The behavior for existing registrations, however, is configurable.

Here are the available choices for the ‘Move Existing Registrations to Newest version’ option. Each of these is checked when the learner launches a registration.

  • Never – keep existing registrations on the old version (the default)
  • If Incomplete – if a registration is marked incomplete (or unknown)
  • When Completed – if a registration is marked complete
  • When Failed – if a registration is marked complete and failed
  • When Passed – if a registration is marked complete and passed
  • Always – always move to the latest version


When a registration moves to a later version, a new instance of that registration will be created (that is tied to the newest course version). To the learner, this will effectively reset their progress in the course. Versioning works this way because new course versions may change the structure of the course itself – especially if multi-SCO – so we cannot guarantee old registration state is compatible with new course versions.

Data about old instances of registrations, which are probably tied to different course versions, can be retrieved using getRegistrationResult with the optional instanceid parameter. A list of instances can be retrieved using getRegistrationDetail.