How to Migrate to a New LMS Without Losing Training Records

Leaving an LMS feels a lot like moving house. The new place looks great, the old one has years of stuff in the closets, and the move date is already on the calendar. In an LMS migration, though, the stuff in the closets includes compliance records an auditor may ask for, certificates with expiration dates and completion history for every employee you've ever trained. Lose a box and you may not notice until it matters. How do you run an LMS migration without losing training records?

A safe LMS migration starts with a full inventory and export of your existing records, long before anyone configures the new platform. List every type of data you hold, decide what must move, what should be archived and what can go, then map users, courses and certificates from the old system's IDs to the new one's. Load historical completions as records rather than trying to re-launch old courses, and plan separately for learners who are mid-course at cutover. Finally, prove the move worked by reconciling record counts and spot-checking real learners before you switch off the old system. Keep a complete archive export no matter what.

What Training Records Do You Need to Keep?

Keep anything someone might reasonably need to prove later: who was trained, on what, when, with what result and against which version of the requirement. Start by listing every kind of data your current LMS holds. Most platforms store more than people realize.

• User accounts with unique IDs, including inactive and former employees
• Completion history with dates, scores and pass or fail status
• Certificates, certifications and expiration or renewal dates
• Current assignments, due dates and overdue status
• Instructor-led attendance, sign-in sheets and instructor notes
• External training records that were entered manually
• Detailed course data such as quiz responses and xAPI statements
• Audit logs showing who changed records and when

Then check your retention rules. Regulated industries and government programs often must keep training records for set periods. Your legal, compliance or HR team should confirm the rules before anyone decides that old records "don't need to move."

How Do You Plan an LMS Migration?

Plan it in phases, with the data work starting first. Configuration of the new platform can run in parallel, but it shouldn't get ahead of the data.

Give the cleanup phase real time. Every duplicate account, retired course or messy department name you fix now is one less problem copied into a brand-new system.

Who Owns Which Part of the Migration?

An LMS migration touches more teams than a typical training project, so name an owner for each workstream before the first export. When everyone assumes someone else is checking the certificates, nobody is.

• Training or L&D: course inventory, course mapping, re-testing content and deciding what retires
• LMS administrators: exports, imports, configuration and the reconciliation itself
• HR or HRIS: user data, employee IDs, departments and the ongoing user feed
• IT: single sign-on, links from the intranet and decommissioning the old system
• Compliance or legal: retention rules, audit requirements and sign-off on the archive
• Communications: learner and manager announcements, especially about in-progress courses

A weekly 30-minute check-in with those owners catches most problems while they're still small. Keep a single shared issue log, and don't close an issue until the person who raised it agrees it's fixed.

How Do You Move Historical Completions?

Move historical completions as data, not as course activity. The new LMS doesn't need to "know" that someone took a course in the old system by replaying it. It needs a record saying this person completed this course on this date with this result.

Import history as records

Most LMS platforms can import historical or external training records from a spreadsheet or file, usually with fields for learner ID, course, completion date, score and status. Some call these external, historical or offline completions. Ask your new vendor for the exact template early, because its required fields will shape how you export from the old system.

Map courses carefully

Old course names rarely match new ones. Build a mapping sheet: old course ID, old title, new course ID, new title, and a note on whether the new course counts as the same requirement. If a compliance course was rebuilt, decide whether old completions still satisfy the new requirement or only count as history.

Protect certificates and expiration dates

Certifications with renewal cycles are the highest-risk records. If expiration dates don't come across correctly, people either get assigned training they don't need yet or, much worse, drop off the renewal list entirely. Test these records first and test them hardest.

Keep the detailed data, even if you can't load it

Some data won't fit the new LMS: SCORM attempt details, quiz responses, or years of activity logs. Export it anyway and store it in an archive you can search. If you use xAPI, statements can often be forwarded to a standalone Learning Record Store (LRS), which keeps that detail portable. The LRS overview from xAPI.com explains how that storage works.

How Do You Move Course Content?

Move course content by re-uploading packages and re-testing every one, not by assuming they'll behave the same. A SCORM course that tracked perfectly in your old LMS can report differently in a new one, because each platform makes its own choices about status, windows and completion rules.

1. Gather the original packages, and the authoring source files wherever you have them.
2. Republish anything old or problematic from source, using the version the new LMS handles best.
3. Upload, then walk each course end to end as a test learner, including a mid-course exit, a resume and a failed quiz.
4. Check completion rules in the new LMS for each course.
5. Note any course that needs rework, and decide whether to fix, replace or retire it.

Moodle is a common destination for teams moving off older or more expensive platforms, and its SCORM activity has a lot of settings that affect tracking. If that's your path, my walkthrough of Moodle SCORM uploads covers the settings that matter most.

What About Learners Who Are Mid-Course at Cutover?

In-progress SCORM attempts generally can't be moved between platforms. Bookmarks and suspend data live in the old system and won't transfer in a usable way. So plan for those learners deliberately. You have three reasonable options:

• Set a cutoff date and ask learners to finish in-progress courses in the old system before it.
• Let them restart in the new system, and say so clearly, especially for long courses.
• For long programs, keep the old system available in read-only or finish-only mode for a short overlap.

Whatever you choose, communicate early and twice. Nobody minds a restart they were warned about. Everybody minds losing an afternoon of progress by surprise.

How Do You Prove the Migration Worked?

Prove it with numbers and with people. Numbers catch missing records in bulk. People catch the ones that look right but aren't.

1. Reconcile counts. Compare the number of users, completions per course and active certifications between the old export and the new system. Investigate every gap.
2. Spot-check a sample of real learners, including long-tenured employees, recent hires, people who changed roles and former employees.
3. Run your key compliance reports in both systems and compare the results.
4. Ask a few managers to review their team's records in the new system.
5. Store the full archive export, the mapping sheets and the reconciliation results together, so you can answer an auditor's question years from now.

Don't switch off the old system until the reconciliation is signed off. Read-only access for a few months costs far less than rebuilding a lost record.

Which Shortcuts Cause LMS Migration Trouble Later?

Most migration problems trace back to a shortcut that looked harmless at the time:

• Starting configuration before understanding the data
• Moving everything, including years of retired courses and duplicate accounts
• Assuming user IDs match across systems when one uses email and the other uses employee number
• Testing a handful of courses instead of all of them
• Forgetting manually entered external training and instructor-led records
• Cancelling the old contract before the archive export is complete and verified

Check your current contract early, too. Some agreements limit how and when you can export data, or charge for bulk exports. Knowing that up front protects your timeline. For general background on how LMS platforms store and manage records, the overview of learning management systems on Wikipedia is a helpful primer for stakeholders new to the topic.

An LMS Migration Is a Records Project First

The new platform is the exciting part, but a successful LMS migration is really a records project with a software project attached. Inventory everything, clean it up, map it carefully, move history as data, re-test every course, plan for in-progress learners and prove the result with reconciled counts.

If a migration is anywhere on your horizon, start the inventory now. It costs nothing but time, and it turns the rest of the project from a scramble into a checklist. If you'd like a second opinion on your data map, or a hand testing course packages in the new platform, that is part of the LMS integration work I do.

← All articles