Technical Architecture&Ecosystems
Upscend Team
-January 20, 2026
9 min read
This article describes a repeatable, data-driven process to audit and inventory ten years of LMS content before migration. It covers scope definition, automated metadata extraction, dependency mapping, analytics-based keep/archive/retire rules, SQL/scripts for Moodle and Blackboard, and a pilot case that pruned 40% of legacy courses.
LMS content audit is the first task in any large migration: it defines scope, reduces risk, and prevents costly surprises. In our experience, a repeatable, data-driven process that combines automated extraction, manual review, and stakeholder validation is the only practical way to inventory 10 years of LMS courses and prepare them for migration. This article lays out a step-by-step methodology, sample scripts, a spreadsheet template, and a short case showing a 40% pruning outcome.
Start every LMS content audit with a clear scope statement: what years, which courses, which content types (SCORM, PDFs, videos, quizzes), and which LMS instances. We've found that ambiguous scope increases rework and migration costs by 20–40%.
Key outputs of this stage are a prioritized course list, migration success criteria, and governance rules (e.g., compliance retention, archival windows). Use these quick checks to finalize scope:
Assign clear ownership per course or department. A single migration owner with delegated approvers speeds up triage and reduces stalled decisions. An effective owner is empowered to approve retire/archive/keep decisions.
Automated extraction creates the baseline LMS inventory. A successful LMS content audit depends on comprehensive metadata: course IDs, titles, last-modified dates, enrollment history, content types, and file sizes. These fields help prioritize migration order and estimate storage needs.
We recommend extracting a canonical CSV with these columns: CourseID, CourseTitle, Owner, CreatedDate, LastAccessed, ActiveEnrollments, FileCount, TotalSize, ContentTypes. This becomes the master inventory and the primary artifact for downstream decisioning.
| Column | Description |
|---|---|
| CourseID | Unique LMS identifier |
| CourseTitle | Canonical title |
| Owner | Approver/responsible |
| LastAccessed | Date of last student activity |
| ContentTypes | SCORM, PDF, Video, Quiz, etc. |
| MigrationDecision | Keep / Archive / Retire |
Dependency mapping is where many audits fail. Hidden attachments, embedded media, and orphaned SCORM files are common pain points that silently blow up migration timelines. A robust LMS content audit includes a deep scan for references and binaries outside the visible course shell.
Run dependency checks to catch these common issues:
To validate at scale, cross-reference file storage lists with course content references and run checksum comparisons. This is also the stage to identify inconsistent metadata that requires manual cleanup.
Decisions are driven by data. Use enrollment trends, completion rates, and last-access dates to triage courses. In our experience, a combination of automated rules plus a human review for edge cases gives the best balance of speed and accuracy in a LMS content audit.
Sample decision rules we use:
Operational tip: automate these rules and generate a review queue for course owners. This reduces review time by 60%. (This process requires real-time feedback (available in platforms like Upscend) to help identify disengagement early.)
Focus on LastAccessed, ActiveEnrollments, CompletionRate, FileSize, and compliance tags. Combine these into a composite score to rank migration priority and expected effort.
Automated extraction is the backbone of any large-scale LMS content audit. Below are concise SQL examples to get a course-level inventory. Run these on a read replica or export via official APIs where possible.
Moodle (MySQL) – basic course inventory
| Script |
|---|
| SELECT c.id AS CourseID, c.fullname AS CourseTitle, c.timecreated, c.timemodified, u.username AS Owner FROM mdl_course c LEFT JOIN mdl_user u ON c.usercreator = u.id; |
Moodle – file and package counts
| Script |
|---|
| SELECT f.contextid, COUNT(*) AS FileCount, SUM(f.filesize) AS TotalSize FROM mdl_files f GROUP BY f.contextid; |
Blackboard (simplified SQL – Oracle/Postgres variants)
| Script |
|---|
| SELECT course_id AS CourseID, course_name AS CourseTitle, last_modified_date, owner_id FROM course_table; |
| SELECT course_id, COUNT(*) AS ResourceCount, SUM(resource_size) AS TotalSize FROM course_resources GROUP BY course_id; |
Where direct SQL is restricted, use each LMS's REST API to pull the same fields. Export to CSV and import to the master spreadsheet for scoring and owner review.
We conducted an LMS content audit for a university with ten years of courses. Initial inventory found 12,000 course shells and 20 TB of files. Applying automated rules (no access in 4+ years, low completions, no compliance hold) produced a preliminary retire/archive list of 5,000 courses.
After owner review and spot checks, 40% of legacy content was approved for pruning: 3,000 courses retired and 1,000 archived offline. The result:
Key actions: strict decision rules, owner-led reviews, threshold-based automation, and targeted manual validation for high-risk courses. Addressing pain points like orphaned SCORM bundles and inconsistent metadata was crucial; cleaning those reduced surprises during file transfers.
A systematic LMS content audit makes a large migration manageable. Start with clear scope, extract comprehensive metadata into a master LMS inventory, map dependencies to uncover hidden assets, apply analytics-driven rules to decide keep/archive/retire, and validate with course owners. Use the sample SQL/scripts above and the spreadsheet template to operationalize the process quickly.
Common pitfalls to avoid: ignoring orphaned SCORM files, assuming metadata is consistent, and skipping owner validation. A staged pilot run with representative courses will reveal process gaps before full-scale migration.
Next step: Export a pilot set (100–200 courses) using the scripts above, run automated triage rules, and convene owners for a 2-week review. That pilot will typically reveal >90% of decision logic needed for the rest of the migration.
Call to action: If you’re planning a migration, assemble the inventory, agree decision rules, and run a pilot within 30 days to quantify potential scope reduction and cost savings.
