Migrating to a New LMS Without Losing Learner Progress

An LMS migration is judged on one morning. Learners log in to the new site, and either they find their courses, their place in them and their certificates, or they do not. Course content can be rebuilt by your team at any time. A completion date from two years ago cannot be recreated once the old system is switched off.

So plan the move around the records, not the content. Below is what can be carried across, how to map it, how to rehearse, and how to run the cutover so that nobody has to redo a course they already passed.

List every record that counts as progress

"Progress" means different things to a learner, a manager and an auditor. Start with an inventory of what the old platform holds and decide, line by line, whether it has to move.

Record	Can it move?	How it usually goes
User accounts and profile fields	Yes	CSV or API import. Passwords are normally reset.
Enrollments, start and expiry dates	Yes	Mapped course to course, keeping the original dates
Lesson and course completions	Yes	Needs a step-by-step map between old and new course structures
Quiz score, pass or fail, date	Usually	Imported as a result summary
Answers to each question	Rarely	Archived as an export for the record
Issued certificates	Yes, with care	Reissued with the original date and number, or stored as files
Assignment uploads and feedback	Yes	Files copied and linked to the user and the step
Resume position inside a SCORM module	No	Only the completion status carries over
Active subscriptions and saved cards	Depends on the payment gateway	Plan this with the gateway, separately from the learning data

Count each line as well: how many users, enrollments, completions and certificates. You will reconcile against those totals later.

Same platform or a different one

If both ends run the same software, use its own tools. A Moodle course backup made by an administrator can include enrollments, grades, completion details and user files, and restores into another Moodle site. LearnDash has an Import/Export screen under LearnDash LMS > Settings > Advanced that carries courses, quizzes, user data and progress, groups and certificates between LearnDash sites. Its documentation recommends practicing the transfer on a development site first, which holds for every route here.

Between different platforms there is no such file. Moving from a hosted course platform to WordPress, from LearnDash to Moodle or the other way means three separate jobs: get the data out (exports, the API, or the database if you have access), convert it to the new structure, and write it in through the new system's own functions. Most of the effort is in the middle step.

Build the mapping before any import

Users

Pick one key that identifies a person on both sides. Unless both systems hold an employee or member number, it is the email address. Clean it first: find duplicates, shared addresses and accounts with no email. Store the old system's user ID on the new account in a profile field, so that any record can be traced back later.

Passwords are stored as hashes in a format specific to each platform. Unless the new system can verify the old format, learners set a new password on first login. Tell them in advance, and send the reset email from a sender address they recognize.

Courses and steps

Make a spreadsheet with one row per lesson, topic, quiz and assignment in the old system and the ID of its counterpart in the new one. It is tedious, and it is the heart of the project. Where the new course is structured differently, write the rule down: "old lessons 4 and 5 were merged, so the new lesson 4 is complete if both were complete".

Statuses and dates

List the states the old system uses (not started, in progress, completed, passed, failed, expired) and their equivalents. Carry the original timestamps. A completion imported with the date of the migration is wrong in every report that follows, and it breaks any certificate that expires a fixed time after completion.

Write through the LMS, not into its tables

It is tempting to insert rows straight into the new database. Do not. An LMS updates several places when a step is completed: progress, activity records, course access, sometimes gradebook totals. A direct insert updates one of them.

Use what the platform provides. In Moodle, accounts, cohorts and enrollments can be loaded with the Upload users CSV tool, and completions and grades through web service functions or a script that uses Moodle's own completion and grade classes. In LearnDash, functions such as ld_update_course_access() and learndash_process_mark_complete() enroll a user and complete a step the way the interface would. Switch off outgoing email while the import runs, or every historical completion sends a "congratulations" message.

Make the import safe to run twice. If it is keyed on user, course and step, a second run changes nothing that is already correct. You will need that property at cutover.

Run a full dry run and reconcile it

Import everything into a staging copy of the new site. Then compare totals with the inventory: users, enrollments per course, completions per course, certificates. The numbers should match, and each difference should have a written explanation.

Totals hide individual errors, so check people too. Choose twenty or so real learners who cover the awkward cases: finished long ago, halfway through, failed and retook a quiz, access expired, member of a group, changed their email. Compare their old and new records side by side. Then ask a few learners and one manager to log in to staging and say what looks wrong.

Cutover for an LMS migration, step by step

1. Announce the date and what learners will need to do, at least a week ahead.
2. Put the old platform in a read-only or maintenance state so no new progress is recorded.
3. Take the final export and run the import again. Because it is safe to repeat, it only adds what changed since the dry run.
4. Reconcile the totals once more and recheck your sample learners.
5. Switch the domain or the links, turn email back on, and send the welcome message with login instructions.
6. Keep the old system online and read-only, for staff, until the first reporting cycle has passed without a dispute.

Choose a quiet period, never the week before a certification deadline.

Redirects, bookmarks and old emails

Learners have years of emails that link to the old course addresses. Map old course and lesson URLs to the new ones with permanent redirects, and send the old login address to the new login page. Certificate verification links matter most: an employer who checks a certificate next year should still land on a page that confirms it. If the address pattern changes, keep a lookup from old certificate IDs to new ones. For the search side of the move, follow our website migration SEO checklist.

What will not move, and what to do instead

• Detailed quiz attempts. Question types and IDs differ between platforms. Import the result, and keep the full attempts as a dated export in your records archive.
• Attempts in flight. A half-finished quiz or SCORM module restarts. Warn learners to finish open assessments before the freeze.
• Time-spent and activity logs. Export them for the archive.
• Video held by the old platform. Download the original files early.
• Recurring payments. Whether subscriptions can continue depends on the gateway and how cards were stored. Our guide to migrating a membership site covers the options.

How much of this to do in-house

A move between two sites on the same platform, with a few hundred learners and the vendor's own export tool, is manageable for a careful administrator who rehearses it. A move between different platforms is a data project: export scripts, a mapping that someone has to own, an import that respects the new system's logic, and a reconciliation report. That is where a team that has done it before avoids the quiet errors that surface months later in an audit.

We migrate learning sites in both directions: onto WordPress LMS plugins from hosted platforms and older custom systems, and through our Moodle migration work between Moodle sites and other platforms. If the old system is one nobody maintains anymore, our migration and modernization team can start from the database alone.

Frequently asked questions

Will learners need a new password after the migration?

In most cross-platform moves, yes. Passwords are stored as one-way hashes in a platform-specific format, so they cannot be converted. The usual answers are a reset email at launch or single sign-on, which removes the LMS password from the picture.

How long should the old LMS stay online?

Keep it read-only until records have been reconciled and at least one reporting or billing cycle has passed. Before you cancel it, take a complete export of data and files and store it under your record retention rules. Once a hosted account is closed, the data is usually gone.

Can we migrate one course at a time?

You can, and it lowers the risk for each step. The cost is a period in which learners have two logins and reports come from two systems. It works best when the split follows groups of people, such as one department or one cohort at a time.

What if the old platform gives us no database access?

Then the export tools and the API set the limits. Ask the vendor early for a full data export and a list of what it contains, and check your contract for data portability terms. Anything the platform cannot export has to be captured another way before the account closes.