Migrating a Course Library to a New LMS in the UAE

On the first Monday after a UAE company moves its course library to a new LMS software, three messages reach the learning team before noon. An employee in Abu Dhabi finished the Arabic version of a mandatory course, but it still shows as incomplete. A supervisor in Dubai says the induction module restarts from the first screen every time his team opens it on their phones. And the compliance manager asks for a policy update to a course whose source files, it turns out, stayed with the agency that built it four years ago.

None of these problems is unusual, and none is solved by a bulk upload. A course library is a collection of packages built at different times, in different formats and languages, by different people, under different agreements. Moving it safely means knowing what each package is, proving that it behaves the same way in the new LMS software, and confirming that you can still change it afterwards.

This article sets out work for HR, IT and procurement teams in the UAE moving to new LMS software, in four parts: a package inventory, results matching, course resume testing and a source-file rights check. It deals with course content only; moving learner records and agreeing exit terms with a provider are separate tasks.

Start with a Package Inventory

Before anything moves into the new LMS software, list every item in the course library in one sheet. For each course, record:

• The title in Arabic and English, and whether the language versions are separate packages or one course.

• The package type: a SCORM package, an xAPI or cmi5 package, a video, a document, an external link, or a course built inside the old LMS software’s own editor.

• The owner, the date of the last update, and how many employees opened it in the past year.

• Whether it is mandatory, and whether it issues a certificate or feeds a renewal cycle.

• Where the source files are, and what rights the organization holds over them.

The package type matters because it tells you how the course talks to the learning management system and therefore what to test. Content packages follow standards that describe that conversation. The cmi5 specification, for example, is described by its authors as a profile for using xAPI with traditional learning management systems, and its scope covers how an LMS launches course units, the runtime communication between them, course structure import and export, and reporting. The xAPI specification itself describes communication about learner activity and experiences between technologies.

Then decide what happens to each item: move it as it is, repackage it, rebuild it, or retire it. Courses nobody has opened in a year are good candidates for retirement, and courses built in the old LMS software’s own editor often need the most attention, because they may not exist anywhere as a portable package. Every course you retire is one less to migrate, test, and maintain in the new LMS software.

Libraries also collect duplicates: the 2021 and 2023 versions of the same course, or an Arabic copy uploaded twice under different titles.

Keep one current version of each course in the new LMS software, archive the rest outside it, and note in the inventory which old versions historical completions refer to, so the records migration can still link to them.

Matching Results Between Old and New LMS Software

A package that launches is not necessarily a package that works. Two LMS software products can read the same package and record a different outcome: one may mark a course complete when the learner reaches the last screen, while another waits for a passing score; one may honor the pass mark set inside the package, while another applies its own setting.

For each package type, and for a sample of the most important courses, define what the result should be and test it in both the old and the new LMS software with the same attempt:

• Completion status: when should the course count as complete?

• Pass or fail: is there a pass mark, and where is it set?

• Score: is it recorded, and as a percentage or as points?

• Certificate: is it issued, with the right name in Arabic and English?

Check the reports as well. A course that records results correctly may still appear under a different category or language label in the new LMS software, which quietly breaks the compliance reports managers already rely on.

Bilingual courses need one extra check. If the Arabic and English versions of a course are separate packages, make sure that the new LMS software treats completing either one as satisfying the assignment, so employees are not chased for the version they did not take. Organizations that run training across several group companies face this at a larger scale; our article on managing bilingual teams across companies looks at that setup in the UAE.

Testing Course Resume in the New LMS Software

Resume is where courses moved to new LMS software most often disappoint learners. Test it deliberately on the courses that matter most and on the longest ones: start a course, leave halfway by closing the browser, return on a different device, and check that the learner lands in the right place with earlier answers kept. Repeat the test on a phone over a mobile connection, because many frontline employees in hospitality, retail, and logistics will use nothing else. Our guide to testing course resume and results describes the full test in more detail.

Migration adds a problem that a normal resume test does not cover: learners who are halfway through a course on cutover day. Their progress usually lives in the old LMS software and may not travel with the package. Decide in advance what happens to these in-progress learners. You might set a deadline for finishing in-progress courses before the switch, accept that they restart, or give manual credit for courses that were nearly finished. Tell employees which option applies before the switch to the new LMS software, not after.

Source-File Rights: Can You Still Change What You Move?

A published package lets you run a course. The source files let you change it: the authoring project files, video masters, voice-over recordings, translation files and images. When a regulation, product or procedure changes, a course without source files can only be replaced, not updated.

For each course in the inventory, record whether you hold the source files and whether you have the right to edit and reuse them on new LMS software. Pay particular attention to:

• Courses built by an external agency, where the agreement may or may not cover source files.

• Library content licensed with the old learning management software, which may not be transferable at all.

• Third-party assets inside your own courses, such as stock images, music and fonts, including Arabic fonts, whose licences may be tied to a project or platform.

Where rights are unclear, ask your legal or procurement team rather than assuming. Unclear courses can often keep running in the LMS software as published packages while the question is settled, but mark them so nobody plans an urgent update that cannot legally be made.

Moving the Library in Waves

Do not move the whole library into the LMS software at once. Start with a pilot wave of about ten courses that together cover every package type and both languages, run the results and resume tests, and fix what fails. Then move the remaining courses in migration waves grouped by owner or business unit, with each content owner signing off on their courses in the new LMS software before employees are assigned to them.

Coordinate the waves with the move of learner records, so that historical completions link to the right courses in the new LMS software; our guide to migrating training records to a new LMS covers that side of the project.

A Hypothetical Example: A Hospitality Group in Dubai and Abu Dhabi

The following example is hypothetical and only illustrates the method.

A hospitality group with hotels in Dubai and Abu Dhabi is moving 140 courses, most in Arabic and English, to new LMS software. The inventory shows that 30 courses have not been opened in a year; they are retired. Twelve were built in the old LMS software’s editor and are rebuilt as packages.

The pilot wave reveals two results problems: several compliance courses in the new LMS software mark completion only on a pass, unlike the old system, and the Arabic versions of eight courses record completion but not a score. The resume test fails on phones for two long video-based modules, which the team splits into shorter units. Finally, the source files for fifteen courses sit with a former agency and the rights are unclear. Those courses keep running as published packages while the legal team clarifies the agreement, and the most-used five are scheduled for rebuilding.

Summary

A course library moves safely when every package is known, tested, and still editable. The inventory tells you what you have and what to retire, results matching proves that courses record the same outcome in the new LMS software, and resume testing, including a plan for learners in progress at cutover, protects the learner experience.

Check source-file and asset rights before you rely on updating a course, move the library in waves with owner sign-off, and coordinate with the move of learner records into the same LMS software. The result is a library that works on day one and can still change when your business does.

Click here. If you are preparing to move a course library to new LMS software, you can talk through your inventory and testing plan with the SkillUp MENA team.