LMS migration guide: how to move to a new LMS without losing data

Disclosure: LMS Advisor is built by the All-in-One LMS team. Where it appears on this page it is marked as our product and described from its public documentation, limitations included.

An LMS migration is the planned move of users, courses, enrolments, completion records and certificates from one learning management system to another, followed by switching learners and integrations to the new platform and retiring the old one. The order of work is: inventory what you hold, decide which history must survive, map it to the new system, rehearse on a copy, reconcile the results, then cut over.

One rule matters more than any other. Decide which history you are obliged to keep, and prove that it arrived, before anyone switches off the old system. Content can be uploaded again next month. A completion record an auditor asks for in three years cannot be recreated once the source is gone.

This LMS migration guide is for LMS administrators, L&D and training operations leads and IT owners who have to migrate to a new LMS. It covers what short checklists tend to skip: what happens to an in-progress SCORM attempt, a certificate with an expiry date or a question bank, and how to prove the data arrived. For the short list of what goes wrong, read our 10 LMS migration mistakes.

What an LMS migration is, and when it is worth doing

Three different things move in a migration, and they fail in different ways. Content is the courses, files, packages and question banks. Records are the evidence that people did things: enrolments, completions, grades and certificates. Connections are everything that points at the platform: sign-in, HR feeds, payment flows, reports and every link in an email or on an intranet page. Content is usually the easy third. Records carry the compliance risk, and in our experience connections cause many of the first-week support tickets.

Reasons that justify a migration

• The platform is ending. The vendor has announced end of life, your version no longer receives security fixes, or the contract cannot be renewed on acceptable terms.
• A requirement it cannot meet. For example data that must stay in one country, single sign-on with automatic provisioning, separate portals for client organisations, or recertification with expiry dates.
• Cost at your volume. Per-user pricing that suited a few hundred learners can look very different after the learner count has multiplied.
• Consolidation. Two or more systems after a merger, with duplicated licences, administrators and reports.
• No way to integrate. There is no usable API or export, so every HR or CRM connection is a manual file.

Reasons that do not

A migration does not fix a content problem or a process problem. It moves both to a new address, at a cost. Be suspicious of these reasons:

• Low completion rates. Courses that are long, dull or irrelevant stay that way in the new system.
• A messy catalogue. Duplicate and abandoned courses are a housekeeping task, and you have to do it before migrating anyway.
• Reports nobody trusts. The cause is usually the data going in: a broken HR feed, duplicate accounts or inconsistent completion rules. A new reporting screen shows the same wrong numbers.
• Nobody owns administration. A platform without a named owner decays on any product.
• The interface looks dated. A new theme or an upgrade is often a fraction of the work.

A simple test: write the problem in one sentence, then ask whether configuration, clean-up or a plugin on the current platform would solve it. If so, do that first. The clean-up is never wasted, because every obsolete course and duplicate account you remove is one you do not pay to move.

What actually moves: an LMS data migration inventory

Start with an inventory, before you choose an approach or accept a quote. Data leaves an LMS by four routes, and the route decides the effort:

• API: good for volume and repeat runs, limited by what it exposes and by rate limits.
• Export file: CSV reports, course backups and standard packages. Simple, but flattened, so detail is lost.
• Database: possible only when you host the system or the vendor supplies a dump.
• Manual rebuild: the only route for most configuration.

Add four columns of your own: the volume, the owner, the decision (migrate, archive, retire or rebuild) and how the result will be checked. A row with no check is a row nobody notices is wrong until an audit.

The hard parts of LMS data migration, explained

Seven areas cause most of the surprises, and each has a technical reason.

SCORM suspend data and in-progress attempts

A SCORM package talks to the LMS through a run-time API, and the LMS stores a small set of values for each learner and attempt. In SCORM 1.2 these include cmi.core.lesson_status, cmi.core.score.raw, cmi.core.lesson_location and cmi.suspend_data. SCORM 2004 splits status into cmi.completion_status and cmi.success_status. Rustici Software's run-time reference lists suspend data limits of 4,096 characters in SCORM 1.2, 4,000 in SCORM 2004 2nd and 3rd Edition and 64,000 in 4th Edition.

Status, score and date are plain values, so a finished attempt is easy to carry: it is imported into the new LMS as a completion record with its original date and score. An unfinished attempt is different. The state a course needs to resume lives in suspend data, a string the authoring tool writes in its own format and, in our experience, often compresses. Only the package that wrote it can interpret it.

To resume, the new LMS would have to hand that package the same string, the same bookmark and a "resume" entry flag inside its own attempt tables. Import tools rarely write at that level, and if the package has been republished the old string may not match the new build.

