10 Steps for Migrating Courses Between LMS Providers Efficiently

Moving courses between LMS providers can feel like you’re trying to pack your whole house into one suitcase. You’ve got content, quizzes, assignments, attachments, user progress, certificates, permissions… the list goes on. In my experience, it only feels chaotic when you skip the planning and start “moving stuff” before you understand what the old system is storing and what the new system actually expects.

This guide is for teams migrating from one full LMS to another (not just swapping templates). I’m talking about real migrations like Moodle → Canvas, Blackboard → Canvas, or Docebo → TalentLMS—the kind where you’re exporting/importing course content and syncing learning records. If you’re migrating 20 courses or 200, the workflow is the same; the difference is how careful you have to be with testing and cutover.

I’ll walk you through a process I’ve used on migrations that involved SCORM packages, quiz questions, and gradebook-style reporting. The goal is simple: you should end up with a new LMS that learners can actually use on day one—without missing files, broken links, or progress that mysteriously resets.

Step 1: Set Clear Migration Goals and Identify Needs

Before you touch exports, imports, or migration tools, you need to know what “success” looks like. Not vibes—specific outcomes.

Here are the questions I start with:

• Why are we switching? Better UX, missing features, cost, reporting gaps, or vendor risk?
• What do we refuse to lose? Completion history, certifications, quiz attempts, gradebook reporting, course structure?
• What’s broken today? If your current LMS can’t track course progress properly, that’s a goal—fix it.

Then I turn that into goals you can measure. For example:

• Reduce course update turnaround time from 10 business days to 5
• Cut “can’t find resources” support tickets by 60–80% after go-live
• Maintain ≥ 98% of SCORM package link integrity (no missing assets)
• Keep learning records accurate within ± 1% variance for completion rates

Finally, I break needs into the buckets the migration will actually touch: content, learning data, reporting, integrations, and user management. This is the foundation for every mapping rule you’ll create later.

Step 2: Audit Your Existing Content and Data

In this step, I’m not just counting courses. I’m figuring out what kinds of content and data you actually have, because that determines how messy the conversion will be.

Audit your course assets like this:

• Content types: courses/modules, videos, PDFs, SCORM packages, xAPI statements, quizzes, surveys, assignments, rubrics
• Dependencies: images, document storage paths, external links, LTI tools, embedded media
• Standards: confirm whether your current LMS supports SCORM 1.2/2004 or xAPI (and what the new LMS supports)

Then audit learning data:

• Users and roles (instructor, learner, manager)
• Progress/completion records
• Attempts and scores (especially for quizzes)
• Certificates issued (and whether they’re generated dynamically or stored)

One thing I learned the hard way: migrating “everything” is how you end up with broken links and wrong permissions. Instead, create a mapping-ready inventory using a spreadsheet or export script output (CSV/JSON works). Track:

• Old LMS identifier (course_id, module_id, quiz_id)
• Human-readable name
• Content format (SCORM/xAPI/HTML/PDF, etc.)
• Where assets live (paths/URLs)
• Whether conversion is needed

And yes—use actual tools here. In real projects, I’ve used export scripts + spreadsheet mapping sheets, then verified file integrity using checksums (MD5/SHA-256) on exported packages so you’re not importing corrupted assets.

Create a Course Catalog for Migration

Once you know what you have, you need a catalog you can execute. This is where migrations get real.

For each course, I recommend capturing:

• Course title and course code
• Status: Active / Archive / Needs Update / Don’t Migrate
• Priority level: High (must go-live), Medium, Low
• Content formats: SCORM, quizzes, HTML modules, attachments count
• Conversion notes: SCORM package version changes, xAPI statement mapping, re-authoring requirements
• Owner: who signs off that the migrated version is correct

Also, tag courses with the “gotchas” you know you’ll face. For example:

• Courses with embedded external links (these often break when URLs change)
• Courses with custom themes or templates (may not carry over)
• Courses with complex quiz question pools (often need re-validation)

