.webp)
Switching learning management systems is not a decision most L&D teams make lightly. The combination of sunk implementation cost, content dependencies, and learner record continuity requirements makes it one of the more complex system changes an organisation undertakes outside of an HRIS replacement.
But it happens regularly and often for the same reasons. The platform has not kept pace with programme complexity. The TMS gap has become unworkable. A merger or acquisition has introduced conflicting systems. The contract renewal conversation has revealed that the current vendor is not building what the team needs.
This guide walks through a practical 6-stage migration process, the specific data categories that most teams underestimate during planning, and the questions to resolve before you move a single record.
Before You Start: The Four Migration Pre-Questions
These questions should be answered before any migration planning begins. The answers shape every decision that follows.
1. What do you actually need to migrate?
Not everything needs to move. Historical completion data for leavers who left three years ago does not need to live in the new system. Compliance records for regulations that have since changed may be better archived than migrated. A pre-migration audit of what learner data, content, and configuration actually needs to transfer versus what can be archived or left behind typically reduces the migration scope by 20 to 40 per cent.
2. What format is your existing content in?
SCORM 1.2 and SCORM 2004 content is generally portable, but older SCORM packages sometimes have dependencies on the originating authoring tool or LMS player that create unexpected rendering issues in a new environment. xAPI content is more portable but requires the new LMS to have a compatible LRS. Proprietary content built inside the current LMS using a native authoring tool may need to be rebuilt from source files rather than exported.
3. What does your compliance evidence requirement look like?
Regulated industries need to understand whether historical completion records in the new system will be accepted as audit evidence or whether the original system needs to remain accessible in read-only mode during a transition period. This is not an LMS decision it is a legal and compliance decision that needs input from the relevant internal stakeholders before migration starts.
4. What is your go-live deadline and why?
The most common reason LMS migrations go wrong is an artificial deadline that compresses the testing phase. If the go-live date is driven by a contract end date, it is worth understanding whether a short-term extension is available even at cost to avoid rushing parallel testing. A migration that goes live with incomplete data is harder to fix after the fact than one that goes live two weeks late.
A frequent mistake in LMS migrations
Setting the go-live date before completing the data audit. The audit typically reveals scope that was not anticipated in the project plan content that needs reformatting, learner records that need manual review, or integration dependencies that require additional configuration. Starting with the date rather than the scope creates a compressed timeline for the wrong reasons.
The 6-Stage LMS Migration Process
Stage 1: Audit and Requirements — What Most Teams Miss
The audit phase produces four deliverables that drive the rest of the migration: the content inventory (every course, module, and asset with its format and current usage data), the learner data map (which completion fields need to migrate and in what format), the reporting requirements document (what management reports need to produce the same output from the new system on day one), and the integration register (every system currently connected to the LMS HRIS, SSO, CRM, VILT platform and its integration method).
The integration register is consistently the most underestimated part of the audit. Organisations typically know about the Workday or BambooHR connection but have forgotten the SSO integration configured eighteen months ago or the Zoom connector set up for VILT scheduling.
Stage 2: Data Export and Mapping
Learner completion data in LMS systems is typically stored in a format proprietary to the platform. The export format (usually CSV or xAPI statements) needs to be mapped field-by-field to the data schema of the new system.
The fields that most commonly create problems: completion status (passed/failed/completed definitions vary between platforms), score (the decimal format and pass mark threshold may differ), time spent (some platforms store this in seconds, others in minutes the difference creates reporting inconsistencies), and certificate expiry dates (if the old system stored these, they need to migrate with the correct expiry logic applied in the new system).
What to watch in data mapping
When a learner has completed the same course multiple times re-takes, annual renewals, or version updates the historical attempts need a defined handling rule before migration. Most platforms default to migrating only the most recent completion. If audit requirements demand a full attempt history, this needs to be explicitly configured rather than assumed.
Stage 3: Content Migration
SCORM and xAPI packages should be tested in the new LMS player before the full content migration, not after. A sample of 10 to 15 packages including the oldest content in your library and any courses with complex branching will surface player compatibility issues early. Video content hosted externally (YouTube, Vimeo, Wistia) typically migrates without issues; video embedded directly in the LMS may need to be re-uploaded to the new system's media library.
Proprietary content built in the old LMS's native authoring tool is the most problematic category. If the source files (usually PowerPoint, Articulate, or Lectora project files) are not available, the content needs to be rebuilt. This is worth identifying in the audit phase, not the content migration phase.
Stage 4: User and Permission Setup
If the new LMS connects to your HRIS, the user setup stage is largely automated the sync pulls employee records with roles, departments, and manager relationships. The configuration work is in the rule engine: which roles trigger which course assignments, what the completion deadline is for each, and which manager receives the compliance dashboard for each team.
Test the HRIS sync specifically with a new joiner scenario and a role-change scenario before go-live. These are the two situations most likely to produce incorrect data in the first month after cutover.
Stage 5: Parallel Testing
The parallel testing phase is the most consistently under-resourced stage of LMS migrations. A pilot group of at least 30 learners covering multiple roles, departments, and completion states should complete real courses in the new system while the old system remains active. The comparison should verify: completion records write to the learner profile correctly, manager dashboards show accurate team data, compliance reports produce the same output as the equivalent report in the old system, and automated assignments trigger on the correct conditions.
Any discrepancy found in parallel testing is significantly cheaper to fix before go-live than after.
Stage 6: Cutover and Decommission
The cutover itself is typically straightforward: the new system goes live, active learners are notified, and a communication plan guides them to the new platform. The HRIS sync ensures new starters from cutover day onwards are onboarded into the new system automatically.
The decommission timeline is where judgment is required. Keeping the old system in read-only mode for 90 days post-cutover is the minimum. For regulated industries, 12 to 18 months is more appropriate compliance queries and audit requests for historical data arise well after teams have mentally moved on from the old platform.
The Pre-Go-Live Checklist
VERIFY BEFORE GO-LIVE
- Content audit complete all courses catalogued with format, usage data, and migration priority confirmed
- Data mapping document signed off every completion field mapped to the new system schema with handling rules for edge cases
- SCORM/xAPI compatibility test complete 10-15 courses tested in the new LMS player with no critical errors
- HRIS integration tested new joiner and role-change scenarios verified, producing correct data
- SSO tested all user authentication routes confirmed working
- Compliance report output compared new system reports produce equivalent output to old system reports
- Manager dashboards verified team compliance views showing accurate data for pilot group
- Automated assignment rules tested role-based course assignments triggering on correct conditions
- Go-live communication sent to all active learners with clear instructions for the new platform
- Old system read-only access confirmed decommission date documented and communicated to compliance team
Migration is complex enough without the platform making it harder. See how Trainery is built to make the switch clean, complete, and audit-ready from day one. Get a Demo
.webp)
.svg)
.svg)
.svg)
