Migrating between LMSs: what can be transferred and where are the limitations
When selecting a new LMS, you’ll often hear the reassuring phrase: ‘We’ll transfer your data, of course.’ However, until you know exactly which data, in what format and with what interdependencies, this is more the start of a discussion than a finished migration plan. This is because every system describes users, courses and results in a slightly different way.
We have already discussed export openness in the context of vendor lock-in. This time, we will focus on the other side of the transfer: what the new LMS can actually do with the exported information. A file that can be downloaded is not necessarily a file that can be fully imported.
Start with the difference between content and history
A course represents one part of the migration. The history of who completed it, how they did so and with what results is a separate layer. Transferring a video or a SCORM package therefore does not automatically transfer students’ previous attempts, comments or certificates.
It is worth creating an overview of several groups: users and organisational structure, the content itself, course enrolments, results, certificates and operational records. For each group, ask both suppliers to confirm the export format and import options. This will enable you to identify in good time which parts of the transfer will be standard and which will require data modification.
Accounts require reliable identity linking
First name and surname are usually insufficient as unique identifiers. There may be people with the same name within a company, people may change their surname, and email addresses may not remain the same throughout. The new system needs to recognise which historical results belong to which account.
Ask whether users are linked via an employee number, an identity from the HR system, or some other stable identifier. Deactivated accounts, external contractors and people with multiple employment relationships are also important. An error in mapping may result in the number of imported rows matching, but their content being displayed to the wrong people.
A standard package is not a backup of the entire LMS
SCORM can facilitate the transfer of a learning package between compatible platforms. However, native tests, discussions, assignments and specific modules may require a different approach. It is also necessary to verify the supported version and behaviour of the package itself in the target player.
A course backup is usually tied to a specific platform. The Moodle documentation, for example, distinguishes whether a backup also includes users and their results. However, it cannot be assumed that any other LMS will be able to read the same backup. If the course uses extensions, it must be clear in advance how the new environment will replace their functionality.
Learning outcomes take many forms
A ‘completed’ record may seem straightforward. In the original system, however, it may have been the result of a combination of a test, attendance at a workshop and confirmation from a tutor. The target platform may evaluate the same completion status according to different criteria. It is therefore important to preserve the meaning of the imported information.
Distinguish at least between the completion date, the score achieved, the validity period and the origin of the record. Ask whether historical data will be recorded as an imported completion or as a new attempt on the course. This is a significant difference for auditing and future reports. Overwriting an old result with a new attempt may create a misleading impression of how the course was completed.
In-progress study is often the most complex part
Picking up where you left off in the middle of a lesson depends on how the course and the LMS store the current progress. Sometimes the necessary information can be transferred; at other times, the new system does not support the same structure or identification of activities. Even support for the same standard does not in itself guarantee the transfer of all in-progress sessions.
Ask for a demonstration of this capability using a specific example. A model student has completed two modules, has one module in progress, and has failed one test. After import, it must be clear what has been retained and what will start afresh. If it is more advantageous to allow completion in the old environment, this decision should be included in the migration plan.
Check certificates and attachments separately
A record that someone has obtained a certificate is not the same as the original document issued. During the migration, you may need both: structured data for searching purposes and the original file to verify its exact wording.
Check the link to the participant, the issuing organisation, the date, the version and the validity. Similarly, enquire about task attachments or proof of attendance. A record of a file’s existence without the file itself is incomplete. Furthermore, in the case of public certificate verification, consider what will happen to the original verification links.
The pilot must verify the meaning of the data
The number of imported rows is an important check, but it does not reveal everything. In the pilot, select different types of users and study scenarios. Check their view, the manager’s view and the report output. Pay attention to time zones, duplicates and integration with new systems.
Before the live migration, the following should be clear:
- Which data will the new system take over, and in what format?
- Which records will remain in a separate archive?
- What will happen to courses in progress and the validity of certificates?
- How will the verification process take place, and who will confirm acceptance of the results?
Migration capability is part of the evaluation of the new platform
You do not need to transfer everything to the same screen on the new LMS. Sometimes it makes more sense to retain a searchable archive and only put the necessary data into operation. However, the decision should be based on your record-keeping and operational needs, not on what is easiest for the supplier to import.
In the LMS Catalogue, you can compare the basic features of the platforms. When making a specific choice, ask for a migration demonstration. This usually reveals more about actual portability than general assurances in the proposal.
