> For the complete documentation index, see [llms.txt](https://docs.nuvolos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nuvolos.com/tutorials/tutorials-for-instructors/reusing-a-course-for-the-next-term.md).
# Reusing a course for the next term
**What you will achieve.** \
By the end of this tutorial you will have a fresh course for the new term that contains the teaching material from a previous course - but none of last term's student instances, hand-ins, or in-progress edits. You will know which artefacts to carry forward, how to bring them across cleanly, and how to leave the old course archived as an institutional record.
**How long it takes.** \
About 30–45 minutes for the carry-forward itself, plus the time to re-distribute applications and material to the new cohort (which can run for a while in the background).
**What you need before you start.** \
A previous course you have taught at least once on Nuvolos, ideally with the Master instance still in good shape. You should be a Space Administrator on that course. If the previous course has already been archived, that is fine - Section Step 2 covers how to access archived material.
{% hint style="info" %}
**Why not just re-use the old course?**
It is tempting to keep teaching out of the same course year after year. Two things make that a poor choice. First, distribution targets every existing instance, so re-distributing material into last year's cohort wakes up old student instances and creates noise. Second, hand-in storage, audit trails, and grade tables accumulate - by year three, the assignment views are crowded with material from cohorts who graduated. Starting a fresh course every term keeps each cohort self-contained while letting you carry forward exactly what you want.
{% endhint %}
{% stepper %}
{% step %}
### Step 1 - Decide what you actually want to carry forward
Before touching anything, list the artefacts in the old Master instance. Most of them fit one of three buckets:
* Bring forward as-is: lecture notes, starter notebooks, datasets, configured applications, `README` content. These are the assets that took real work to produce and are still good.
* Bring forward and update: assignment files (deadlines and contexts will change), version-pinned dependencies, anything dated. Carry them across, then revise.
* Leave behind: student instances, hand-ins, grades, scratch files, anything generated during a live session that shouldn't outlive the term.
The Master instance is the right source for everything in the first two buckets. Student instances are the right place for nothing in either.
{% endstep %}
{% step %}
### Step 2 - Capture the previous Master instance as a snapshot
[Snapshots](/concepts/distribution.md) are the cleanest carry-forward mechanism. A snapshot of the Master instance freezes its files, configured applications, and state into an immutable record that you can later use as the seed for a new course.
Open the previous course and navigate to the Master instance. From the left sidebar, hover the camera icon and click TAKE SNAPSHOT AND DESCRIBE. Give it a clear name like "end-of-term-2024-spring" so you can find it next term too. Add a description noting what was final and what was still being worked on.
{% hint style="info" %}
**If the previous course is already archived**
Archived courses are read-mostly but you can still create the seed you need. Open the archived space (turn on the Archived toggle in the Space dropdown if you don't see it), navigate to the Master instance, and [restore an existing snapshot](/how-to-guides/common-workflows/snapshots/restore-a-snapshot.md) to the current state. You then have 3 days to take a fresh snapshot and complete this tutorial — see How-to › End-of-course tasks › Archive your course for the grace-period rules.
{% endhint %}
{% hint style="success" %}
**Checkpoint**
You should now see your named snapshot in the snapshot list of the previous course's Master instance. This snapshot is your safety net and your carry-forward source — everything you do next builds on it.
{% endhint %}
{% endstep %}
{% step %}
### Step 3 - Create the new course
[Create the new course](/how-to-guides/workflows-for-instructors/create-a-new-course.md) as you would a fresh course, but pay attention to two specific choices:
* Course name - include the term so cohorts don't blur together ("Statistics 101 — Autumn 2025" not just "Statistics 101").
* Application picker - skip it. You will not pick a fresh application here; you will bring the configured one across from the previous Master instance in the next step.
From the Dashboard, select + NEW COURSE, fill in the name and description, click + ADD SPACE, and skip the application step. You now have an empty new course with an empty Master instance.
{% endstep %}
{% step %}
### Step 4 - Bring teaching material across with cross-space distribution
Distribution normally pushes material from the Master instance of one course to its student instances. Less obvious - and the key to this workflow - is that you can also distribute from the Master of one course into the Master of another. This is how teaching material moves across course boundaries on Nuvolos.
Open the previous course and go to the Master instance. Make sure you are looking at the Current state (or restore the snapshot from Step 2 if you took it earlier and the state has drifted). Then:
1. On the Files screen, select the files and folders you want to bring forward. On the Applications screen, select any configured applications. Stage everything together.
2. Click the share icon on the sidebar to open the Distribution. Review the staged objects and click CONTINUE.
3. Save the staged objects as a named bundle (for example, "course-template-2024"). This makes the same carry-forward repeatable next term - you re-distribute the bundle without re-staging individual files. See [distribution bundles](/how-to-guides/common-workflows/object-distribution.md) for details.
4. On the target screen, change the target from the default ("all students of this course") to the Master instance of the new course. This is the cross-space distribution: the source is the old course's Master, the target is the new course's Master.
5. Choose the [distribution strategy](/reference/configuration/distribution-strategies.md). For a fresh course Overwrite is correct, as there is nothing in the new Master to preserve.
6. Click SHARE OBJECTS. If you brought across applications, distribution may take a while.
{% hint style="success" %}
**Checkpoint**
Open the new course and navigate to its Master instance. Your carried-forward files, folders, and applications should all be present. Start the application - if you bring forward a configured JupyterLab from last term, all your packages and customisations should already be in place.
{% endhint %}
{% endstep %}
{% step %}
### Step 5 - Update what needs updating
This is the part that has to happen by hand. The carried-forward material is correct as of last term, not as of this term. Walk through it and fix:
* Dates and deadlines in the README and in any assignment files.
* Term numbers, room references, lecture-day references.
* Pinned package versions if you want to refresh - or, if you don't, version-pin them more aggressively now to *prevent* updates this term.
* Anything tied to the previous cohort: "Last year's class found this hard" comments, references to specific student questions, etc.
If the course uses the Course Configuration > Student Credit Quotas screen for GPU access, redefine the quota schedule for the new term - old end-dates are now in the past and will not work.
{% endstep %}
{% step %}
### Step 6 - Set up archival on the new course and invite the new cohort
Now treat the new course as you would any new course. Set the Space archival date at the time of creation, or edit it now via the info panel on the course overview, so the new course will archive automatically at the end of this term - same lifecycle, same hygiene. See [How-to › Archiving your course](/how-to-guides/workflows-for-instructors/archiving-your-course.md) for the mechanics.
Then invite the new cohort following [How-to › Invite students](/how-to-guides/workflows-for-instructors/invite-students.md). Each new student gets their own fresh instance, populated automatically from your carried-forward Master via the Distributed instance - the same mechanism that gets material to first-day joiners in any course.
{% endstep %}
{% step %}
### Step 7 - Archive the previous course
If the previous course is not yet archived, archive it now. Set the archival date or wait for the automatic schedule, depending on your institution's record-keeping preferences.
Archived courses keep hand-ins and grade tables intact for institutional reference but free up everyday storage. Students from the old cohort can still restore snapshots to retrieve their work; new students never see the old course at all.
{% hint style="success" %}
**You're done**
You have lifted the teaching material from the previous course into a fresh course, updated what needed updating, set up the new course's lifecycle, invited the new cohort, and archived the previous course. The carry-forward is now repeatable - next term you re-run the same steps, ideally re-using the bundle you saved in Step 4.
{% endhint %}
{% endstep %}
{% endstepper %}
#### Where to go next
* If you want a colleague to take over the course rather than continuing it yourself, the same carry-forward works. See [How-to › Invite teaching assistants and co-instructors](/how-to-guides/workflows-for-instructors/invite-tas.md) to give them the right roles before you hand the bundle over.
* If your course used GPU access last term, double-check the new credit-quota schedule before students arrive. See [How-to › Courses with GPUs](/how-to-guides/workflows-for-instructors/courses-with-gpus.md).
* To turn the carried-forward material into graded assignments for the new cohort, see [How-to › Assignments, grading, and feedback](/how-to-guides/workflows-for-instructors/setting-assignments.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.nuvolos.com/tutorials/tutorials-for-instructors/reusing-a-course-for-the-next-term.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.