LMS Migration Without Losing Your Training History

Switching learning platforms doesn't have to mean starting your training record from zero. Here's what actually breaks in an LMS migration, and the sequence that keeps your history intact.

I build and support LMS platforms for a living — Moodle, Blackboard, custom WordPress builds — and the question that gets asked too late, almost every time a platform change comes up, is what happens to the last several years of completion records, certificates, and assessment history sitting in the old one. By the time anyone asks, the new platform is usually already picked. That order is backwards, and it's exactly how organizations end up re-certifying employees who were already certified, or losing the one audit trail a regulator asked for. An LMS migration is not a content export. It's a continuity problem, and it has to be planned as one from the start.

What actually breaks when you move platforms

The course files are usually the easy part. SCORM packages and xAPI statements are built to be portable in theory, but in practice, the records tied to them are shaped by the platform that created them — a learner ID, a course structure, a completion threshold that lives in the old LMS's database and not in the package itself. Move the content without mapping that structure first, and you can end up with a course that imports cleanly but shows every learner as zero percent complete, even though they finished it eighteen months ago. Certificates are worse: most platforms generate them on the fly from a completion record, so if that record doesn't carry over, the certificate doesn't exist anymore even if the learner genuinely earned it.

Decide what deserves to make the trip

Not everything in your current LMS should migrate. A platform change is the one moment you have real leverage to retire courses that are out of date, assessments nobody has looked at the results of in years, and content built for a role that no longer exists. Carrying all of it forward out of habit just means you've spent a migration budget moving dead weight into a new system. The content worth migrating as full, interactive courses is the content still actively assigned. The content worth migrating only as a completion record — a line that says who finished what and when — is everything else you're keeping for audit or resume purposes but won't run again.

A sequence that actually protects history

Here's the sequence that actually protects history, regardless of which platforms are on either end:

Vendor lock-in shows up most clearly during a migration

You find out how much control you actually had over your own training data at exactly the moment you try to leave. Some platforms make export painless. Others charge for it, throttle it, or hand you a format that technically contains the data but isn't usable without their own tooling to read it. This is the argument for asking the export question before you sign with any LMS, not after — whether you're evaluating a cloud SaaS platform, an open-source build like Moodle, or a custom-built system. The platform that's easiest to get into is not always the one that's easiest to get out of, and a migration is where that gap gets expensive.

What happens when the builder and the migrator are different teams

Under subcontract to WiseWire, I helped build the road-safety and rehabilitation-leadership training platforms for a Johns Hopkins University-affiliated program, in WordPress. Years later, the platform migrated to a different system entirely — that migration wasn't work my team did, and I don't know the details of how it was run. But it's a real example of the risk every long-lived training platform eventually carries: the team that builds it and the team that eventually moves it are often not the same people, on a timeline nobody who built the original system controls. Plan your migration documentation as if someone other than you will be the one executing it, because eventually, someone usually is.

A clean LMS migration isn't the one with the newest features on the other side. It's the one where a learner who finished a course in the old system can still prove it in the new one, and where a compliance officer can pull five-year-old records without a caveat. Get the sequence right — inventory, user mapping, certificate verification, parallel run, retained access — and the platform change becomes a non-event for anyone except the admin who planned it.

Frequently asked questions

Will our old completion records transfer automatically to a new LMS? Rarely cleanly. Most platforms can import a course file, but completion records, certificates, and scores are tied to each system's internal structure and usually need explicit mapping or manual verification rather than a one-click import.

How long should we run the old and new LMS in parallel? At minimum, one full reporting cycle — long enough that any compliance report you'd normally pull can be generated and checked against both systems before you decommission the old one.

Is it worth migrating every old course into the new platform? No. Treat a migration as a content audit. Anything no longer actively assigned only needs to move as a historical completion record, not as a rebuilt interactive course.