How to Back Up Your Own Skool Community Before Moving

Treat the backup like a migration, not a download spree

If you own or administer the community, you have a cleaner reason to preserve the material than a member trying to copy somebody else’s course. You may still share ownership with instructors, guests, contractors, or clients, so start by confirming which assets you control and which ones have separate license terms.

A useful backup has three qualities:

1. Complete enough for the purpose of the move.
2. Organized enough that another person can understand it.
3. Verified enough that you know the files work before the old access disappears.

Downloading every visible video into one folder achieves none of those by itself.

Define what “backup” means for this move

Write one sentence describing the outcome before touching the classroom. For example:

We need a local working copy of the videos we produced, arranged in current module order, so the team can rebuild the course on the new platform.

That statement excludes several things a video downloader does not own:

• member comments and discussions;
• completion records and leaderboard data;
• platform configuration;
• payments and subscription history;
• third-party tools embedded in a lesson;
• text, worksheets, and links unless you save them separately.

The narrower definition prevents a false sense of security. A folder of MP4 files is a video archive, not a complete backup of a community business.

Establish ownership and permission

Create a short rights column in the inventory. A simple label is enough:

Pay attention to guest workshops, licensed music, stock footage, client examples, and recordings where a speaker approved streaming but not redistribution. Moving your own course does not automatically expand those agreements.

For the broader permission framework, use the local responsible-use guide.

Inventory the classroom before saving files

Work module by module and record:

• module number and title;
• lesson number and title;
• item type: video, text, link, worksheet, or event;
• video provider when visible;
• approximate runtime;
• ownership label;
• backup status;
• verification status;
• notes about replacements or missing sources.

A spreadsheet is useful, but a plain CSV or Markdown table is enough. The inventory is the control document. If the migration is interrupted, it tells the next person exactly where to resume.

Skool classrooms may use multiple external video providers. Skool’s own help material currently documents YouTube, Vimeo, Wistia, and Loom as classroom hosting partners, so two adjacent lessons can require different checks even when they look similar in the course interface. See Skool’s current video troubleshooting guidance and our provider explainer.

Test representative lessons first

Do not start with the entire library. Choose a small test set:

1. one short Skool-hosted lesson;
2. one Loom or Vimeo embed;
3. one lesson with detailed slides or screen text;
4. one long replay;
5. one item you expect to exclude.

For each included video, open the exact lesson, press play, let the provider load, and use the Skool Course Downloader workflow. Then verify the resulting MP4.

The test should answer:

• Does activation work for the migration operator?
• Are the providers detected correctly?
• Is 720p sufficient, or does the course need 1080p for small text?
• How long do large files take on the current connection?
• Where will completed files be stored?
• Can the replacement platform accept the resulting files?

Fix those decisions before scaling up.

Create the destination structure in advance

Mirror the current teaching order with leading numbers:

course-name/
  00-migration-notes/
  01-start-here/
  02-foundations/
  03-implementation/
  04-review/
  community-replays/
  needs-review/

Inside a module, use a predictable pattern:

01-welcome-and-outcomes.mp4
02-account-setup.mp4
03-first-workflow.mp4

Keep replays separate unless they are formally part of a module. Name them by date so chronology survives:

2026-07-14-weekly-office-hours.mp4

The course file-naming system includes a fuller manifest template.

Run the backup in controlled batches

Skool Bulk Downloader runs one recoverable course job at a time and processes selected lessons in order. Use module-sized batches when that makes verification easier.

A reliable batch looks like this:

1. Add two or three clearly identified lessons.
2. Wait for a completion before adding the next item.
3. Move the finished file into its module folder.
4. Mark it downloaded in the inventory.
5. Open and verify it before marking it complete.

Avoid opening a wall of nearly identical tabs. It makes titles, providers, and status harder to match and increases the chance that a valid file ends up under the wrong lesson name.

Verify content, not just file existence

A non-zero file size does not prove the archive is usable. For every completed video:

• open it in a normal local player;
• check the first minute;
• seek to the middle;
• check the final minute;
• confirm both picture and audio;
• compare duration with the lesson;
• confirm slides and interface text remain readable;
• update the inventory from “downloaded” to “verified.”

Move questionable files to needs-review rather than leaving them among complete lessons.

Keep two copies before cancelling anything

Do not remove the old platform or source copy immediately after the first successful pass. Keep:

• the working archive on your main drive; and
• a second copy on a separate drive or approved storage system.

Open a sample from the second copy. A backup that has never been restored or opened is only an assumption.

Finish with a migration record

Store these items in 00-migration-notes:

• the final inventory;
• the date of the backup;
• who performed and verified it;
• excluded items and why;
• unresolved permission questions;
• source-provider notes;
• the replacement-platform upload status;
• a note describing where the second copy lives.

That small record turns a folder of media into a defensible migration artifact. It also gives the team a clean checklist when rebuilding the course.

Final creator checklist

• The intended backup scope is written down.
• Ownership or license status is recorded for every included video.
• Every module and lesson appears in the inventory.
• Representative providers and video lengths were tested first.
• Storage space was estimated before the full run.
• Folder and filename rules were chosen in advance.
• Every completed MP4 was opened and checked.
• Excluded and failed items are documented.
• A second copy was created and sampled.
• The old platform remains available until the migration is confirmed.

If you are ready to run the video portion, start with the practical Skool Course Downloader guide and keep the inventory beside you.

Expand

Close

Last substantively reviewed August 2, 2026. See our editorial and corrections policy.