Migrating from Learning Locker: A Full Guide

What a migration involves

Learning Locker stores your learning history in a MongoDB database. Moving to Sereni LRS means copying that history across, pointing your source systems at the new endpoint, and confirming your reports still say the same thing.

It runs as seven steps. Your team supplies access to the source database and decides the cutover window; we handle the export, conversion and import. A single LRS with a few million statements is usually a day of work spread over a week of checking. Nothing is deleted from Learning Locker at any point, so the whole process is reversible until you decide otherwise.

What moves, and what does not

Statements are standard xAPI, so they move across unchanged — including their original identifiers and timestamps. What differs is the structure around them, and Learning Locker's own internal bookkeeping does not travel.

Before you start

Have these ready before the first step. Each one blocks the migration if it appears late.

• Read access to the Learning Locker database, ideally to a replica or a restored backup rather than the live server.
• Confirmation of which Learning Locker version you are on. Version 2 is the common case; version 1 stores data differently and needs an extra conversion step.
• A list of the LRSs you want to move, and which of them are still receiving data.
• A list of the systems that send statements — LMS, authoring tools, mobile apps, anything with credentials — because each one needs pointing at the new endpoint.
• A named owner for reporting sign-off. Somebody has to confirm the numbers match, and it is faster to agree who before rather than during.

Step 1 — Take an inventory

Before anything moves, we record what exists: how many statements each LRS holds, how many of them are voided, and the date range they span. These numbers become the checklist you sign off against at the end.

This is also where surprises surface — an LRS nobody remembered, a test environment full of junk data you would rather not carry over, or a gap in the history that predates the migration and would otherwise get blamed on it.

Step 2 — Prepare the destination

We create a Space to match your Learning Locker organisation, then a Store for each LRS you are moving. Access keys are issued per Store, so each source system ends up with its own credentials and can be revoked independently later.

Nothing has been copied yet at this point. If you want to change your structure — splitting one busy LRS into separate Stores for production and testing, say — this is the moment to decide, not after the data has landed.

Step 3 — Export the history

The export runs against your Learning Locker database in date-ranged chunks, oldest first, reading from a replica or a snapshot so live traffic is unaffected.

Chunking matters for a practical reason: if something interrupts a large export, only the chunk in progress has to be repeated. Oldest-first matters because voided statements have to arrive after the statements they void, or the link between them cannot be rebuilt.

Step 4 — Convert the data

Learning Locker changes some characters when it saves a statement, because MongoDB does not allow certain characters in field names. Anything custom your organisation records — the extension fields where scores, departments, course codes and similar business data live — comes out of the database in that altered form.

The conversion step puts it back. This is the most common way a self-run migration goes wrong: the import succeeds, the statement count matches exactly, and months later somebody notices a report that filters on a custom field returns nothing. The data is there, the field names are subtly wrong, and nothing flagged it. Our conversion checks for this explicitly and fails loudly rather than quietly.

Step 5 — Import in order

Converted history is loaded in batches, in the same oldest-first order it was exported. Each batch reports how many statements it wrote, and those counts are logged as the import runs.

Two properties make this safe to run against production. Loading the same batch twice cannot create duplicates, because statements are matched on their original identifier — so an import interrupted halfway is resumed, not restarted. And because the counts are reported per batch, a problem is visible within the first minutes rather than at the end of a long run.

Step 6 — Verify

Volume alone is not proof. These are the checks we run with you before anything is switched over, each one against a number recorded in step 1.

• Total statements per Store match the source count for the LRS it came from.
• The number of voided statements matches, and a sample of them still shows what voided them.
• A handful of individual learner transcripts read identically on both systems — same activities, same results, same dates.
• Custom extension fields are readable and filterable, confirming the conversion did its job.
• The oldest and newest statements match the date range from the inventory, which catches a chunk that silently failed to load.
• At least one of your existing reports is rebuilt and produces the same totals as Learning Locker.

Step 7 — Run in parallel, then cut over

Source systems are pointed at Sereni LRS while Learning Locker keeps running and keeps receiving. For that period both systems hold the same new data, so a problem discovered on day one is a configuration change rather than a restore.

Once your reporting owner confirms parity for a full reporting cycle — a month, for most organisations — statements stop flowing to Learning Locker. Keep it readable for as long as your retention policy requires, then decommission it.

Two things worth planning for

Neither is difficult, but both are easier to handle now than to discover during the cutover.

• File attachments. If your statements reference uploaded files, those files live outside the statement database and are moved separately. Tell us early if you use them, because it changes the sequence.
• Credentials. Every system that sends statements needs its new key deployed. If some of those systems belong to vendors or other teams, their lead time — not the data — is usually what sets the migration date.

Getting help with it

We run the export, conversion and import as part of onboarding, including the verification pass and a written reconciliation against your inventory numbers. Your team supplies access and owns the sign-off.

If you would rather run it yourself, the endpoints and their behaviour are in the documentation, and we can review your plan before you start.