LMS Data Migration Guide — A 2025 Step-by-Step Guide for L&D and IT Teams

Industry research from Brandon Hall Group consistently shows that more than 40% of LMS implementations run over budget or timeline, and data migration is the single most cited root cause. Corrupted completion records, missing user profiles, SCORM packages that refuse to launch in the new environment; these are not edge cases. They are the norm when organizations skip structured planning.

This guide covers every phase of LMS data migration, moving users, content, and completion records, across six structured phases with 20+ checklist items. Whether you are on an L&D team managing a vendor switch or an IT lead running a full platform replacement, this is your step-by-step playbook for 2025.

Why LMS Data Migrations Fail — The Top 3 Practitioner-Reported Reasons

Failure Reason #1: No data mapping plan before migration begins. Organisations assume the new LMS will ‘just accept’ their export files. In practice, custom user fields, completion status labels (“passed” vs “completed”), and SCORM 1.2 vs SCORM 2004 version mismatches cause silent failures, records import but track incorrectly, or completions disappear entirely. G2 reviewers on multiple enterprise LMS platforms cite this as the top post-go-live frustration.

Failure Reason #2: Migrating ‘in-progress’ enrollments without a cut-off policy. Moving partially completed courses creates confusion for learners, they either restart from scratch or land mid-module with broken bookmarks. Practitioners on Reddit r/elearning consistently recommend migrating only completed enrollments and setting a hard cut-off date for in-progress work before go-live.

Failure Reason #3: Testing conducted only by administrators, not real learners. SSO loops, broken SCORM launches, and certificate delivery errors routinely pass admin QA because admins use elevated permissions. Pilot groups must include everyday learners from multiple departments and devices. Support forum patterns across Moodle, Cornerstone, and Canvas show that learner-reported errors spike in the first two weeks post-launch when this step is skipped.

Before You Begin: Prerequisites and Readiness Assessment

Rushing into an LMS data migration without completing this phase is the single fastest way to exceed your timeline and budget. Invest two to three weeks here, it saves months later.

Stake holder Alignment

• Identify an executive sponsor who can resolve cross-departmental blockers (IT vs L&D priority conflicts are the most common cause of phase delays).
• Map all stakeholders: L&D leads, IT/systems team, HR/HRIS owners, compliance officers, and end-user representatives from each major department.
• Define your migration goals in writing: Is this a full platform replacement? A content-only migration? Consolidation of multiple LMS instances?
• Secure a project manager, LMS migrations consistently fail when treated as a ‘side task’ for existing staff already at capacity.

 

Data Audit

• Export a full inventory of all users (active and inactive), courses, enrollments, completion records, and certificates from your current LMS.
• Flag inactive users (ex-employees, test accounts) for archiving rather than migration, migrating ghost accounts pollutes reporting in the new system.
• Identify all content formats in use: SCORM 1.2, SCORM 2004, xAPI, cmi5, PDF, video, ILT sessions. Confirm which formats your new LMS support.
• Review your company’s data retention policy before purging any historical completion records, regulated industries (healthcare, finance, manufacturing) must retain training records for defined periods.
• Check whether your current LMS overwrites historical attempt data (a common issue where only the final pass/fail is stored rather than all attempts).

Technical Requirements Check

• Confirm SSO compatibility: SAML 2.0, OAuth 2.0, or LDAP, test this before any data moves.
• Verify HRIS integration: will user provisioning sync automatically in the new platform?
• Establish a staging environment in the new LMS for test migrations, never run first-pass migrations against your live production instance.
• Agree on a rollback plan: retain read-only access to the legacy LMS for at least 60 days post-cutover.

Phase 1 — Discovery  and Data Audit: Steps 1–4

This phase establishes the factual foundation for every decision that follows. Skipping any step here creates compounding problems in later phases.

Step 1: Full Content Inventory

