Decide what a new course package does to existing progress

Classify the change by its effect on saved state

SCORM Cloud’s versioning guide, checked on 7 November 2026, distinguishes overwriting files from retaining separate course versions. It warns that moving an existing registration to a newer version creates a new instance and effectively resets progress, while older instance data remains available. This is SCORM Cloud behavior, not a guarantee for every LMS.

Describe what changed beyond the visible title: unit identifiers, branching, questions, completion requirements or the order of tracked activities. A spelling repair and a replacement assessment may require different continuity decisions. Ask the implementation owner which stored state depends on the changed structure. Do not infer compatibility merely because the new package has the same filename or displays a similar opening screen.

Choose an outcome for each enrollment state

Create rows for a person not yet enrolled, an untouched existing registration, an in-progress registration and a completed registration. Add failed or expired cases if they matter to the actual course policy. For each row, specify which version should open next, whether prior progress remains applicable and what historical result must remain identifiable.

These rows express the requested policy, not an instruction to invent per-person controls the platform lacks. Ask the LMS owner which supported configuration can implement it and whether its scope is course-wide. If the desired policy is not supported, expose the tradeoff before launch. A seemingly convenient always-latest setting can have a very different effect on an almost-finished learner than on a new enrollment.

Rehearse old-state and new-package combinations safely

Use synthetic registrations with recognizable progress in the old version. Test the selected transition in an approved environment, then inspect both what opens and what the administrator can still report. A correct new title does not prove that the prior attempt history remains accessible or clearly associated with its original version.

Include a learner returning through an old course link. Check whether the supported workflow reaches the intended version, an explicit restart or a clear unavailable state. If old saved data is incompatible, do not hand-edit it into the new structure. Preserve the distinction between historical completion and a new requirement. A legitimate need to take revised material again should be communicated as that requirement, not disguised as accidental lost progress.

Publish the continuity decision with the release handover

Before an authorized release, prepare the learner explanation and administrator record: what changes, who is affected, whether work restarts and which previous results remain visible. Name an owner for unexpected returning-learner behavior. Avoid promising that a rollback restores every state unless the platform’s actual recovery path has been verified.

Keep the prior package reference, new package reference and tested transition cases together. If a correction is later required, review any new progress already collected before reverting content. This lesson does not authorize a migration or record deletion; it defines the evidence a responsible owner needs to approve one. Acceptance means the version change has an explicit, tested effect on learning continuity rather than an unexamined assumption that new files and old state will fit.

Make the reasoning concrete.

A fictional agency revises a training course from three units to four and changes its assessment. The team plans to overwrite the package while several test learners are midway through the previous structure.

The team records the supported version policy and learner notice before requesting release approval, preserving historical results under their original version.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Change

   Which tracked structure or state assumptions changed?

2. Population

   Which registration states need different continuity decisions?

3. Capability

   Can the platform implement the requested policy at the required scope?

4. History

   Where does the previous version’s result remain identifiable?

5. Recovery

   What happens to progress collected after the change if a correction is needed?

Watch for the wrong conclusion.

• Treating a matching filename as state compatibility.
• Assuming a version move preserves progress in every LMS.
• Reverting content without considering new records already collected.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• SCORM Cloud: Course Versioning and Overwriting →Primary platform documentation · Supports: Supports scoped overwrite/version separation and registration-instance restart consequences; transition decisions and fixtures are editorial.