10 LMS migration mistakes and how to avoid them

An LMS migration fails most often for predictable reasons: the team never inventoried what it had, underestimated historical completion and certificate records, lost SCORM tracking data, mismatched user identities, broke URLs, skipped dry runs and switched everything over in one weekend with no way back. Avoiding these ten mistakes, and following a phased plan with rehearsals and a rollback option, removes most of the risk from moving to a new learning platform.

Whether you are moving from a legacy corporate LMS to Moodle, from a SaaS platform to WordPress, or consolidating several systems into one, the content is usually the easy part. The hard parts are data that proves compliance, identities that connect learners to that data, and the integrations and habits that grew around the old system. Below are the mistakes we see teams plan for too late, how to avoid each one, and a phased plan you can adapt as your LMS migration checklist.

Planning and data mistakes

1. Skipping a content and data inventory

Teams often start by exporting courses and discover months later that the old system also held assignments, forum history, custom user fields, enrolment rules, certificate templates, and reports that managers relied on. Every unknown found after cutover is more expensive than one found in week one.

How to avoid it: build a spreadsheet inventory before choosing a migration approach. For each object type record the volume, the owner, whether it must be migrated, archived or retired, and how it will be validated. Include files and media, question banks, grade history, custom fields, roles and permissions, enrolment methods, reports and scheduled jobs. Use this exercise to retire content: migrating obsolete courses adds cost and clutter.

2. Underestimating completion and certificate history

In regulated industries, historical completions are the asset. Auditors will ask for proof that someone completed a course on a date with a score. If the new LMS cannot represent that history, you either keep the old system alive or lose evidence.

How to avoid it: decide early whether history will be migrated as live records (enrolments, completions and grades recreated in the new system), as a read-only archive (exports stored securely and searchable), or both. Map completion dates, scores, expiry and recertification dates explicitly. Re-issuing certificates from the new platform may change dates or numbering, so agree with compliance owners what "equivalent" means.

3. Losing SCORM tracking data

Re-uploading SCORM packages is straightforward. Carrying over in-progress attempts is not. SCORM stores state per learner and per attempt in the LMS: SCORM 1.2 uses fields such as cmi.core.lesson_status and cmi.suspend_data, while SCORM 2004 separates cmi.completion_status from cmi.success_status and allows far larger suspend data. Suspend data is package-specific and rarely portable between LMSs.

How to avoid it: migrate final outcomes (status, score, date) and accept that in-progress attempts will usually restart. Communicate a deadline so learners can finish courses before cutover. If you are also changing standards, read our comparison of SCORM vs xAPI vs cmi5 before re-publishing content.

Identity and URL mistakes

4. Mismatching user identities and SSO

History is only useful if it attaches to the right person. Emails change, usernames differ between systems, and SSO providers may send a different unique identifier than the old LMS stored. Duplicate accounts after cutover are one of the most visible and damaging migration failures.

How to avoid it: choose one immutable identifier, such as an employee or student ID, and use it as the matching key for every record. Confirm what your identity provider will send in SAML assertions or OIDC claims, and test that first logins land on the migrated account rather than creating a new one. Most platforms support this: Moodle's bulk user upload, for example, accepts an idnumber and an auth method per user. Our guide to LMS SSO with SAML vs OIDC explains the identifier choices.

5. Ignoring URL redirects and SEO

Public course catalogues, landing pages and help articles carry search rankings and inbound links. Changing platforms usually changes every URL. Without redirects, you lose traffic and learners hit dead links from emails, intranets and bookmarks.

How to avoid it: crawl the old site and export URLs from sitemaps, analytics and server logs. Map each old URL to its most relevant new page and implement permanent (301 or 308) server-side redirects. Google's site move guidance recommends keeping redirects for as long as possible, generally at least a year, and warns against redirecting everything to the home page. Remember internal deep links too: course links in HR systems, email templates and intranet pages.

Cutover mistakes

6. No dry runs

A migration script that works on a sample of 50 users can fail on 50,000 because of encoding issues, unexpected nulls, oversized files or timeouts. Discovering that during the real cutover leaves no time to fix it.

How to avoid it: run at least two full rehearsals on a production-sized copy of the data in a staging environment. Time each step, record failures, fix and repeat. Validate with reconciliation reports: user counts, enrolment counts, completion counts per course, and spot checks of individual learners chosen by the business, not by the migration team.

7. Big-bang cutovers

Switching every user, course and integration at once maximises risk and support load on day one. It also means any problem affects everyone.

How to avoid it: phase where you can. Common options are migrating by business unit or region, launching new courses on the new platform while old courses finish on the old one, or running a pilot group first. A short parallel period, with the old system read-only, gives learners and administrators a safety net.

8. No rollback plan

If the new platform fails on launch day, you need a documented, rehearsed way back. Without one, teams push forward with a broken system because retreat is impossible.

How to avoid it: define go and no-go criteria before cutover, keep the old system intact and restorable until the new one is proven, and decide how any activity recorded in the new system during the failed window would be preserved. Rehearse the rollback during a dry run, not in theory.

Integration and communication mistakes

9. Forgetting integrations

An LMS rarely stands alone. HRIS feeds create users and assign mandatory training, CRMs trigger enrolments, payment gateways sell courses, and BI tools pull completion data. These links are often undocumented because they were built years ago.

How to avoid it: list every inbound and outbound connection, including scheduled file drops and webhooks, with owners on both sides. Rebuild and test each one in staging with realistic data. Our article on LMS integrations with HRIS, CRM and payments covers the common patterns.

10. Poor communication

Learners, managers, instructors and administrators all experience a migration differently. Silence breeds support tickets and distrust.

How to avoid it: publish dates early, tell learners what will and will not carry over (especially in-progress courses), train administrators before launch, prepare help content and a support rota for the first weeks, and give managers a way to verify their team's records.

A phased LMS migration plan

Use this table as a starting LMS migration checklist and adapt it to your platform and size.

How we can help

We plan and execute LMS data migrations between Moodle, WordPress LMS plugins, Open edX, Canvas and proprietary platforms, including history, SCORM results, identities and redirects. See our LMS migration services, or talk to us about your inventory and timeline before you commit to a cutover date.