1. Export a complete list of all courses, modules, quizzes, videos, job aids, and learning paths from your current LMS.
2. Categorize each asset: Update (minor fix needed), Revise (significant rework), Overhaul (rebuild from scratch), or Retire (no longer relevant).
3. Use completion rate data to inform retirement decisions; courses with under 20% completion over 12 months are candidates for deletion rather than migration.
4. Document every content format and version (SCORM 1.2 vs 2004, xAPI version, video codec, etc.), version mismatches are the leading cause of broken content post-migration.

Step 2: User Data Inventory

1. Export all user records including: full name, email, employee/student ID, department, role, group memberships, and any custom profile fields.
2. Separate active users from inactive (former employees, test accounts). Plan to archive rather than migrate inactive records.
3. Identify users with compliance-critical training records, these must be migrated with full historical completions, not just current status.

Step 3: Completion Records Deep-Dive

1. Export all completion records including: completion date, completion status, score, number of attempts, certificate expiry dates, and time-on-task data.
2. Determine whether your current LMS stores all attempts or only the most recent, if only the latest, document this limitation for compliance teams before migration.
3. Identify which completions are compliance-mandatory vs elective, mandatory completions require 100% fidelity; elective data can tolerate some imprecision.
4. Set a hard cut-off date for migrating ‘in-progress’ enrollments: require learners to either complete or restart courses before the cut-off.

Step 4: Integration Mapping

1. List all current LMS integrations: HRIS, CRM, SSO provider, video hosting, webinar tools, and analytics platforms.
2. Confirm which integrations will be rebuilt vs retired in the new platform.
3. Document all API connections, webhook endpoints, and authentication tokens that will need to be reconfigured.

Phase 2 — Data Mapping and Cleansing: Steps 5–8

Data mapping is the most technically demanding phase of any LMS data migration. Every field in your source system must be explicitly matched to a field in the destination system, or flagged as unmappable.

Step 5: Field-Level Data Mapping

1. Create a data mapping document: a spreadsheet with columns for Source Field, Source Format, Destination Field, Destination Format, Transformation Required, and Migration Owner.
2. Pay special attention to completion of status labels; different LMS platforms use different values (‘passed’, ‘completed’, ‘satisfactory’, ‘failed’, ‘incomplete’). Map each source value explicitly to its destination equivalent.
3. Map custom user profile fields individually; standard fields (name, email) transfer cleanly; custom fields (cost center, location code) often require manual transformation.

Step 6: Data Cleansing

1. Remove duplicate user accounts (same email, multiple records).
2. Standardize date formats, completion date fields often contain inconsistent formats (MM/DD/YYYY vs YYYY-MM-DD) that break import validators.
3. Normalize department and role labels if they vary across records.
4. Archive all historical data to a secondary backup before any cleansing, this is your safety net.

Step 7: Content Format Preparation

1. Re-publish SCORM 1.2 packages to SCORM 2004 (or xAPI) if your new LMS requires a different version, do not assume backwards compatibility.
2. Test every SCORM package in SCORM Cloud before importing to the new LMS, this isolates whether bugs are in the content or the platform.
3. Standardize file naming conventions for all assets before bulk upload.
4. Optimize video file sizes, oversized assets slow down the new LMS and frustrate learners on day one.

Step 8: Full Backup

1. Create a complete backup of your entire current LMS, database, content files, user records, and completion data.
2. Store this backup in at least two separate locations (primary server + cloud archive).
3. Document exactly when the backup was taken so the delta sync window is clear.

Phase 3 — Platform Configuration: Steps 9–11

Before a single user record or course file moves, the new LMS must be fully configured and tested. Skipping this phase and configuring ‘on the fly’ during migration is a guaranteed way to corrupt records.

Step 9: New LMS Setup

1. Configure SSO authentication; test login flows across all device types (desktop, mobile, tablet) before migration.
2. Set up all user roles, permission groups, and organizational units in the new system to mirror your current structure.
3. Configure your HRIS integration if applicable, automated user provisioning should be active and tested before bulk user import.

Step 10: Content Configuration

