Migrating Training Records to a New LMS in Saudi Arabia

Two weeks after a Saudi company switches to new LMS software, a site manager in Dammam opens his team report and finds that half of his technicians appear never to have completed fire safety training. They did complete it, some of them three times. The old system stored each year’s session under a different course code, and the migration matched none of them to the course in the new platform. Renewal reminders are now going out to people whose certificates are still valid, and nobody can say which certificates have actually expired.

Problems like this rarely come from the import tool. They come from treating migration as a file transfer rather than a matching exercise. Training records only mean something together with their context: who the person is, which course and version they completed, when, with what result, and on what authority a certificate was issued.

This article sets out a practical method for HR, IT and procurement teams in Saudi organizations moving training history into new LMS software: a record-matching plan, a trial import with reconciliation, and specific steps to preserve accreditation records. It focuses on learner records; moving course content is a separate project.

Why Training Records Lose Meaning When LMS Software Changes

Every learning management system organizes data in its own way. One may treat each annual session as a separate course; another may expect a single course with several versions. One may store a score as a percentage; another as points. When records move between LMS software products built on different assumptions, the data can arrive intact while its meaning is lost.

Records management guidance makes the same point. The UK National Archives’ guidance on transferring digital records warns that migrating information from one data structure and application to another can increase the risk of losing its content and context, and the ability to access it. It advises agreeing on minimum mandatory metadata before migrating and mapping metadata fields against each other, and it says no digital information should be destroyed until it has been loaded successfully into the new environment and quality-checked. Those three principles shape the steps below.

Step 1: Build a Record-Matching Plan

Start with an inventory of where training history lives today: the old LMS software, spreadsheets kept by sites or departments, attendance sheets from classroom sessions, and certificates issued by external providers. Then decide what will actually move into the new LMS software. Not every field needs to travel. Saudi Arabia’s Personal Data Protection Law Implementing Regulation requires controllers to collect and retain only the minimum personal data necessary for the purpose. Treat the field list as a data minimization decision: agree with your data protection officer which fields the new LMS software genuinely needs, and leave the rest in a controlled archive.

Next, build a mapping table for each type of key that links one record to another:

• People: use the employee number as the matching key, not the name. Arabic names are often spelled differently across systems, and the same person may have two accounts in the old LMS software after a transfer or rehire.

• Courses: map every old course code to a course and version in the new LMS software, including retired and renamed courses.

• Statuses: decide how ‘attended’, ‘passed’, ‘completed’, ‘exempt’ and ‘in progress’ translate, because two LMS software products rarely use the same list.

• Dates: confirm the calendar and format of every date field. Older spreadsheets may hold Hijri dates, and a date read in the wrong calendar shifts every expiry it touches.

• Results: agree how scores convert, and whether attempt history moves or only the final result.

Each table needs an owner who signs it off: HR for people, the training team for courses and statuses, and the health and safety or compliance function for anything tied to a certificate. If employee data in the new LMS software comes from your HR system, align the matching key with that connection; our guide to connecting an LMS to HR systems in Saudi Arabia covers that link.

Some records will not match anything: a course code nobody recognizes, or an employee number that no longer exists. Do not force them into the new LMS software. Put them on an exceptions list with the source file and the reason, decide each case with the record owner, and keep the list with the migration documents. A short, explained exceptions list is a sign of a careful migration; an empty one usually means the problems were hidden.

Step 2: Run a Trial Import Before the Real One

A trial import loads a small, deliberately difficult sample into a test environment of the new LMS software. Choose one or two departments or sites, and make sure the sample includes the cases most likely to break:

• Employees who transferred between sites or were rehired.

• Courses that changed code or version over the years.

• Expired, valid, and soon-to-expire certificates.

• External training recorded with an uploaded certificate.

• Classroom attendance taken from spreadsheets rather than the old system.

Then reconcile the result. Compare record counts by course and year between the old and new LMS software. Pick about twenty employees and trace each one’s full history from source to destination. Open their certificates and reports in Arabic and in English. Finally, check how the assignment rules in the new LMS software react to imported history: an employee who completed a course last month should not be assigned it again on the first day of go-live.

Set pass criteria before the trial, such as an exact match on counts and no unexplained differences in the traced histories, and repeat the trial after every mapping fix until it passes. Let the LMS software provider run the import if that is part of the agreement, but keep the reconciliation in your own team’s hands: the people who know the records are the ones who will notice that a name, a date, or a course looks wrong. If you are still choosing LMS software, ask for a trial import on your own sample as part of a practical demo test before contracting; it reveals more than a demonstration with prepared data.

Step 3: Preserve Accreditation Records in the New LMS Software

Some training records carry weight outside the organization: certificates required by clients on projects, professional development hours that count towards a license, or courses delivered by an approved external provider. For these accreditation records, a completion flag in the LMS software is not enough. Make sure each one keeps:

• The issuing body or provider, and any approval or accreditation number shown on the certificate.

• The original issue date and the expiry or validity date.

• Accredited hours or credits, where they apply.

• The certificate number and the original certificate file.

Do not let the new LMS software generate fresh certificates for historical completions. A certificate dated on migration day misrepresents when the training took place, and may contradict the copy the employee already holds. Import the original file and dates instead, and test that renewal assignments are calculated from the original expiry date rather than the import date.

Cutover: Going Live on the New LMS Software

When the trial passes, plan the cutover. Agree a date after which nothing new is recorded in the old LMS software, run the full import, then import the small set of records created between the final extract and go-live. Keep the reconciliation report, signed by each mapping owner, with the project documents.

Keep a read-only copy or full export of the old LMS software until the new records have been verified, in line with the principle of not destroying anything before it has been loaded and checked. How long that archive is then retained is a decision for your data protection officer. Tell employees how to report a missing or incorrect record during the first months. Course content follows its own path, covered in our guide to migrating a course library to a new LMS.

A Hypothetical Example: A Facilities Management Company

The following example is hypothetical and only illustrates the method.

A facilities management company with sites in Riyadh, Jeddah, and Dammam is moving six years of training history into new LMS software. Its first trial import uses the Jeddah site and the head office HR team.

The reconciliation finds three problems. Fire safety training appears under four old course codes, which the team maps to one course with dated versions. Classroom records from one site’s spreadsheet hold Hijri dates that were read as Gregorian, moving several expiry dates by years. And certificates from an external first aid provider arrive without their files or approval numbers.

The team fixes the mappings, converts the dates with the source calendar confirmed, and adds certificate files and numbers to the import. The second trial passes, the third covers all sites, and cutover follows a week later, with the old LMS software kept read-only for verification. In the first month, employees report a handful of missing external certificates, which are added from the archive.

Summary

Migrating training records to new LMS software is a matching exercise before it is a technical one. A plan that maps people, courses, statuses, dates and results, with an owner for each table, prevents most of the problems that otherwise appear after go-live.

Prove the plan with a trial import of difficult cases, reconcile counts and individual histories, and protect accreditation records by keeping their original dates, numbers, and files. Keep the old LMS software data until the new records are verified, and the move will preserve the training history your organization has built.

Click here. If you are planning to move training records into new LMS software and want a second view on your matching plan, the SkillUp MENA team is happy to discuss it with you.