An LMS migration goes wrong in predictable places. The courses come across, the video plays, and then a learner logs in to find four years of completions gone and the certificate on her wall with no matching record.
Moving content is the easy half. Learner records, completion history and certificates already issued are the half that decides whether people trust the new system.
This is a working plan for an LMS migration: what to export, how SCORM packages travel, how to bring accounts and history across, a cut-over sequence, and the tests to run before you switch anyone over.
Decide what moves, what gets rebuilt and what gets archived
Do not migrate everything. Most libraries carry courses nobody has opened in two years. Sort the inventory into three piles before you touch an export button: move as is, rebuild, or archive and retire.
| What | Usual export form | Watch out for |
|---|---|---|
| Course structure and pages | SCORM package, HTML or a content export file | Styling and layout rarely survive intact |
| Video and audio | Source files from your media library or server | Originals may have been deleted after upload |
| Question banks | CSV, QTI or the platform’s own question export | Images inside questions, negative marking, partial credit |
| Quiz and exam definitions | Usually rebuilt, not exported | Time limits, randomisation rules, pass marks |
| Learner accounts | CSV from the user table or your HR or student system | Duplicate accounts, old email ids, no phone number |
| Enrolments and progress | CSV per course or a reporting export | Partial progress is often not portable |
| Completions and scores | CSV with dates, scores and attempt counts | Time zone of the stored timestamp |
| Certificates issued | PDF files plus a CSV index | Certificate numbers must stay unchanged |
| Forum posts and messages | Often not exportable | Decide early whether to archive or lose them |
Write the decision for each row into one sheet and get the owner of each course to sign against it. That sheet prevents most of the arguments that come later.
SCORM packages: what travels and what does not
SCORM is the reason course content is portable at all. The standard is maintained by the ADL Initiative, which supports SCORM 1.2 (released 2001), SCORM 2004 3rd Edition and SCORM 2004 4th Edition (2009).
A SCORM course leaves the old system as a zip file, called a Package Interchange Format or PIF, containing the course files and an XML manifest named imsmanifest.xml at the root that describes the contents and the order in which the parts are delivered. Alongside packaging, SCORM defines a run-time data model and an API so the content can report score and status back to the LMS.
Three things to check before you rely on a package.
- Which version was it authored in? A 1.2 package and a 2004 package behave differently on completion and scoring. Note the version for each course.
- Does the zip actually contain the media? Some authoring tools produce packages that stream video from the old server. Those break the day the old server is switched off.
- Is the run-time data being used? If a course sets completion or score through the SCORM API, test that path, not just whether the pages open.
Learner history that lives inside a SCORM package, such as bookmarks and suspended session data, generally does not travel. Assume learners restart a partly finished course and tell them so in advance.
Learner accounts and history
Rebuild accounts from the authoritative source, not from the old LMS. For a company that is the HR or payroll master, for an institute the admissions record. The old LMS user table is a copy that has been drifting for years.
- Export users from the authoritative system with a stable unique id: employee code, student roll number or enrolment number.
- Export users from the old LMS and match on that id. Anything that does not match goes on an exception list for a human to decide.
- De-duplicate. The same person with two email ids is normal and both records usually carry completions.
- Import accounts into the new system with the same unique id, and set roles and cohorts at import rather than afterwards.
- Import completion history as records against the person and the course: course name, completion date, score, attempts, certificate number.
- Mark imported rows as historical. An auditor should be able to tell a record created by the old system from one created by the new one.
Do not try to reconstruct in-progress states. Completed and not completed are the two worth carrying. Anything in between costs days and helps almost nobody.
Certificates already issued
A certificate already in someone’s hands is a promise. If the number printed on it stops resolving, you have created a problem that is visible outside the organisation.
Carry the certificate number across unchanged, keep the original issue date rather than the import date, keep the expiry date if the certificate carries one, and store the original PDF as an attachment even if the new system can regenerate the design. Then test verification with real numbers taken from real certificates, including one issued years ago, before you switch anything off.
Personal data during the migration
Learner records are personal data, and a migration is exactly the moment when copies spread into laptops, email attachments and vendor folders. The Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025 with an eighteen-month period for phased compliance, and the Act places clear responsibility on the organisation holding the data to keep it safe. The highest penalty under the Act, ₹250 crore, attaches to failure to maintain reasonable security safeguards.
Practically: keep exports encrypted, name the two or three people allowed to touch them, delete working copies on a fixed date after go-live, and record that deletion. If keeping this data inside your own network is part of why you are moving, our comparison of self-hosted and cloud hosting for an LMS covers what that changes.
The LMS migration cut-over plan
Run the migration twice. The first run is a rehearsal on a copy, timed and documented. The second run is the real one, following the notes from the first.
- Four weeks out: rehearsal import into a test instance. Record how long each step takes and every error.
- Three weeks out: fix what the rehearsal exposed. Re-export anything that came in wrong.
- Two weeks out: pilot with one cohort of 20 to 30 real learners on real courses. Collect their complaints, not your own.
- One week out: tell every learner the date, what changes, and that partly finished courses restart. Freeze new course uploads on the old system.
- Cut-over day: stop enrolments on the old system, take the final export of completions since the rehearsal, import, reconcile counts, open the new system.
- Day one to seven: keep the old system running in read-only mode. Staff a helpdesk number for the week.
- After 30 days: archive the old system as a full backup, confirm the backup restores, then decommission.
Testing before the switch
- Pick ten learners at random and reconcile every completion, score and certificate against the old system, row by row.
- Check the total count of completions per course matches between old and new, and investigate any difference.
- Open one course of each type and each SCORM version on a desktop and on a mid-range Android phone.
- Take one full assessment end to end, including a deliberate network drop, and confirm the result is recorded.
- Verify three certificates by number, one recent, one old and one expired.
- Run the reports the management actually reads and compare them with last month’s numbers from the old system.
Frequently asked questions
How long does an LMS migration take?
The content is rarely the constraint. Cleaning the user list, agreeing what to retire and reconciling history take the time. Plan in weeks rather than days, and treat the rehearsal run as compulsory.
Can we move an old SCORM 1.2 course without re-authoring it?
Usually yes, if the package is self-contained and the new system imports that version. The usual failures are missing media and content that referenced the old server, both of which the rehearsal import will show up.
What if the old system will not give us an export?
Take what you can through reports and the database. Where nothing else works, carry the history as a signed CSV attached to each learner record. Weaker than a native import, far better than losing it.
Should we run both systems in parallel for a while?
Read-only, not in parallel. Two systems both accepting enrolments produce two versions of the truth, and reconciling them costs more than the migration did.
Where Quipu LMS fits
If you are moving to a system you run yourself, Quipu LMS imports SCORM content, carries roles and cohorts, handles assessments and auto grading, and issues certificates with verification and expiry tracking, with setup, data migration and training handled by the team in Hubli.
