An LMS migration should begin with a small rehearsal, not a bulk transfer. Inventory courses, questions, media, enrolments and access rules; confirm what can be exported; then import a permitted sample and reconcile it. Keep the old system available until the team has accepted the new workflow and a rollback plan.
Decide what must survive the move
Separate essential records from convenient history. Course files, question keys and active access rights may be critical, while some old activity logs may not be portable. Record ownership and authorised use of content. An export button does not prove that another product can import the format or reproduce its behaviour.
Download the migration reconciliation worksheet. This is an editable, ungated worksheet from ThePrepLab. Examples are illustrative, not customer results. Use anonymous IDs instead of student personal information.
| Object | Questions to resolve | Acceptance evidence |
|---|---|---|
| Questions | Do options, keys, solutions and diagrams export? | Reviewed count and sample comparison |
| Courses and media | Are files available, licensed and transferable? | Playable sample with correct organisation |
| Enrolments | Can active entitlements and dates be represented? | Test learner sees only permitted content |
| Attempt history | Can raw records or reports be preserved? | Archive and documented limitations |
| Payments | Which provider owns transaction and refund records? | Agreed reconciliation outside the content import |
Choose a representative pilot
Select one course and a small question set containing ordinary text, equations, diagrams and at least one unusual format. Use test accounts rather than live student credentials. Include an expired access case and a student who should not see the course. Success means correct access boundaries as well as successful access.
A reconciliation example
Suppose an original pilot contains twenty questions. Eighteen import successfully and two require manual correction. Report eighteen accepted and two unresolved—not “100% migrated” because twenty records exist in a file. After correcting the remaining items, independently check their keys and presentation before marking them accepted. These are illustrative counts, not PrepLab migration performance.
Use a stable source ID and a destination ID in the worksheet so duplicate names do not hide missing objects. Record whether each test refers to the intended question version. Check text and media as well as totals: twenty question shells without their diagrams are not equivalent to twenty complete questions.
Plan cutover and rollback
- Agree the final export time and how changes after that time will be handled.
- Assign owners for content, student communication and access verification.
- Preserve an authorised backup and restrict who can read it.
- Define what failure would pause the move or return learners to the old workflow.
- Keep deletion and contract cancellation separate from the import decision.
Do not cancel the old service just because a demo import worked. Resolve the timetable, support contacts, data retention and any payment-provider responsibilities first. Record which historical functions will not transfer and explain the limitation to affected staff. Treat a vendor’s promise as something to test, not as acceptance evidence.
Can every LMS migrate to PrepLab automatically?
No universal compatibility is claimed here. Export availability, content rights, formats and package scope differ. Ask both vendors to demonstrate the specific objects you need and obtain a written scope for manual work. Never share account passwords in a public ticket or import file.
Use the software evaluation scorecard, ownership checklist and question-bank review log. If evaluating PrepLab’s branded app, bring an authorised sample to the discussion rather than migrating the entire archive first.