1. Set up all course categories, learning paths, and catalogue structures before importing content.
2. Configure completion rules for each course type, ensure pass thresholds, attempt limits, and expiry rules are set correctly before any learner data maps to them.
3. Test SCORM and xAPI tracking settings in the staging environment with a sample course, verify that completion status, score, and time-on-task are recording correctly.

Step 11: Integration Rebuild

1. Reconnect all integrations (HRIS, SSO, video tools) and test each end-to-end before proceeding.
2. Validate that automated user sync from HRIS is creating, updating, and deactivating user accounts correctly.

Phase 4 — Pilot Migration: Steps 12–13

A pilot migration is not optional. It is the single most effective risk mitigation step in the entire LMS data migration process. Run it with 5–10% of your total data volume.

Step 12: Pilot Execution

1. Select a representative pilot group: include users from different departments, different roles, and different completion record types (some with many completions, some with few, some with compliance-mandatory records).
2. Migrate the pilot group’s user records, course completions, and a cross-section of content to the staging environment.
3. Have pilot users actually log in and test, not administrators acting as users. Require them to launch a course, check their completion history, and access any certificates.
4. Run a full data validation: compare completion record counts, scores, and dates between the source LMS and the new platform. Use checksums on content files to verify integrity.

Step 13: Pilot Review and Fix

1. Document every error discovered in the pilot, categorized by severity (data-corrupting vs cosmetic vs minor).
2. Fix all data-corrupting errors before proceeding to full migration.
3. Update your data mapping document to reflect any field or format discrepancies discovered in the pilot.
4. Get sign-off from compliance and L&D leads before moving to Phase 5.

Phase 5 — Full Migration and Go-Live: Steps 14–17

With your pilot validated and your mapping refined, you are ready for full-scale LMS data migration. Plan this phase around minimal disruption; a weekend window with maintenance mode enabled is standard practice.

Step 14: Bulk User Migration

1. Import all active users using your cleaned and mapped CSV files or via the new LMS’s API bulk import.
2. Apply delta sync to capture any new user registrations or profile changes that occurred since your initial export.
3. Verify user counts: total users imported must match active users in your source system to minus archived accounts.

Step 15: Content Migration

1. Import all course content using the batch/bulk import tools provided by the new LMS vendor.
2. Verify that all SCORM and xAPI packages launch correctly after import, do not assume successful import equals functional content.
3. Spot-check 10% of imported courses with a manual launch test covering multiple content types.

Step 16: Completion Records Migration

1. Import all completion records using the vendor’s prescribed CSV format; this is typically the most sensitive step and should be reviewed by both IT and compliance stakeholders.
2. Validate completion record counts: total completions in new LMS must equal total completions in source export.
3. Run a final delta sync to capture any completions recorded between your bulk export and go-live.

Step 17: Go-Live Cutover

1. Disable write-access to the legacy LMS (retain read-only access for 60 days minimum).
2. Enable the new LMS for all users simultaneously or by department rollout, document which approach and timeline.
3. Set up a dedicated support channel for go-live week (Slack channel, help desk queue, or named point of contact per department).
4. Monitor SCORM completion rates, login success rates, and system error logs in real-time for the first 48 hours.

Phase 6 — Post-Migration Stabilization: Steps 18–20

Go-live is not the finish line. The four to six weeks after cutover are critical for ensuring adoption, resolving edge-case errors, and validating that compliance records are accurate.

Steps 18–20: Stabilize and Optimize

1. Monitor key metrics weekly for the first six weeks: login rates, SCORM completion rates, helpdesk ticket volume by issue type, and page load errors.
2. Solicit structured feedback from learners and admins at the two-week and six-week marks, use targeted surveys, not generic satisfaction ratings.
3. Archive the legacy LMS fully (or decommission) only after six weeks of stable operation and compliance sign-off on record accuracy.

LMS Data Migration: Phase Timeline Table

This table is your project management reference. Share it with stakeholders during kickoff and update it weekly during execution.

Implementation Complexity Rating by LMS Platform