The realistic outcome: completed history arrives as a record, and in-progress attempts restart. Plan for it:

• Report on in-progress learners several weeks before cutover and give them a finish-by date.
• For long courses, let those learners finish in the old system during a short parallel period.
• Test what happens when someone reopens a course they already completed. A new attempt must not overwrite the imported completion with "incomplete".

If you are republishing content anyway, our comparison of SCORM, xAPI and cmi5 explains which standard to publish to.

xAPI statements and the learning record store

xAPI data is stored as statements (who did what, to which activity, when) in a learning record store (LRS). ADL's version 1.0.3 specification, cited here, was the basis for the standard IEEE 9274.1.1-2023. Statements are designed to be portable: the specification lets a client read them from the statements resource, filtered with since and until, and send them to another LRS. If the old LMS uses an external LRS, you may only need to point the new LMS at it. If the LRS is built into the old LMS, ask for a full statement export early.

The details that catch people out are in the specification's data model and communication rules:

• Two dates. The receiving LRS must overwrite stored with its own time, while timestamp keeps the time of the event. Reports must use timestamp, or every historical statement appears to have happened on migration day.
• Statement IDs. Keep the original id. An LRS must not change anything when it receives a statement ID it already holds, which makes a repeat run safe.
• Actors. A learner is identified by an email address, a hashed email, an OpenID or an account made of a home page and a name. If the home page is the old LMS, the new LMS will not recognise the person without a mapping.
• State. Bookmarks and resume data sit in the separate state resource, which the specification describes as a scratch area. Copying statements does not copy state.

cmi5 adds one more point. Its specification defines a registration as "an enrollment instance of a learner in a course", and the LMS issues the ID. Statements from the old system carry registrations the new LMS never issued, so do not expect it to work out completion from them. Import the completion as a record and keep the statements for analysis.

Quizzes, question banks and QTI

QTI (Question and Test Interoperability) is the 1EdTech specification for exchanging questions, tests and results between systems. "Supports QTI" is not an answer, because versions 1.2, 2.1, 2.2 and 3.0 all exist and support differs by platform and by direction. Canvas, for example, documents import of QTI 1.2 and 2.1. Moodle's question import recommends Moodle XML and lists GIFT, Aiken and a Blackboard format among others, and its question export offers Aiken, GIFT, Moodle XML and XHTML, not QTI.

Ask both platforms which format and version, import or export, and which question types survive. Then test one question of every type you use. Expect to rework calculated and other specialised types, rules that draw random questions from a pool, category trees, embedded images and per-answer feedback. Item statistics and question IDs almost never survive. Learners' past answers are rarely importable as attempts, so carry the result as a grade and archive the detail.

Common Cartridge and platform course backups

Standard course export formats move the course, not the learners.

• Common Cartridge is the 1EdTech packaging standard. A version 1.3 cartridge can hold web content, QTI assessments and question banks, discussion topics, web links and LTI links. Enrolments and completions are not among its content types.
• Canvas packages a course export as an IMSCC ZIP file (.imscc), and its documentation says that exports leave out student interactions and grades. Grades are exported separately as CSV.
• Moodle writes a course backup with the .mbz extension. Administrators and managers can include users, completion details, logs and grade history, but that is a Moodle-to-Moodle route: the backup FAQ says the target must be the same version or newer, and that passwords are not backed up.
• Moodle and Common Cartridge: the Moodle 5.3 documentation says it imports only versions 1.0 and 1.1 and exports version 1.1 for a short list of activities. Check the cartridge version your source produces.
• Open edX exports a course as a .tar.gz file, and its documentation lists user data, course team data, discussion data and certificates as not exported.

Where a destination offers an importer for another platform's backup file, expect structure and content. Learner history still travels by CSV, API or database.

Certificates, verification URLs and expiry dates

A certificate is three things: a record (who, which course, issue date, expiry date, certificate ID), a document (usually a PDF) and a verification URL that a third party can open. A careless migration issues every certificate again from the new system. The issue date becomes migration day, the ID changes, and the renewal clock restarts for the whole workforce.

• Import the original issue date and expiry date as data, including certificates that have already expired. Lapsed periods matter in an audit too.
• Keep the original certificate ID. If the destination generates its own, store the old ID in an extra field and keep a lookup table.
• Archive the original PDFs. They are what the learner was actually given.
• Keep old verification URLs working, because they are printed on documents and posted on professional profiles. Redirect the old path to the new verification page by certificate ID, or host a simple lookup of archived certificates.
• Check that renewal reminders fire from the imported expiry date. Test with a certificate that expires next month.

Agree with the compliance owner what counts as equivalent evidence before you build anything.

User identity matching and passwords