What I like about a well-built catalog is that it becomes your migration queue. You can sort by priority, estimate work, and avoid the classic problem: “We migrated everything, but the top 10 courses weren’t tested.”

Step 3: Define Your Data Mapping and Conversion Rules

This is the step that saves you later. If you don’t define mapping rules up front, you’ll spend go-live week guessing what “completion” means in the new LMS.

I recommend building a mapping sheet with columns like:

• Old field (example: course_id, user_email, cert_template_id)
• New field (example: course_code, email, certificate_id)
• Transform rule (example: normalize emails to lowercase; map status codes; convert timestamps to UTC)
• Validation check (example: record counts match; checksum match; referential integrity)
• Fallback behavior (example: if cert_template_id missing, mark certificate as “not issued”)

Conversion rules matter most for these areas:

• SCORM/xAPI: confirm how the new LMS interprets tracking events and completion thresholds
• Quiz questions: question types, scoring logic, and feedback rules
• Permissions/roles: who can view, edit, grade, and publish
• Links and assets: rewrite URLs so attachments resolve correctly

Here’s a failure mode I’ve seen: the import “succeeds,” but completion never triggers because the completion rule differs (for example, one LMS requires passing score, the other uses “viewed”). So define an if/then rule now:

• If the new LMS completion logic differs, then you must adjust course settings or re-author SCORM packages to match the expected completion behavior.
• If a course contains unsupported content types, then you either convert (HTML repackage, SCORM rebuild) or mark it “Needs Update” in your catalog.

Step 4: Build a Migration Team and Workflow

You don’t need 20 people, but you do need the right roles. In my experience, the teams that move fastest are the ones with clear ownership.

At minimum, plan for:

• Migration lead (owns timeline, sign-offs, risk log)
• Data/technical owner (exports, imports, mapping, validation checks)
• Instructional content owner (course structure, quiz logic, learning objectives alignment)
• Admin/permissions owner (roles, groups, access model)
• QA tester(s) (test cases, evidence capture, bug triage)
• Privacy/compliance contact (PII handling, retention rules)

Workflow-wise, I suggest a simple ticketing structure:

• Every course migration gets a ticket with status: Not Started → In Progress → QA → Approved
• Every validation issue gets a “bug” ticket with screenshot/log attachments
• Every sign-off includes evidence (test run notes, sample learner outcomes)

One practical tip: don’t let the content owner discover broken quizzes during final QA. Build a quick checkpoint after each import batch so issues get fixed while the context is still fresh.

Step 5: Back Up Everything and Prepare a Rollback Plan

Backups aren’t optional. And rollback planning isn’t either.

Before you migrate anything meaningful, make sure you can do at least:

• Full backups of course content packages and configuration exports (where supported)
• Database exports for key learning records (or equivalent admin exports)
• Asset backups (SCORM zip files, media files, attachments)

Then define rollback triggers. For example:

• If completion rates drop by more than 5% for a migrated course cohort, then pause further imports and rollback the affected batch to the previous state.
• If quiz scoring mismatch is detected in QA, then stop go-live and fix scoring logic before continuing.

I also like to keep a “known good” snapshot of the new LMS test environment after each major batch so you’re not chasing moving targets.

Step 6: Set Up Environments and Access Control

Create separate environments for development/testing and production. If you can’t, at least isolate learner-facing access during early testing.

In practice, I set up:

• Old LMS: export-only access for migration scripts
• New LMS test environment: import sandbox + QA accounts
• Production new LMS: restricted admin access until cutover

Also double-check access control. The fastest way to create “mystery bugs” is to accidentally test with admin permissions that learners won’t have.

Finally, confirm authentication and identity mapping:

• How users are identified (email vs username vs external_id)
• Whether SSO/SSO mapping is ready
• What happens to users who exist in one system but not the other

Step 7: Execute Content and Data Migration in Phases

Don’t try to migrate everything in one giant wave. You’ll regret it.