Complexity ratings below are based on native export/import tooling capabilities, historical migration project timelines, and practitioner-reported friction from forums and vendor documentation reviews. Ratings reflect the complexity of migrating FROM each platform (egress complexity).

The 7 Most Common LMS Data Migration Mistakes — and How to Avoid Them

Mistake 1: Starting migration before completing a data audit. Organizations eager to hit a go-live date skip the audit phase. The fix: mandate a two-week audit and make it a gating milestone, nothing moves until the audit report is approved.

Mistake 2: Migrating ‘in-progress’ enrollments. Partially completed courses cause broken bookmarks, confused learners, and inflated ‘incomplete’ counts in reports. The fix: set a hard cut-off date and require learners to complete or abandon in-progress courses before migration.

Mistake 3: Ignoring SCORM version mismatches. Assuming your SCORM 1.2 content will behave identically in a new LMS is a common and costly error. The fix: test every content package in SCORM Cloud before migration and re-publish any packages that fail.

Mistake 4: No rollback plan. If go-live fails, organizations with no fallback lose access to learner records. The fix: keep read-only access to the legacy LMS active for a minimum of 60 days post-cutover, and document the rollback procedure before go-live.

Mistake 5: Treating completion record migration as an afterthought. Completion records are the most legally sensitive data in your LMS. Migrating them last, without a validation step, risks compliance failures. The fix: validate completion record counts and spot-check individual records as a dedicated milestone — not an afterthought during go-live.

Mistake 6: Only testing with administrators, not real learners. Admin accounts have elevated permissions that bypass many failure modes real learners encounter. The fix: recruit a diverse pilot group and require them to complete full learning journeys, not just check that content loads.

Mistake 7: Decommissioning the legacy LMS too quickly. Rushed decommissioning leaves no safety net for edge cases and compliance queries that surface weeks after go-live. The fix: set a minimum 60-day parallel-access window with a formal sign-off process for decommissioning.

LMS Data Migration Master Checklist (25 Items)

This checklist is your bookmark-worthy companion for the entire migration lifecycle. Phase-gate your project against it — do not advance until each phase is complete.

PHASE 1 — Discovery & Audit

☐ Export full inventory of all courses, modules, quizzes, and learning paths from current LMS

☐ Categorize all content: Update / Revise / Overhaul / Retire

☐ Export all user records including custom profile fields

☐ Identify and separate active vs inactive users

☐ Export all completion records including dates, scores, attempts, and certificate data

☐ Determine if current LMS overwrites historical attempt data

☐ Set a hard cut-off date for in-progress enrollments

☐ Map all existing LMS integrations (HRIS, SSO, video, analytics)

PHASE 2 — Data Mapping & Cleansing

☐ Create field-level data mapping document for all user, content, and completion data

☐ Map all completion status labels between source and destination LMS

☐ Remove duplicate user accounts and normalize data formats

☐ Re-publish SCORM packages to correct version if required

☐ Test all SCORM/xAPI packages in SCORM Cloud before import

☐ Create full backup of current LMS data in two separate storage locations

PHASE 3 — Platform Configuration

☐ Configure SSO and test across all device types

☐ Set up all user roles, groups, and org unit structures

☐ Configure HRIS integration and verify automated user provisioning

☐ Set completion rules for all course types in new LMS

☐ Rebuild and test all third-party integrations

PHASE 4 — Pilot & Validation

☐ Run pilot migration with 5–10% of total data

☐ Recruit real learners (not just admins) for pilot testing

☐ Validate completion record counts between source and destination

☐ Get compliance and L&D sign-off before full migration

PHASE 5–6 — Full Migration & Stabilisation

☐ Run bulk user, content, and completion record migration

☐ Execute delta sync for records created after bulk export

☐ Monitor login rates, SCORM completions, and error logs for 6 weeks post-go-live

☐ Retain read-only access to legacy LMS for minimum 60 days

☐ Conduct formal decommission sign-off with compliance team