Every record has to attach to the right person, so choose one identifier that never changes, such as an employee or student number, and use it as the matching key in every file. Email addresses change.

Passwords rarely transfer. A properly built system does not hold them: NIST SP 800-63B requires that passwords are "salted and hashed using a suitable password hashing scheme". The most an export can contain is a hash in the old platform's scheme, which the new platform can use only if it supports the same scheme, and in our experience vendors are often unwilling to export hashes at all. Plan one of two things: single sign-on from day one, so the LMS never holds a password, or a forced reset with a clear email and extra support cover.

With single sign-on, test the first login. If the identifier in the assertion or token does not match the imported account, an LMS that creates accounts at first login makes a second, empty one and the learner's history seems to vanish. Take care if the identity provider is changing too: OpenID Connect says the only stable identifier for a user is the combination of the iss and sub claims, so a new issuer means new values. Match on a directory attribute you control. Our guide to SAML and OIDC single sign-on for an LMS covers the identifier choices.

URLs, deep links and redirects

Every course URL changes. Links to the old system sit in welcome emails, intranet pages, HR systems, QR codes on equipment, certificates and other platforms that launch your courses over LTI. Build a map from each old course URL to its new one and serve permanent redirects from the old domain. That is possible only if you control the domain. If learners used an address on the vendor's domain, the redirects end with the contract, so use your own domain on the new platform from the start.

For public catalogue pages, Google's site move guidance recommends permanent redirects such as 301 and 308, kept for at least a year, and warns against sending many old URLs to one irrelevant page such as the home page. Do not rely on redirects for LTI connections: plan to register each one again and recreate the links in the other platform.

Migration approaches compared

There are four ways to get from the old system to the new one. Real projects often combine two of them.

The fourth option deserves more attention, because moving history nobody will use is cost with no benefit. But "start clean" is never completely clean: at a minimum, user accounts and current certificate expiry dates must arrive, or the new system cannot tell who is due for renewal.

Whichever you choose, write the go and no-go criteria and the way back before the cutover date is announced.

A step-by-step LMS migration plan

This is the sequence we recommend, and the table works as an LMS migration checklist. Each phase has an owner and a test for "done", because a phase that ends when the calendar says so is how unverified data reaches production.

For one source system of moderate size, our own indicative ranges, not a quote, are: audit and decisions one to two weeks, mapping and build one to four weeks, and the trial, reconciliation and acceptance one to three weeks. The freeze, final run and cutover take days. That is roughly three to ten weeks to go-live, with two to four weeks of hypercare after it. Several source systems, long compliance history or a phased rollout stretch all of these.

What a field mapping looks like

Phase 3 decides the quality of everything after it. Here is a hypothetical mapping for completion records, to show the level of detail needed.

Run the phase 5 trial at least twice: the first rehearsal finds the problems and the second proves the fixes. And tell learners early, in plain words, what will not carry over.

How to prove the data arrived: a reconciliation checklist

Validation is a written comparison between two systems, made by someone who did not write the scripts. Agree the tolerance in advance. For compliance completions and certificates it should be zero unexplained differences. A difference with a reason, such as accounts excluded because the person left before the cut-off date, is fine. A difference nobody can explain is a defect.

1. Record counts by entity. Users, courses, enrolments, completions, grades and certificates in source and target, with exclusions listed and counted.
2. Completion totals per course. One row per course, source against target. A system-wide total can hide a course that lost half its records behind another that doubled.
3. Completion dates. Count completions by month in both systems. A spike in the migration month means dates were overwritten.
4. Certificate counts and expiry dates. Totals per course, then expiry dates by month for the next 12 months. Your renewal reminders will run from this list.
5. Learner transcripts side by side. A sample chosen by the business, not by the migration team. Include leavers, people who changed name or unit, and the longest transcripts.
6. SCORM launch tests. For each package, or at least one per authoring tool and version: launch, exit halfway, resume, complete, and confirm status and score are recorded. Then reopen a course with imported history and confirm the record is unchanged.
7. Quiz spot checks. One question of every type, with images, feedback and scoring, and one full quiz attempt.
8. SSO login test. An existing user lands on the migrated account with history visible, no duplicate is created, a deactivated user cannot sign in, and a new starter gets the right role.
9. Report parity. Rebuild the reports managers use and compare the same period in both systems.
10. Links and redirects. Test the mapped URLs and certificate verification links, and crawl course pages for references to the old domain.
11. Integrations. Push one test record through each connection, end to end.

Run the list after the trial migration and again after the final one, and keep the signed report with the archive as your evidence.

Data protection and compliance during a migration

A migration copies personal data to a new supplier, to staging servers and often to engineers' working files. This section is general information, not legal advice. Under the GDPR, these are the points to settle:

