The LMS migration checklist we use (and what vendor guides skip)

An LMS migration checklist should cover five things, in order. Secure exit terms and export formats in your current contract. Inventory your content, users and learning history. Retest every SCORM, xAPI and cmi5 package on the new platform. Archive completion and certificate records in a form you can hand an auditor. Then plan the cutover for SSO, SCIM and old URLs.

In LMS Advisor, the content side starts with importing your Moodle .mbz backups or LearnDash courses, your original SCORM, xAPI and cmi5 zips go back in for retesting, and SAML SSO and SCIM handle the identity cutover. Completion history is the part you archive yourself, and this checklist shows how.

The migrations we get called in to rescue usually skipped the history and the retesting, and so do most vendor guides. Docebo's LMS migration guide (updated January 9, 2026) has six steps and admits some content won't make the transition, but it doesn't cover retesting packages or keeping transcripts. 360Learning's migration guide (updated June 17, 2026) calls the process "simple and easy" thanks to its mass import. Copying files is the easy part. Proving two years from now that a nurse completed bloodborne pathogens training in March 2026 is the hard part. Our checklist is built around that problem, after years of moving teams off Moodle, LearnDash and SaaS platforms.

What does an LMS migration actually move, and what can't it?

A migration moves content, people, structure (groups, departments, enrollments) and history. The first three transfer with some rework. History is where the losses happen, because every LMS stores progress, attempts and logs in its own schema, and importers are built to move courses, not records.

A Moodle .mbz course backup, according to the MoodleDocs course backup page, can optionally include role assignments, groups, user files, user completion details, course logs and grade history. A file ending in -nu.mbz has no users and -an.mbz is anonymized: fine for content, useless for history. The Moodle backup and restore FAQ adds that logs are off by default, passwords are never backed up, and quiz questions come along only if their category is used in a quiz. Check which options were ticked before you trust a backup.

LearnDash has a built-in import/export tool that covers courses, lessons, topics, quizzes, questions, groups, assignments, certificates and users. The LearnDash transfer documentation (updated July 2, 2026) also notes that it can't export a single course by default, and that LearnDash support gives only limited help with transfers. In practice it's a LearnDash-to-LearnDash tool. Don't count on another LMS reading its export file.

What should you check in the contract before you sign or renew?

The cheapest time to secure your data is before signing, when the vendor still wants your business. The next best is 90 days before renewal. Check both contracts for these points:

• Export formats. Completions, scores and dates per learner as CSV, certificates as PDFs with their IDs, xAPI statements through the LRS API. "Your data is yours" without a format is not an answer.
• Who runs the export and what it costs. Some vendors bill a full data extract as professional services. Get the price in writing.
• Access after termination. How long do you keep admin access after the contract ends, and when is the data deleted? Push for a read-only window of 60 to 90 days.
• Original content files. Keep your own copy of every SCORM zip and authoring source file. A package pulled back out of an LMS may not be the one you uploaded.
• API limits. If you plan to pull history through an API, find out the rate limits now, not during cutover week.

Timing matters for self-hosted platforms too. As of September 2026, the Moodle releases page lists October 5, 2026 as the end of security support for Moodle 5.0, and October 4, 2027 for Moodle 4.5 LTS. If you're on either one, an upgrade-or-migrate decision is coming. If you're also deciding where the new platform should run, see our post on self-hosted vs cloud LMS deployment.

How do you inventory content, users and history?

Build a spreadsheet from the old system's reports, one row per item and a decision column.

