Migrating from Yet Analytics SQL LRS

Why this one is easier than most

Yet Analytics SQL LRS is a fully conformant Learning Record Store, which changes the shape of the migration entirely. There is no database export, no schema mapping and no conversion step: statements, attachments and documents all come out through the same standard xAPI interface they went in through.

That has two practical consequences. Nobody needs credentials to your database — a read credential on the LRS itself is enough. And because reading does not disturb writing, the transfer can run against a live system, at whatever pace suits you, without a maintenance window.

It also means the backend you chose does not matter. SQLite, Postgres, MySQL or MariaDB all present the same interface, so the same process applies to all of them.

What moves, and what does not

Everything the specification covers transfers. What stays behind is the configuration around it — the parts that are specific to how SQL LRS is operated rather than to your learning data.

Before you start

Short list, because the API does most of the work.

• The URL of your SQL LRS, reachable from wherever the transfer will run.
• A credential pair with read access to statements. Nothing in this process writes to SQL LRS.
• Your current statement count, which SQL LRS reports on its own status endpoint and shows in the admin console.
• Whether you use attachments, and roughly how much space they occupy — it changes how long the transfer takes more than the statement count does.
• Whether Reactions is enabled, and if so what the active rules do. These need rebuilding before cutover, not after.
• A list of the systems that send statements, since each needs new credentials at the end.

Step 1 — Take an inventory

Record the statement count, the date of the oldest and newest statement, and whether documents and attachments are in use. These are the numbers you will sign off against, and gathering them takes minutes.

This is also the moment to decide what not to bring. A long-running LRS often holds test data from its first weeks, or statements from a pilot that never went anywhere. Migrating is a reasonable opportunity to leave those behind, but it has to be a decision rather than an accident — otherwise the counts will not reconcile at the end and nobody will know why.

Step 2 — Prepare the destination

We create a Space for your organisation and a Store to receive the data — one Store per SQL LRS deployment. Access keys are issued per Store, so each system that sends statements ends up with its own credentials.

If you have been running separate SQL LRS instances for production and staging, they become separate Stores in the same Space, which keeps the separation you already have while putting both under one set of dashboards.

Step 3 — Transfer the statements

Statements are read from SQL LRS oldest first, in pages, and written to the destination Store in the same order. Order matters for one reason: a voiding statement has to arrive after the statement it voids, or the link between them cannot be rebuilt.

One detail specific to SQL LRS is worth knowing, because it can quietly change your data in transit. SQL LRS supports both xAPI 1.0.3 and 2.0.0, and can hold statements in either form. Unless it has been configured to convert between them, asking for statements as 1.0.3 can still return newer-format statements — a mix that is easy to miss. The transfer asks for the newer version, so statements arrive exactly as they were stored. Sereni LRS accepts both, so nothing needs rewriting.

The transfer is resumable. Each page is acknowledged before the next is requested, and statements are matched on their original identifier, so an interrupted run continues rather than restarting and cannot create duplicates.

Step 4 — Attachments and documents

Attachments are the pleasant surprise of this migration. Because SQL LRS stores the files in its own database rather than alongside it, they come through the same interface as the statements that reference them — no separate file copy, no reconciling paths, no risk of moving statements and leaving their evidence behind. Signed assessments and uploaded work arrive with the records that describe them.

State and profile documents are transferred after the statements. These are the smaller half of an LRS but often the part learners notice first: state documents are what let someone resume a course where they left off. If a course is mid-cohort during the migration, this is the step that decides whether learners pick up where they stopped or start again.

Step 5 — Verify

Each check maps to a number recorded in step 1.

• The statement count on the destination Store matches the count SQL LRS reported.
• The oldest and newest statement dates match, which catches a page that failed silently in the middle of a long run.
• A sample of voided statements still shows what voided them.
• Attachments open, and their contents match what SQL LRS held.
• A learner mid-course can resume, confirming state documents arrived intact.
• One of your existing reports is rebuilt and produces the same totals.

Step 6 — Reconnect the senders, then cut over

Each system that sends statements gets its new access key and is pointed at the destination. SQL LRS keeps running and keeps receiving during this period, so both systems hold the same new data and a problem is a configuration change rather than a restore.

Once your reporting owner confirms parity for a full reporting cycle, statements stop flowing to SQL LRS. Keep it running read-only for as long as your retention policy needs, then shut it down.

Two differences worth planning for

Neither is difficult, but both are easier to settle before the cutover than during it.

• Credential scopes. SQL LRS lets you attach fine-grained scopes to a credential pair — read-only for a reporting tool, write-only for a course player. Sereni issues access keys per Store, so isolation comes from which Store a key belongs to rather than from scopes on a shared key. Worth mapping your existing credentials to Stores before you issue new ones.
• Reactions. If SQL LRS is generating statements from rules, those rules are part of your learning design, not just configuration. The statements they have already produced transfer as data, but the generation stops when SQL LRS does — so the rules need rebuilding on the destination and switching on at cutover, not afterwards.

Getting help with it

We run the transfer as part of onboarding, including the verification pass and a written reconciliation against your inventory. Because nothing writes to SQL LRS and no database access is involved, this is one of the lower-risk migrations we do — most of the elapsed time is attachments moving and people confirming reports.

If you would rather run it yourself, the endpoints and their behaviour are in the documentation, and the free xAPI Validator is useful for checking anything the destination rejects.