• Lawful basis and purpose. Article 6(1) lists the lawful bases, including compliance with a legal obligation and legitimate interests. Moving platforms does not in itself change your basis for holding training records, but check that the purposes are unchanged, because Article 5(1)(b) limits further processing to compatible purposes.
• Data minimisation. Article 5(1)(c) limits personal data to what is necessary, and Article 5(1)(e) says it must not be kept in identifiable form for longer than necessary. A migration is the natural moment to leave behind old activity logs, unused profile fields and accounts past their retention period.
• Records you must keep. Some training records have to be retained under health and safety, financial, healthcare or other sector rules, or under contract. The periods vary by rule and by country, so take them from your compliance owner and write them into the inventory. Article 17(3)(b) recognises that the right to erasure does not apply where processing is needed to comply with a legal obligation under EU or member state law.
• Contracts and exit terms. Article 28(3) requires a contract with each processor, which covers the new vendor and any migration partner. Under its point (g), that contract must have the processor delete or return all personal data, at your choice, when the service ends. Read the contract for the export format, how long data stays retrievable after termination, any export fee and how deletion is confirmed. Take the export before the termination date.
• Security of copies. Article 32 names encryption and pseudonymisation among appropriate measures. Treat staging as production: restricted access, encrypted transfer, no CSV files by email. Delete dumps and working copies after sign-off and record that you did.
• Transfers outside the EU. If the new host or the migration team is outside the EU, the transfer rules that start at Article 44 apply. Using a migration partner based outside the EU is an international transfer too and needs the same safeguards.

If your learners are elsewhere, ask the same questions under your own privacy law. Article 5(2) makes the controller responsible for demonstrating compliance, which is one more reason to keep the reconciliation report and the deletion confirmations.

Choosing the destination and the delivery model

If the destination is still open, choose it with a scorecard and a pilot. Our guide on how to choose an LMS gives the method. From a migration point of view, the delivery model decides which routes are open for loading history.

• SaaS. You load data only through the vendor's import tools and API. Ask whether completions can be imported with their original dates, whether certificate IDs and expiry dates can be set, and what the API rate limits are.
• Self-hosted open source, such as Moodle or Open edX. You have database access, so any history can be loaded in principle, but you own the scripts, the hosting and the upgrades.
• Self-hosted commercial. A licensed product on your own server: vendor support, with your own control of the data.

One option in the third group is LMS Advisor, which is our own product. Its public pages say it runs in the vendor's cloud or on your own PHP and MySQL server, and supports SCORM 1.2 and 2004, xAPI with a built-in learning record store, cmi5 and LTI 1.3 as a tool provider.

For migration it documents direct importers for Moodle .mbz backups and LearnDash courses, which bring course structure. From any other platform, content arrives as SCORM, xAPI or cmi5 packages. Its documentation also says that learner history does not travel inside packages and that historical completion records need a separate export. A REST API covering users, enrolments, progress and certificates is listed, so ask how your historical completions would be loaded.

Its limitations: pricing is quote-based, and it is not a course-selling storefront (there is no built-in checkout, and paid courses are sold through WooCommerce). AICC and H5P are not supported, and it cannot launch other vendors' LTI tools. See LMS Advisor for the detail.

Whatever you choose, add one question to the scorecard: how do we get everything out again? The best time to negotiate export terms is before you sign.

What drives LMS migration cost and timeline

The number of users matters less than people expect. These drive the effort:

• Source access. A documented API or database access is quick. A vendor that offers only report exports is slow.
• History. How many years, how many record types and how exactly they must be reproduced.
• Data quality. Duplicate accounts and inconsistent course codes are fixed either in the source or in the scripts.
• Content volume. Every SCORM package is uploaded and tested, and every course without an importer is rebuilt by hand.
• Integrations and SSO. Each connection is rebuilt and tested.
• Approach. Phased and parallel migrations lower risk but add elapsed time, delta runs and a period of paying for two platforms.

For our own work, the public LMS cost calculator shows a base range of 5,000 to 30,000 USD and 3 to 10 weeks for "Migrate to a different LMS / upgrade". That is an indicative range from our LMS cost calculator, October 2026, not a quote. The platform, learner count and complexity you select scale it, and content volume, integrations and compliance work are separate lines that add to it. The licence for the new platform is separate again.

How we can help

We plan and run LMS migrations between Moodle, WordPress LMS plugins, Open edX, Canvas and proprietary platforms: the inventory, field mapping, import scripts, rehearsals, reconciliation and cutover described above. See our LMS migration services, or talk to an LMS engineer about your inventory before you commit to a cutover date.