I recommend phased migration that mirrors real risk:

• Phase 1 (low risk): course shells, modules, static content (PDFs, videos, HTML pages)
• Phase 2 (medium risk): quizzes, assignments, gradebook mapping
• Phase 3 (high risk): SCORM/xAPI tracking, completion logic, certificates, learning record history

For each phase, define a “done” checklist. Example:

• Course imports completed without errors
• All attachments resolve (spot-check 10–20 links per course)
• Quiz question types import correctly
• SCORM tracking events produce expected completion state for a test learner

When you do this in phases, you can fix issues before they multiply across hundreds of courses.

Step 8: Test With Realistic Test Cases

Testing is where migrations either feel smooth… or fall apart.

Don’t just test “a user can log in.” Test how learners actually behave.

I run test cases like:

• Happy path: start course → complete module → take quiz → get completion
• Partial completion: stop mid-course, come back, verify progress state persists
• Retakes: quiz retake allowed → verify best score rules (if applicable)
• Certificate issuance: complete requirements → confirm certificate appears and has correct metadata
• Permissions: learner can view, instructor can grade, admin can manage—no more, no less

For evidence, capture:

• Test learner IDs (old and new)
• Course IDs and timestamps
• Screenshots/log exports for any mismatch

And here’s a rule I stick to: If completion and certification logic differs between LMSs, then you can’t declare victory until you’ve proven it with at least 3–5 migrated courses across different content types.

Step 9: Prepare Cutover Timeline and Change Freeze

Cutover is where timelines get tight and mistakes happen. Plan it like a launch.

What I include in my cutover plan:

• Cutover date and time window (including time zone)
• Change freeze window (example: no course edits 48 hours before final import)
• Final data sync schedule (what gets updated and when)
• Communication plan (what users see and when)
• Support coverage (who’s on call and what hours)

Also, decide what happens to in-flight learning during cutover:

• If a learner starts a course just before cutover, then will their progress carry over, or will you treat it as a fresh start?
• If certificates are generated during the migration window, then how will you prevent duplicates?

These decisions should be written down. If they’re not, you’ll make them under pressure—and that’s when people get angry.

Step 10: Validate Post-GoLive and Fix Issues Fast

After go-live, I treat the first week like a “stabilization sprint.” The goal isn’t perfection—it’s fast detection and quick fixes.

Validate these immediately:

• Login works for all user groups (including SSO users if applicable)
• Course access matches the old permission model
• SCORM/xAPI tracking is producing expected completion states
• Certificates are generated correctly (or not generated if that’s your chosen policy)
• Search works (or at least course discovery doesn’t feel broken)

Then monitor support signals:

• New support ticket volume related to migrated courses
• Top error messages (quiz scoring errors, missing attachments, tracking failures)
• User drop-off points (where learners abandon)

If something breaks, fix it fast—but don’t silently patch without tracking. Put every fix into a changelog so you know what changed and why.

Step 11: Manage Data Privacy and Compliance

Moving data between LMS platforms isn’t just technical work—it’s privacy work too. And it’s where teams get sloppy when they’re rushing.

Make sure you understand the rules that apply to your organization (GDPR, FERPA, CCPA/CPRA, and any internal policies). Then audit the data you’re moving. Don’t assume “it’s just learning progress.” Progress exports often include identifiers and sometimes more than you expect.

In my projects, I’ve seen teams accidentally export fields like:

• Direct identifiers (email, name, employee/student ID)
• PII embedded in custom fields
• Free-text fields (which can contain personal data)

Use secure transfer methods—encrypted backups, secure file transfer, and restricted access to migration environments. And after migration, update your privacy documentation so it reflects the new data handling flow.

One practical check: confirm retention rules. If the old LMS stored data longer than you want, then decide what gets retained in the new LMS and what gets deleted or anonymized.

Compliance isn’t something you tack on at the end. It’s part of the migration plan from day one.