1. Courses. Export every course with its last enrollment date, completion count and owner, then mark it keep, rebuild or retire. Be ruthless: every retired course is one less thing to test.
2. Content types. Count SCORM 1.2, SCORM 2004, xAPI, cmi5, video, documents and plugin activities. Plugin activities are the ones that turn into rebuild work.
3. Users. Split active from inactive and decide what identifies a person: email, employee ID or username. Pick one key and check it's unique in both systems.
4. Structure. Record departments, groups, managers and any external audiences (contractors, customers, franchisees) that need separate spaces.
5. History with a retention rule. For each course, note whether a law, regulator or customer contract requires you to keep the record. OSHA's bloodborne pathogens standard, for example, requires training records kept for 3 years from the date of training, with dates, a content summary, trainer names and qualifications, and attendee names and job titles. Those are exports you can't skip. State OSHA plans and other regulators can differ, so confirm the current rule for each record type with your compliance owner.
6. Integrations. List everything that talks to the LMS: HRIS feeds, SSO, webhooks, reporting tools, e-commerce, LTI links.

How do you move SCORM, xAPI and cmi5 packages without breaking tracking?

Upload the original packages, then test them as a learner would. A package that uploads cleanly can still report the wrong status, because every LMS implements the SCORM runtime a little differently.

Test one course per authoring template, not every course:

• Launch on desktop and on a phone.
• Leave halfway, come back, and confirm it resumes on the right screen.
• Fail the quiz, then pass it, and check the status and score the LMS records each time.
• Confirm the completion rule matches the old one. A course that used to complete on quiz pass and now completes on slides viewed quietly inflates your compliance numbers.
• Find the result in the report your managers actually use.

When a result looks wrong, run the same zip in Rustici's free SCORM Cloud testing, which plays SCORM, xAPI and cmi5 packages. If the package misbehaves there too, fix the publish settings, not the LMS.

Flag three things for extra attention. Multi-SCO SCORM 2004 packages rely on sequencing support, which varies by platform. Long SCORM 1.2 courses can outgrow their resume-data limit. And xAPI statements need an actor the new LMS can match to a user, or the data can't be joined to a learner record. Our guide to SCORM vs xAPI vs cmi5 covers each of these failures.

Two things importers won't tell you. In-progress attempts don't move, so learners halfway through a course start over. Set a deadline to finish in the old system or warn people up front. And xAPI statements sitting in the old LRS stay there unless you export them. The xAPI communication spec returns statements in pages, with a link to the next batch when more results exist, so budget time for a script that walks every page.

How do you keep completion, grade and certificate history for audits?

There are three realistic options, and many teams combine them.

Whichever you choose, pull these exports before the old contract ends:

• Per-learner completions with course name, course version, completion date, score and status, as CSV.
• Quiz and exam attempt data for anything high-stakes, including dates and scores per attempt.
• Every issued certificate as a PDF, plus a CSV of certificate IDs, learner, issue date and expiry date.
• Grade history and logs for courses with a retention rule.
• The course content itself, so you can show what learners were taught.

Certificates need their own plan. If your old platform printed a verification URL or QR code on each certificate, those links break when the old system goes away. Keep a lookup table for credentials already in circulation. For recurring training, carry each person's current expiry date into the new LMS. Otherwise people show as overdue on day one or drop out of the renewal cycle.

How should you handle SSO, SCIM and the cutover weekend?

Identity is where cutover weekends go sideways, so prove the account model in a test environment first.

• Match on a stable identifier. Your SAML assertion should send the same identifier you used as the user key in the import. If the old LMS keyed on username and the new one on email, fix that mapping before go-live, not after hundreds of duplicate accounts appear.
• Plan for passwords. Password hashes rarely move between platforms. Without SSO, schedule a reset email and brief the help desk.
• Stage SCIM carefully. Turn on provisioning to the new LMS, confirm a small group syncs correctly, then assign everyone. In Okta, for example, deprovisioning a user sets active=false in the SCIM app. Decide whether the old LMS keeps receiving those updates during parallel running.
• Silence automations during import. Enrollment emails, welcome messages and overdue reminders will fire for every imported record unless you pause them.
• Freeze changes. Stop content edits and new enrollments in the old system from a set date, so the final export matches what you tested.

A cutover weekend should be boring. If you're still mapping fields on Saturday, the date was too early.

How do redirects, parallel running and a pilot group fit together?

