How to keep online courses up to date
Maintaining a software course is not the same as making one. This is the workflow we use: decide the version you teach, map each lesson to a source you trust, check the passages that source affects, and update only what actually breaks the student's path.
TeachCurrent editorial team · Published · 8 min read
A course goes out of date unevenly. One lesson is wrong within weeks because a menu moved; another is still correct after three years because it teaches a concept. Blanket re-recording wastes the time you have, and waiting for student complaints means the damage is already done. What works is a small inventory plus a fixed decision order.
Define the version you teach
Before anything else, write down the version of the software each course was recorded against, and the date. A lesson recorded against an older intended version is not automatically wrong — it may simply be a course about that version. Deciding this up front turns a vague worry (“my course feels old”) into a testable statement (“this course teaches version X as of March”).
Record three things per course:
- The intended version or release the course teaches.
- The recording window, so timestamps can be judged in context.
- Whether you promise students it stays current, and how often you will review it.
Map lessons to reliable sources
A source-to-lesson inventory is the smallest useful artefact in course maintenance. One row per claim that depends on something outside your control.
| Lesson | Claim | Source of truth | Risk |
|---|---|---|---|
| M2 · L04 | Folder layout of a theme | Official theme architecture docs | High — blocks later lessons |
| M3 · L02 | Name of a settings screen | Product UI documentation | Medium — confusing, not blocking |
| M5 · L01 | Why templates are separated | Concept — no external source | Low |
The third row matters as much as the first two: marking conceptual lessons as sourceless stops you re-reviewing material that cannot go stale.
Separate a changed page from changed behaviour
This is where most maintenance goes wrong. Documentation gets rewritten, reorganised and renamed constantly without the software changing at all. Treat a source difference as a question, not a verdict:
- The wording changed, the behaviour did not — no lesson edit.
- The behaviour changed but your approach still works — add a note about the version.
- The behaviour changed and your steps now fail — the lesson needs an edit.
Wherever possible, confirm category three by running the steps yourself once. One reproduction is worth ten changelog readings.
Prioritise what students cannot complete
Rank findings by what they do to the learner, in this order:
- Blocking — a step cannot be completed, so the rest of the module stalls.
- Misleading — the step works but teaches an approach that is now discouraged.
- Cosmetic — a label or screen name differs; students adapt without help.
Blocking items get fixed now, ideally with a pinned lesson note within a day and a proper edit later. Cosmetic items get batched into the next scheduled pass.
An edit that only clarifies documentation
Not every fix is a re-record. Say a lesson tells students to open a panel that is now reached from a different menu. The cheapest correct fix is a dated on-screen note and an updated lesson description: “Recorded against version X. Since version Y this panel moved to Settings → Appearance; the steps that follow are unchanged.” The video stays, the student is unblocked, and your update log shows exactly what was decided.
Update and record the decision
Every finding ends in one of three recorded states: updated, kept with a reason, or retired. The reason is the valuable part — six months later it stops you re-litigating a decision you already made, and it tells a collaborator why a lesson that looks wrong is intentional.