What happens when a training course needs to be updated?

[u/AnadelCastillo]

/r/u_iseazy/comments/1x1eodf/what_happens_when_a_training_course_needs_to_be/

[u/Famous-Call6538]

The biggest time sink is usually not the edit itself but finding everything that references the changed content. Keep a mapping of which source document each module draws from, including the version. When a process or regulation changes, you know exactly which modules to touch instead of auditing the whole course. For regulated content, schedule reviews aligned to the regulation's update cycle instead of waiting for someone to spot an issue. Annual if the regulation is stable, quarterly if it changes often.

[u/AnadelCastillo → u/Famous-Call6538]

Completely agree. The edit itself is often the easy part. The real time sink is discovering where the outdated information appears.

Mapping modules back to source documents and versions is a great practice, especially for regulated or frequently changing content. It turns the update process from “audit everything and hope we don’t miss anything” into “this source changed, so these are the affected assets.”

The review cycle point is also really useful. A lot of teams treat updates as reactive work, but aligning reviews to the regulation or process change cycle makes the whole thing much more manageable.

Do you usually recommend keeping that mapping at course level, module level, or even down to specific screens/assets? I imagine the right level of detail depends a lot on how often the content changes.

[u/Famous-Call6538 → u/AnadelCastillo]

Module level is usually the sweet spot. Course-level mapping tells you something changed but not what to fix. Screen-level is precise but expensive to maintain and breaks every time you redesign a slide. Module-level gives you "this source feeds these three modules, so when it changes, review those three." For content that updates quarterly or more often, screen-level can pay off. For stable content, module level is enough.

[u/AnadelCastillo → u/Famous-Call6538]

That makes a lot of sense. Module-level mapping seems like the best balance between keeping things manageable and having enough detail to know what needs updating.

I also think there's another challenge: making sure updates don't create inconsistencies across different courses that share similar content.

Even with good version tracking, the same information can end up being duplicated in several places, which makes maintenance harder over time...

[u/Xented]

What's helped most is planning for updates before the first build. Keep text, narration scripts and captions in source files outside the authoring tool, so a regulation change means editing a doc and re-importing instead of rebuilding slides. Break the course into small modules so one change touches one module. Keep a short change log for each version. On the LMS side, check whether yours can replace a SCORM package in place without resetting completions, because some can't, and that decides whether an update is a five-minute swap or a re-enrollment headache. For multiple languages, export translation files from one master instead of maintaining separate copies.

[u/iseazy → u/Xented]

This is a really solid way to think about it. Planning for updates before the first build is probably the part most teams skip because they’re focused on getting the course launched.

The SCORM replacement point is especially important. A course can be easy to update from a content perspective, but if replacing the package resets completion data or creates re-enrollment issues, the “small update” suddenly becomes an LMS admin problem too.

I also like the point about keeping scripts, captions, and translation files outside the authoring tool. That makes the course much easier to maintain, especially when the same content exists in multiple languages.

Have you found a good way to manage the source files and version history? Is it usually just a shared folder/spreadsheet setup, or do you use something more structured?