Old LMS links hide in intranet pages, onboarding emails, Slack bookmarks, help articles and QR codes on break-room posters. Map each course, the login page and any certificate verification page to its new address. Google's site move guidance recommends permanent server-side redirects (301 or 308) and keeping them for at least a year. That matters most for public catalogs and customer academies.

Run a pilot before full launch with one internal department and, if you have one, one external audience. Give it two to three weeks, log every ticket, and set a clear exit test: packages track correctly, managers can find their reports, and SSO works on every device type in use.

Then run both systems in parallel, with the old one closed to new enrollments and a fixed end date. Parallel running without a deadline means two LMS bills and two sets of records that disagree.

The printable LMS migration checklist

Before you sign

1. Confirm export formats for completions, certificates, attempts and xAPI statements.
2. Get post-termination access and deletion terms in writing.
3. Collect original SCORM zips and authoring source files.
4. Check API rate limits on the old platform.

Inventory and plan

1. List every course with owner, last enrollment and a keep, rebuild or retire decision.
2. Count content by type and flag plugin activities for rebuild.
3. Choose one unique user identifier and clean duplicates.
4. Map groups, departments, managers and external audiences.
5. Mark courses with a legal or contractual retention rule.
6. List every integration and who owns it.

Build and test

1. Retest one course per authoring template: launch, resume, fail, pass, report.
2. Flag multi-SCO SCORM 2004 packages and long SCORM 1.2 courses.
3. Check xAPI actor matching and cmi5 moveOn rules.
4. Set up SSO and SCIM in a test environment with real accounts.

Preserve history

1. Export completions, attempts, certificates, grade history and required logs.
2. Export xAPI statements from the old LRS.
3. Store the archive with an index, an owner and a retention period.
4. Carry current certificate expiry dates into the new LMS.

Cut over

1. Freeze content and enrollments in the old system.
2. Pause automated emails, import users and enrollments, then re-enable.
3. Put 301 redirects in place for courses, login and certificate verification URLs.
4. Run the pilot, then parallel running with a fixed end date.
5. Confirm every export opens before the old contract ends.

How to run this checklist in LMS Advisor

Our team spent years doing these migrations by hand before building LMS Advisor, which is why it imports from Moodle and LearnDash directly. Here is how each phase of the checklist maps to the platform, including the one it won't do for you.

Our comparisons with Moodle and LearnDash spell out what carries across, the e-learning standards page covers package support, and the security and data ownership page explains cloud and self-hosted options. To see your own packages run before you commit, book a demo and bring a few zip files.

Frequently asked questions

What should be on an LMS migration checklist?

It should cover exit terms and export formats, a full inventory, a package retest plan, a history archive and a cutover plan for SSO, SCIM and redirects. Teams miss the archive most often, and without it, proof of past training disappears with the old contract.

Can LMS Advisor import courses from Moodle or LearnDash?

Yes. LMS Advisor imports Moodle .mbz course backups and LearnDash courses, and you upload your original SCORM, xAPI and cmi5 packages alongside them. It does not import historical completions, logs or grade history, so export and archive those from the old platform before the contract ends. Retest one course per authoring template after import.

Can you move completion records to a new LMS?

Sometimes, but usually as summary records rather than full history. Many platforms can import a completion with a date, and far fewer can import scores, attempts and logs. Either way, export the full records as CSV and PDF before the old contract ends.

Do SCORM courses need to be retested after switching LMS platforms?

Yes. Each LMS implements the SCORM runtime slightly differently, so status, score and resume behavior can change even when the upload succeeds. Test one course per authoring template rather than every course, and use a neutral player such as SCORM Cloud to tell package problems from platform problems.

How long does an LMS migration take?

Plan in months, not weeks. The timeline depends less on headcount than on the number of distinct content templates, integrations and records you must preserve. A migration with SSO, SCIM and a few hundred courses needs time for package testing, a pilot of two to three weeks and a parallel-running period.

What gets lost when you switch LMS platforms?

Usually in-progress attempts, activity logs, plugin-based activities, passwords and certificate verification links. Grade history and xAPI statements go too, unless you export them before the old system shuts down.