How do you migrate an LMS without losing completion dates?

Why do completion dates get reset during a migration?

Because the import path is often the same code path as a new completion. A learner finishing a course today and a record arriving from a CSV today look identical to a system that only stamps the current time. The date field is written by the receiving system rather than read from the file.

The damage is not visible on the day of the migration. It appears months later, when a certificate that should have expired is still valid, or when an auditor asks for evidence of training that the system now says happened last spring.

What should you export from the old system?

Four things, at minimum. Users, with the identifier you will match on. Enrollments, so you know who was assigned what. Completions, carrying the original completion timestamp. Certificates, including issue and expiry dates where the old system tracked them.

Ask the outgoing vendor for the export before you give notice. Export tooling has a way of becoming less available once a contract is ending. Ask specifically whether the completion export includes the original date or the export date, and get the answer in writing.

What else can change a completion date during a migration?

The import stamp is the obvious failure. Four quieter ones change dates while the import looks clean.

1. Day and month swapped. A date written 03/04/2025 is 3 April in one locale and 4 March in another. In a bilingual workplace, both conventions can sit in the same file. Export and import as YYYY-MM-DD, the ISO 8601 order, which has only one reading.
2. A date shifted by a day. A date with no time zone is often read as midnight. Converting midnight from one zone to another can move it into the previous day. Export with a time zone, or in UTC, and check a few records on both sides.
3. Records on the wrong person. If learners are matched by name or by an email that changed, two people can merge or one can split. Match on a stable ID, and map old IDs to new ones before the import.
4. Expiry recalculated from the import. Even when the completion date survives, some systems compute the next due date from the day the record arrived. Check expiries separately from completions.

How do you verify the migration afterwards?

Reconcile counts first. Total users, total completions, and completions per course should match the source export exactly. A difference of a few records is not rounding, it is a bug.

Then spot-check the extremes. Pull the ten oldest completions and confirm the dates survived. Pull anything with an expiry and confirm the expiry recalculated from the original date rather than the import date. Test the property rather than taking it on trust, whichever system you are moving to.

Keep the old system read-only until those checks pass, and keep the raw export files where nobody can edit them. If a date is questioned later, the original export is the evidence of what the old system said.

How does EmbayLMS handle this?

EmbayLMS imports users, enrollments and completions through its Switcher Program with the original completion dates preserved, so recertification cycles continue from when the training actually happened. Certificates carry their own issue and expiry dates. Learning data is stored at rest in Canada.

The verification steps above still apply. A vendor claiming date preservation, this one included, is making a claim you should test against your own export before you decommission the old system.

This page explains a general migration practice. It is not legal advice, and it does not state what any particular obligation requires of your organization. Consult a lawyer about your own obligations before you rely on it.