Step 12: Prepare Your Users for the Transition

No matter how clean your migration is, learners will still feel the change. So don’t leave them guessing.

I like to schedule announcements in phases:

• Announcement 1 (2–3 weeks before): why you’re switching, what improves, and what users need to know
• Announcement 2 (1 week before): when the new LMS goes live, what will look different
• Go-live message (day-of): how to access courses, where to find help

Then provide quick, practical help:

• Short walkthrough videos (login + course navigation + starting a lesson)
• FAQs focused on migrated-course issues (progress, certificates, retakes)
• Support channels with clear response times

Also, run a pilot with a small group if you can. In my experience, a pilot catches the “we forgot to map X” issues before the whole organization sees them. Pick a mix of learners: new users, active learners, and users with certificates in progress.

Step 13: Document the Migration Process for Future Reference

If you want the next migration to go faster, document this one. Otherwise, you’ll end up rediscovering the same problems.

I document:

• Migration scope (which courses, which content types, which learning records)
• Tools and versions used (export/import methods, scripts, mapping sheets)
• Field mapping decisions and transform rules
• Test cases run and results (including the “we expected X but got Y” notes)
• Issues found, root causes, and fixes
• Cutover timeline and what was changed during stabilization

Even better: keep a “known issues” list for the first 30 days after go-live. That way, support teams aren’t improvising answers.

It’s not just admin work. Good documentation is what turns migration into a repeatable process instead of a one-off fire drill.

Step 14: Plan for Ongoing Maintenance and Updates

Once the new LMS is live, you still have maintenance. Content updates, security patches, and backups aren’t optional just because the migration is “done.”

Plan a schedule that includes:

• Backups (and testing that restores work)
• Content audits (broken links, outdated attachments, quiz validity)
• Admin training (so instructors and admins know how to work inside the new workflows)
• Review of user feedback (especially for migrated courses)

Also keep an eye on standards and new features. If your LMS adds improved SCORM/xAPI tracking or better reporting, you’ll want to revisit configuration—not ignore it.

Step 15: Evaluate the Success of Your LMS Migration

After go-live, don’t just “check if it works.” Compare it to your baseline and your goals.

Here are KPIs I actually track (and how):

• Completion rate change = (Post-migration completion % − Pre-migration completion %) / Pre-migration completion % × 100. Target: within ± 1–3% for comparable course cohorts.
• Time-to-first-lesson = median time from account activation (or enrollment) to first lesson start. Target: no increase, ideally a decrease.
• Support ticket volume = number of tickets tagged to migrated courses per week. Target: drop after week 1–2; if it stays high, you’ve got a systemic mapping issue.
• Certificate accuracy = (Correct certificates issued / Total certificates expected) × 100. Target: ≥ 99% for courses that rely on compliance.
• Engagement = active learners per week / total enrolled learners. Target: stable or improving for priority courses.

Collect feedback from learners and instructors too. I like short surveys with 3–5 questions: navigation clarity, quiz experience, progress visibility, and whether they know where to get help.

Then compare results to your original goals. If something misses, don’t just blame the migration—identify what failed (content conversion, permissions, tracking logic) and fix it with a targeted plan.

Sources

For more detailed guidance on managing LMS transition projects, check out Create AI Course or explore effective lesson preparation strategies.
Understanding course writing and planning can makes your migration even smoother, so consider reviewing resources like lesson writing tips or creating effective teaching strategies.

For market context and adoption trends, you can also reference industry research on LMS spending and replacement cycles, such as:

• Grand View Research – Learning Management System (LMS) Market Size (accessed 2026-04-13)
• Gartner newsroom resources (research varies by report; access may require subscription)

On replacement timing specifically, you’ll want to validate any “% of organizations replacing within a year” claim using a source that matches your region and organization type (higher ed vs enterprise vs workforce training). I recommend pulling the exact stat you want from the report you’re citing, then referencing the publication date in your internal planning doc.

FAQs