Migrating a learning platform without losing a student

Replacing a learning management system is rarely difficult because of the new platform. It is difficult because of the old one: years of accounts created by hand, courses copied and recopied, grades entered under deadline pressure, and data stored in formats nobody has examined since the system was installed. The measure of a successful migration is simple to state and hard to achieve. On the first morning after cut-over, every student can sign in with the password they already know, sees the courses they are enrolled in, and finds their progress exactly where they left it.

Start with an inventory, not a timetable

Agree who owns the migration on the institutional side before any technical work begins. That is usually the registrar or an academic systems lead, supported by IT, and they must be able to make decisions about what data matters. Before agreeing a go-live date, extract a full copy of the legacy database and profile it. Count users, courses, enrolments, submissions, grades and files. Identify which tables the old application actually reads and which are leftovers from abandoned modules. Note every place where the same fact is stored twice, because those are the places where the two copies will disagree. The inventory becomes the reconciliation baseline: every number you record now is a number you will check again after each rehearsal.

Preserve passwords by verifying, not resetting

Forcing every user to reset their password on day one is the single most reliable way to flood a help desk and lose the goodwill of students who have no reliable email access. It is also usually unnecessary. Legacy systems store a hash of each password, and most use a documented scheme: a salted cryptographic hash, a key-derivation function such as bcrypt, or an older unsalted digest. Identify the exact format from the stored values and the old source code, then implement a verifier for it in the new platform.

• Import the legacy hash unchanged, tagged with its algorithm, rather than attempting to convert it.
• On sign-in, verify the password against the legacy scheme; if it matches, immediately rehash it with the new platform’s modern algorithm and discard the old value.
• Treat weak legacy schemes, such as unsalted fast digests, as a risk to retire: set a deadline after which accounts that have not signed in must reset.
• Test the verifier against known accounts created specifically for the purpose, never by collecting real users’ passwords.

Repair character encoding before anything else

Names, course titles and forum posts in older systems are frequently stored in a mixture of encodings, or worse, double-encoded: text saved as UTF-8, read as a single-byte encoding, and saved again. The result is the familiar scramble of accented and non-Latin characters. Somali, Arabic and English text can all appear in the same table. Detect the pattern systematically by sampling rows with non-ASCII bytes, write a deterministic repair function, and run it on a copy before import. Keep the original bytes in a staging column so that any repair can be audited and reversed.

De-duplicate accounts and carry progress

Legacy platforms often contain people with more than one account: one created at admission, another by a lecturer who could not find the first, a third after a forgotten password. Merging them is valuable, but merging the wrong two people is far worse than leaving duplicates in place. Match on stable identifiers such as the student number from the registry first, then propose fuzzy matches on name and date of birth for human review. Never merge automatically on name alone. Record every merge in a log that maps old identifiers to the surviving one, so that grades and submissions follow the person. Students care less about their profile picture than about whether the system remembers that they completed the first half of a module. Map enrolments, completion records, quiz attempts, grades and submitted files explicitly, and decide in writing what will not be migrated, such as old session logs or abandoned draft courses. Where the new platform models something differently, for example a different grading scale, convert with a documented rule and keep the original value alongside it.

A migration is only as good as the reconciliation that proves it, and a reconciliation is only as good as the baseline taken before anything moved.

Rehearse until the cut-over is boring

Run the full migration end to end against a fresh copy of production at least twice before the real event, and time each run. Each rehearsal should finish with the same reconciliation: counts by entity, spot checks of individual students chosen at random, sign-in tests with prepared accounts, and a review by registry staff who know what the data should look like. Fix the script, never the output, so that each rehearsal is reproducible. Rehearsals also expose the slow steps: file storage in particular can take far longer to copy than the database, and is often better moved in advance with a final incremental sync during the cut-over window. Invite a small group of staff and students to use a rehearsed copy for a few days and report anything that looks wrong; they will notice things no script checks for, such as a course appearing under the wrong department.

Cut-over and rollback

• Choose a window away from examinations, assignment deadlines and registration periods, and announce it early through every channel students actually read.
• Freeze the legacy system to read-only before the final extract, so no work is created that the migration cannot see.
• Define go and no-go criteria in advance: which reconciliation checks must pass, and who has authority to decide.
• Keep the legacy system intact and restorable for an agreed period, with DNS or proxy changes that can be reversed quickly.
• Staff a help desk for the first days with scripts for the questions you expect: sign-in, missing courses and missing grades.

Rollback should be a rehearsed procedure, not an aspiration. If the go criteria are not met, the decision to stay on the old system should be quick and blameless. A delayed migration is an inconvenience; a broken one costs students work they cannot recover and costs the institution trust that takes years to rebuild. After the support period, decommission the old platform properly: archive what records policy requires, then securely destroy the rest.