Moving training data and courses without losing the audit trail.
The hard part of an LMS migration is not the platform. It is the seven years of completion records, the reports your management already quotes, and the approval history that nobody thought to export. We scope that properly before we quote anything.
Key facts about LMS migration
- What we migrate
- User and organisation records, course content, completion and assessment history, certificates, approval and sponsorship records, and reporting definitions.
- Content formats
- SCORM 1.2 and 2004 packages, H5P activities, xAPI statements, and YAML course packages — the open formats Drupal LMS reads natively.
- The hard part
- Historical records and reporting definitions. Content usually moves more easily than the reporting that sits on top of it.
- What we need from you
- Access to export from the current system, a named contact who knows the approval rules, and a list of the reports that must keep working.
- What we do not do
- We do not promise a fixed duration before scoping, and we do not migrate without a test on a copy of your real data first.
- Platform licence
- HK$0. Migration is a scoped service engagement, quoted separately, with the assumptions written down.
Why we will not quote a duration yet
Migration effort is driven by data volume, history depth and the number of reports to rebuild — not by user count. A quote before we have seen a sample of your data would be a guess dressed as a number. The assessment exists precisely to replace that guess with something you can check.
How a migration runs
Scoping and sample
We take a copy of a representative data sample — users, one course, and a slice of history — plus a list of the reports that must keep working. From that we build the actual scope, not a template one.
Mapping and decision log
Every field in the old system is mapped to a field, a transform, or a documented decision not to carry it. That log is the deliverable you review, because it is where surprises live and it is the only way to make an irreversible step accountable.
Trial migration and reconciliation
We run the migration on a full copy in a test environment and reconcile counts: users in equals users out, completions in equals completions out, and every exception listed with a reason. Nothing touches production until that passes.
Cutover and verification
We run the agreed cutover window, then verify against the reconciliation baseline — not just "the site loads". Certificates, records and the reports in scope are checked against the pre-migration figures.
Handover and cutback
Training for the people who will run the platform, documentation for the configuration, and a defined period where the old system stays available as a read-only fallback. We remove that fallback on a date you agree, not on a date we choose.
What moves, and how
| What you have | How it moves | What we need from you |
|---|---|---|
| User accounts and org structure | Mapped and imported with role mapping applied | A user list with department, grade and manager |
| Completion and attendance history | Imported with original dates and completion states preserved | An export including timestamps, not just a summary |
| Assessment and exam results | Imported into the candidate learning profile | An export with scores and pass status |
| Certificates | Regenerated as PDF from the imported record, or uploaded as existing files | The source records and expiry dates |
| Approval and sponsorship history | Imported as a dated workflow history | The old approval data, if it was ever stored |
| SCORM / H5P course packages | Loaded natively — no conversion needed | The package files |
| Content authored in a proprietary tool | Converted where a clean export path exists; flagged where it does not | Access to the authoring tool export |
| Reports and dashboards | Rebuilt on the new reporting layer, then reconciled against the old figures | The list of reports management actually reads |
| User-comments and forum posts | Usually not migrated | A decision from you, not from us |
No rows match your filter.
Two migration situations that need different answers
Moving a mature commercial platform
The data is usually clean and exportable, and the reports are the real work. Expect the bulk of the effort to be in rebuilding dashboards and checking they agree with the old numbers. This is the more predictable of the two, provided the export path is confirmed in scoping.
- Bulk data migration
- Report rebuild and reconciliation
- Single sign-on and HRIS re-pointing
- Training your team on the new configuration
Moving from spreadsheets or an in-house system
There is rarely a clean export. The first task is data archaeology — reconstructing what the spreadsheet actually meant, because a column called "status" may encode three different states. The good news is that there is usually very little data, so the effort goes into interpretation rather than volume.
- Data archaeology and interpretation
- Redefining the process the spreadsheet was a proxy for
- Deciding what history is worth keeping
- A smaller, cleaner target system
Where migrations usually go wrong
Scoping by user count instead of data depth
A 5,000-user system with one year of history is a smaller migration than a 300-user system with a decade of records and custom report logic. The estimating question is how much history and how many definitions, not how many logins.
Rebuilding reports to look right rather than to agree
A dashboard that looks similar but counts differently is worse than no dashboard, because people will make decisions on it. Every report in scope gets reconciled against a pre-migration figure before it is called done.
Leaving the old system running indefinitely
The fallback is valuable for a defined period and corrosive after it. We agree the cutback date during scoping, and honour it, because a second system quietly becomes the system of record for whoever joins next.
Migrating data nobody ever queries
Completion records from six years ago for staff who have left are cheap to move and expensive to store, secure and explain. We will tell you which data is worth carrying and which is not, and let you make that call.
Questions about LMS migration
Can you migrate from our current LMS specifically?
We have not run a production migration off every platform in the market, so we will not claim prior experience with an export format we have not seen. What we can do is take a sample export from your instance during scoping, confirm what is extractable, and tell you plainly what is feasible before you commit to anything.
How long does migration take?
We do not publish a fixed figure, and any vendor who gives you one before seeing your data is guessing. What we give you after scoping is a range, with the assumptions stated, and a set of milestones you can hold us to.
Do you migrate content or only records?
Both, and they are different jobs. Content in SCORM, H5P or YAML moves natively. Content authored in a proprietary tool needs a conversion path, which we confirm in scoping. Records need field mapping, and that mapping is the document you should review before anything moves.
What happens to our data if we leave later?
It stays in a standard schema and exports in standard formats — SQL, YAML, SCORM. There is no proprietary export fee to negotiate on the way out, because the platform is open source and the formats are open.
Can you run the migration in phases?
Often yes, and it is usually better. A common pattern is new programmes and new joiners moving first, with historical records migrated once the target has settled. The order depends on your cutover risk, not on our convenience.
Does the PDPO affect migration?
Personal data is involved in a migration, and the handling of it — access, transfer, retention — has to meet the Personal Data (Privacy) Ordinance. We work with your existing privacy process, and we will not suggest moving personal data by any route that circumvents it.
Start with a sample, not with a price
Send us a data sample and the list of reports that must keep working. We will tell you what is feasible, what the scope is, and what it would cost — before you commit to anything.