Your training platform still works, but nobody really uses it any more. Logins are eroding, content is dated, and every export request turns into a project. The question is no longer whether to change, but what to move to, and how to get there without losing what you have built up.
This article starts from that exact point. It is not about choosing a first LMS, but about replacing an existing platform: what should trigger the decision, the four possible destinations depending on who you train, what genuinely transfers from one system to another, and how to run the switch without creating a gap in your traceability.
The six signals that say it is time to replace your platform
A platform does not become obsolete because its interface has aged. It becomes obsolete when it stops letting you do the job. Here are the six observable signals, from most to least decisive. Two are enough to justify a replacement project.
- The login rate has been falling for over six months without recovering. This is the most reliable signal because it does not depend on your impressions. Look at the share of employees active over thirty days, not the number of accounts created.
- Part of your workforce has no simple way to log in. No corporate email address, no computer, no screen time. If the platform requires all three, it structurally excludes your operational teams.
- You cannot export your data, or the export is chargeable. This is a dependency signal, and it becomes urgent: the longer you wait, the more there is to recover.
- Producing proof of training takes manual work. If pulling a list of valid certifications for an audit takes days of reprocessing, the platform is failing at its primary function.
- Cost per active user is drifting. You are paying for accounts that no longer log in. Divide the annual amount by employees genuinely active, not by licences.
- Every new need means custom development or another paid module.
One signal is not enough to decide. A falling login rate may be an enablement problem rather than a tooling problem, and changing platform would not fix it. Before committing to a replacement, check that the problem really is the tool and not the way it is being run.
Which LMS to migrate to: four destinations depending on who you train
This is the question that determines everything else, and it turns on a single criterion: who actually needs to train, and under what physical conditions. Functional depth, by contrast, looks much the same from one serious platform to the next.
Your learners work at a computer
Support functions, head office, engineering, desk-based sales. The dominant constraint is instructional depth and integration with your information systems. You can prioritise long paths, virtual classrooms and the link with skills management. Almost the entire market answers this need properly, which shifts the decision towards support and cost.
Your learners have no fixed workstation
Sales assistants, field technicians, operators, warehouse staff, care workers, seasonal hires. This is where replacement most often fails, because a platform designed for desk work gets bought again in the hope it will adapt. Three requirements are non-negotiable and can be checked in a single demo:
- Login without a corporate email address.
- Genuine offline operation, with deferred synchronisation, not simple caching.
- Short formats, readable on a smartphone in a few minutes, between two tasks.
Beedeez, the LMS built for frontline teams, is designed for this case, with usage benchmarks observed on this type of rollout in the region of 95% completion and 92% engagement. These are observed benchmarks, not a guaranteed outcome: they depend as much on content quality and manager involvement as on the platform.
You train both populations at once
This is the most common situation above a few hundred employees, and the worst served. A platform that only serves one of the two populations creates two-speed adoption, and it is always the field that drops off.
Two strategies work. Either a single platform genuinely able to deliver the same content as a long format at a desk and a short format on mobile, which means verifying the second promise rather than the first. Or a main platform complemented by a dedicated frontline setup, with a shared skills framework. The second option costs more in licences and far less in failed adoption.
You have a hard integration or data-sovereignty constraint
Data hosted in a specific country, connection to a complex information system, multi-entity and multi-country governance. These constraints shorten the candidate list before the instructional question even arises. Handle them first, as knock-out criteria, or you will discover at the final stage that your favourite fails the security review.
To compare platforms across these four profiles, see our comparison of the best LMS for businesses. To formalise your requirements before going to market, we published the full template of an LMS requirements document for frontline teams.
What you keep, what you lose
This is where projects go wrong, because it gets discovered too late. An LMS migration never transfers 100% of what exists. Here is what carries over, what carries over badly, and what does not carry over at all.
| Item | Transfers? | What to do |
|---|---|---|
| Accounts and team mapping | Yes | CSV export from the old platform. A good moment to delete dormant accounts rather than pay for them another year. |
| Completion history | Yes, as data | Recoverable as a table. History becomes viewable again, but rarely replayable inside the new tool's paths. |
| Certifications and expiry dates | Yes, secure these first | Extract name, course, date obtained and expiry date before anything else. This is the data with legal weight. |
| SCORM and xAPI content | Yes | Export the packages and test playback on the target platform before the switch, not after. |
| Content built in the old platform's editor | No | The most expensive item. It has to be rebuilt, so it has to be triaged: half an ageing catalogue rarely deserves to be carried over. |
| Quizzes and assessments | Partially | Questions can be recovered; scoring logic and pass conditions are reconfigured by hand. |
| Certificates already issued | As an archive | Export them as PDFs and keep them outside the platform. They cannot be regenerated from the new tool. |
| Social content, comments, questions | No | Identify contributions with business value and turn them into content before shutdown. |
| Aggregated statistics and dashboards | No | Freeze a snapshot before the switch: it becomes your baseline for measuring the effect of the change. |
Migrating without a break in compliance
If you train on regulated subjects, safety, electrical certifications, manual handling, hygiene, migration creates a risk that conventional project management ignores: a period during which you can no longer prove who is certified for what.
An audit or an accident does not accept "we were changing platforms at the time". Four rules cover this risk.
- Export before you terminate, never the other way round. A closed account does not reopen, and an outgoing vendor is under no obligation to restore an environment for your export needs. Negotiate the termination date after verifying your exports, not before.
- List the expiries falling during the switch. Pull the certifications expiring in the next six months. They get handled before the migration or just after, never during.
- Run both platforms in parallel across the regulated scope. Dual running costs a few extra weeks of subscription. That is the price of continuity of proof, and it is far below the cost of a gap in traceability.
- Archive the old system in a readable form and keep that archive for your statutory retention period. A raw export nobody can read is not proof.
The rule to remember: migration ends when you can produce, from the new tool, the list of valid certifications across your whole population. Not when accounts have been created. For more on this, see our guide to managing regulatory certifications for frontline teams.
The six-step sequence
The durations below are orders of magnitude for an organisation of a few hundred to a few thousand employees. They vary mainly with the volume of content to rebuild, never with the number of learners.
1. Frame the decision, one to two weeks
Write down what the current platform does not allow, and how you will know the replacement succeeded. Deliverable: a one-page note with three measurable objectives. Without it, the project drifts into an endless feature comparison.
2. Inventory what exists, two to three weeks
Active and dormant accounts, content by format, certifications in force, existing integrations. The deliverable is the inventory and, above all, the triage, because this is where you decide what will not be carried over. Migrating an entire ageing catalogue is the most expensive and least useful decision in a migration project.
3. Choose the destination, three to six weeks
Shortlist on knock-out criteria, then demo on your own use cases. Have it tested by the populations that are hardest to reach, not the easiest: they are the ones the previous platform failed.
4. Secure the exports, one week, before any termination
Extraction, integrity check, archiving. Deliverable: a complete, tested dataset stored outside both platforms.
5. Switch in batches, four to eight weeks
Start with the regulated scope and new-joiner onboarding, which are both the most critical and the easiest to frame. Then extend by population. A single big-bang switch multiplies failure points without saving any time.
6. Verify and close, two weeks
Compare the active-user rate against the snapshot taken before the switch, produce the certification status from the new tool, and only then close the old contract. To measure real effect beyond usage, see our guide to measuring frontline training effectiveness.
What a migration really costs
The budget for a replacement is not the difference in subscription between the old and the new platform. Four items get added, and the first is by far the heaviest.
- Rebuilding non-transferable content. This dominates. It shrinks dramatically if you triage instead of carrying everything over, and if the target platform has an authoring tool usable without technical skills, which avoids outsourcing every module.
- The overlap between the two subscriptions during dual running, to be provisioned explicitly.
- Configuration and integrations: structure, permissions, single sign-on, HRIS connection.
- Internal time, almost always missing from estimates, although it is often the project's largest real cost.
To build and defend the budget internally, our guide to calculating the ROI of an LMS sets out the method and the indicators to track.
The five most expensive mistakes
- Terminating before verifying your exports. The irreversible one. Every other mistake can be recovered.
- Trying to carry everything over. An ageing catalogue is mostly content nobody opens any more. Migrating it costs money and clutters the new tool from day one.
- Choosing on a generic demo. A demo that succeeds on a textbook case tells you nothing about your reality. Insist on your own content and your own populations.
- Treating migration as a technical project. Moving the data is the easy part. Adoption is the real subject, and it is prepared beforehand, not afterwards.
- Overlooking line managers. With frontline populations they make or break usage. A flawless platform with no local relay reproduces exactly the login rate you were trying to escape.
Frequently asked questions about changing LMS
How long does an LMS migration take?
Allow three to six months between the decision and closing the old contract, for an organisation of a few hundred to a few thousand employees. The dominant variable is not the number of learners but the volume of content to rebuild.
A switch limited to a pilot scope, for instance regulated paths and new-joiner onboarding, can be live in six to eight weeks.
Can you keep your training history when changing LMS?
Yes, as data. Accounts, results, completion dates and certifications export to a table and can then be re-imported or archived. However, history is rarely replayable inside the new tool's paths: it is viewable, not reactivatable.
The condition is to run that export before terminating the old contract, because a closed account does not reopen.
What happens to certifications that are still in force?
They remain valid, but you have to be able to prove it throughout the switch. Extract name, course, date obtained and expiry date first, then list the certifications expiring within six months so they can be handled before or after the migration, never during.
Across a regulated scope, run both platforms in parallel for the duration: the cost of a dual subscription is far below the cost of a break in traceability.
Should you migrate all your content or start clean?
Triage, almost always. In an ageing catalogue, a large share of content is no longer opened, no longer current, or no longer matches the jobs people actually do. Carrying it over costs money and clutters the new platform from day one.
The practical rule: carry over what is regulated, what is used, and what is up to date. Rebuild the rest as real needs arise.
Is SCORM content transferable between LMS platforms?
Yes, that is precisely what the standard is for. Export the packages and test playback on the target platform before the switch, particularly result tracking, which is the part that most often breaks.
Watch the crucial distinction: content built in your old platform's proprietary editor is generally not exportable. That is the main cost item in a migration.
Which LMS should you migrate to for frontline teams?
To an LMS built for them, not a desk platform adapted after the fact. Three requirements are knock-out criteria: login without a corporate email address, genuine offline operation with deferred sync, and short formats readable on a smartphone.
That is the positioning of Beedeez, the LMS built for frontline teams, with observed usage benchmarks in the region of 95% completion and 92% engagement on this type of rollout. These are observed benchmarks, which also depend on content quality and manager involvement.
When in the year should you switch?
Avoid your peak business periods and any strong seasonality, when neither managers nor teams have any availability. Avoid the weeks running up to a regulatory deadline as well.
The real constraint is not the calendar but your current contract end date: start early enough that you are never forced to terminate before securing your exports.
