Switching your learning management system touches everything: course content, enrollment records, completion history, and every integration your SIS and gradebooks depend on. Get the migration wrong and you lose transcript data or break compliance evidence; get it right and you finally stop fighting a platform that's outgrown its use. This checklist is for IT leaders, L&D teams, and school or training-provider admins planning a switch.
Before you start
- [ ] Assemble a migration team spanning IT, L&D/academic staff, and a project owner with sign-off authority.
- [ ] Inventory every course, user account, and completion record on the legacy LMS — active, inactive, and archived.
- [ ] Decide what actually migrates. Not every retired course or dormant account needs a new home; archiving isn't the same as migrating.
- [ ] Confirm your legal/compliance stakeholders' position on whether historical completion records need to move as live data or can stay accessible read-only during a transition window.
- [ ] Set a firm cutover date and a parallel-access window — a minimum 60 days of read-only legacy access is standard practice, longer for regulated training records.
Data and content audit
| Category | What to check |
|---|---|
| Course content | Active vs. retired courses, quiz/assessment banks, video files, SCORM/xAPI packages |
| User accounts | Active learners, inactive accounts, admin roles, group/cohort assignments |
| Completion records | Course completions, CE credits, certification renewal and expiration dates |
| Integrations | SIS/gradebook sync, SSO, roster provisioning (OneRoster/Ed-Fi), payment/billing if applicable |
Technical compatibility
- [ ] Confirm the destination LMS supports both SCORM 1.2 and SCORM 2004 if your legacy content uses both — completion logic differs between them and mismatches silently corrupt scoring.
- [ ] Check xAPI support if you need granular interaction-level tracking that SCORM can't capture.
- [ ] Map SCORM-based quiz scoring rules explicitly — scoring logic is one of the most common casualties of an LMS migration and rarely fails loudly.
- [ ] Verify LTI compatibility if third-party tools (proctoring, plagiarism detection, publisher content) plug into your courses.
- [ ] Where source and destination platforms don't align on standards, budget extra time for manual data mapping rather than assuming an automated import will handle it.
Compliance and data integrity
- [ ] Confirm completion and assessment history migrates as structured records mapped to the correct user and course, with original timestamps preserved — this is the layer regulators and auditors care about most.
- [ ] For FERPA-covered institutions, document who has access to student records during the migration window and confirm the new platform's data handling meets the same standard as the old one.
- [ ] Get a written answer on whether the new system's imported records will be accepted as audit evidence, or whether you need to retain the legacy system as the system of record for a defined period.
- [ ] Test a full-fidelity migration in a staging environment before touching production data — never run a first-pass migration live.
Cutover and rollback
- [ ] Freeze non-critical changes on the legacy LMS in the days before cutover to avoid a data mismatch between the final export and go-live.
- [ ] Run a parallel validation pass: spot-check a sample of migrated completion records against the legacy system before declaring success.
- [ ] Keep the legacy LMS in read-only mode for your agreed window, with a formal sign-off process before decommissioning it.
- [ ] Communicate the cutover plan to instructors and learners in advance, including what happens to in-progress courses on migration day.
How to use this
Work through "Before you start" and the data audit table first — most migration failures trace back to skipping the audit and assuming the vendor's import tool handles edge cases. Use the technical compatibility section as a direct question list for your new LMS vendor before signing a contract, not after.