How to migrate to a new LMS without losing your mind

To replace your LMS, decide first whether you are replacing one system, consolidating several, or fixing the one you have, then run the move in five stages: audit the content and cull what nobody uses, map every data field to its new home, recruit internal champions to test early, pilot with a controlled group before full rollout, and review engagement against the goals you set at the start. Most mid-sized organisations should allow three to six months end to end.

Last reviewed September 2026.

Switching a learning platform is a change management project wearing an IT costume. The organisations that get it right treat the move as a chance to rethink how their people learn rather than a transfer of files from one server to another.

Signs it is time to replace your LMS

Most teams sit with a system they dislike for a year or two longer than they should, because the switch feels bigger than the irritation. These are the signals that usually mean the irritation has become a cost.

• Nobody logs in unless compliance forces them to. Voluntary usage is the honest measure of whether the platform works for your people.
• You export to a spreadsheet to answer any real question. If leadership reporting happens outside the system, you are paying for storage rather than for a learning platform.
• Assignment is manual. New starters do not land in their onboarding path automatically, and role changes are handled by someone remembering.
• It does not work on a phone. Retail, hospitality, field and healthcare teams cannot complete desktop-only modules between shifts, so your completion figures are measuring desk access.
• The renewal quote keeps rising while the roadmap does not move. Price increases are easier to accept when something is arriving.
• You are running more than one learning system because different departments solved the same problem separately.

One or two of those is an argument for fixing what you have. Four or more, and the cost of staying has probably passed the cost of moving. The HR business case builder is a reasonable way to put numbers around that before you take it to a budget holder.

Four ways to deal with an LMS you have outgrown

Three different projects hide behind the phrase "we need a new LMS", and they cost very different amounts. Work out which one you are actually running before you start talking to vendors.

It is also worth checking whether the job belongs in a learning platform at all. Some of what people ask an LMS to do is really employee record territory, and this comparison of what an LMS and an HRIS each handle sets out the split.

Consolidating several learning systems into one

LMS consolidation carries two problems a single replacement does not, and both are people problems rather than technical ones.

The first is duplicate and conflicting records. The same person exists in three systems with three different email addresses, three completion histories and possibly two conflicting expiry dates for the same certificate. Decide the rule before you migrate: which system is authoritative for which data, and what happens when they disagree. Writing that rule down takes an afternoon and saves months of reconciliation.

The second is ownership. Each system has a department that chose it, configured it and has been judged on it. Consolidation asks some of those people to give up a tool they defended. Bring them in as the design group rather than telling them the decision, and be explicit about what they keep. A department that gets a better mobile experience and keeps its own reporting view will usually trade the login.

Practically, run consolidation in waves rather than one cutover. Move the largest and cleanest population first, prove the migration works, then bring across the harder groups with the lessons applied. A single-day switch across five systems gives you no way to tell which source caused a problem.

Why LMS migrations go wrong

The most common failure is the lift and shift: moving every course, file and user record across exactly as it sits today. That carries your old clutter into a new house. Broken SCORM packages, duplicated user records and training nobody has opened in years all come along for the ride, and the new system inherits the old system's problems on day one.

The second failure is skipping the reason. If people first hear about the change through a systems announcement, adoption suffers. Frame the move around what the team gets: easier access to career development, cleaner navigation, and learning that works on a phone.

The five-step LMS migration plan

Step 1: Audit your content before you move a single file

Before anyone touches the upload button, sort the existing library into four piles.

• Keep: evergreen material people still complete and still rate.
• Refresh: content that is relevant but needs a visual or functional update to suit the new platform.
• Archive: courses nobody needs to take again, but whose completion records you are obliged to retain.
• Retire: everything else.

Be ruthless. If a course has not been opened in twelve months and is not a legal requirement, it probably does not need to move. Culling lowers the volume of data you migrate, which lowers the risk of errors and keeps the new library searchable.

Look at format while you are in there. If the old system was built for desktop, this is the moment to plan for the people who do the actual work. Short, mobile-friendly modules completed between shifts beat hour-long desktop courses for most frontline teams.

Step 2: Map your data so nothing gets lost

Losing completion records or historical certificates means months of chasing paper. Data mapping gives every data point in the old system a clear home in the new one, and it is the most technical part of the project.

Start from your mandatory reporting. What does leadership actually look at? Usually compliance status, capability gaps and learner engagement. Every field feeding those reports needs a mapped destination before the migration date. If you maintain a skills matrix, map it deliberately rather than rebuilding it by hand later.

User data deserves the same care. Names and email addresses are easy. The value sits in custom attributes such as department, site, hire date and manager, because those fields are what let the new system assign training automatically. A new marketing hire should land in their onboarding path without anyone in HR lifting a finger, and that only works if the attributes came across clean.

Run a test migration of a sample of user records and check certificates and completion histories arrived intact before you commit to the full load. There is a field-by-field version of this in the LMS migration checklist.

Step 3: Recruit champions to test the system early

Technology is only as good as the people using it. Pick a small group of champions across departments, ideally people comfortable with new tools or vocal about the old system's limits. Give them early access and let them break things.

Their feedback surfaces the confusing navigation and broken links you missed. More usefully, when the platform goes live company-wide, those champions become peer support on the ground. Help from a colleague lands better than a generic email from IT.

Train managers separately. They read the reports and nudge their teams to finish modules, and development sticks when the manager is part of it. A manager who can see how the system supports their team's growth treats it as a tool rather than an obligation.

Step 4: Pilot, then launch, and never on a Friday

Run a pilot with a small controlled group before the full rollout. A soft launch tests the platform in a live environment without risking a company-wide mess, and it gives you real completion data to compare against.

When the pilot holds up, go wide with clear communication about what is changing and why. Do not launch on a Friday. You want the full team available for the inevitable "I cannot log in" queries, and a weekend of unanswered tickets sets the tone for the whole platform.

Step 5: Run the post-migration check-up

In the weeks after launch, watch engagement. Are people logging in? Are they finishing the migrated courses? Gather feedback through short surveys or a few focus groups. You might find refreshed content is not landing, or that one department is struggling with the interface. Fixing those quickly shows the team the migration was for them.

Then go back to the goals you set at the start. If you moved for better reporting, run the reports and check they answer the question. If the goal was engagement, compare the numbers against the old system's benchmarks. A platform such as Compono Develop ties development records to career progression, so historical data keeps working rather than sitting in an archive, but whichever system you land on, the review is what turns a migration into an improvement.

How long an LMS migration takes and what it costs

Three to six months is the realistic range for a mid-sized organisation replacing a single system. Content auditing and testing take the largest share of that, which surprises people who budgeted for the data load.

The costs that get missed are rarely the licence. Content remediation for broken or dated modules, integration work with the HR system, administrator time during the parallel-running period, and the communications effort all land on internal teams. Consolidating several systems adds reconciliation time on top, so plan longer and stage it in waves.

One practical rule: keep the old system readable for a defined period after cutover, even if it is switched to read-only. It costs a little extra licence and it is the cheapest insurance available when somebody asks for a record from four years ago.

Frequently asked questions

How do I know it is time to replace our LMS?

Look at voluntary usage, whether reporting happens inside the system or in a spreadsheet, whether assignment is automatic, and whether the platform works on a phone. If several of those are failing and the renewal price keeps climbing without a roadmap behind it, replacement usually costs less than staying.

How long does it take to migrate to a new LMS?

Plan for three to six months for a mid-sized organisation replacing one system. The timeline depends on the volume of content and the complexity of your data, with the content audit and testing taking the largest share. Consolidating several platforms takes longer and should be staged in waves.

What is involved in consolidating multiple learning systems into one?

Everything in a normal migration, plus reconciling duplicate users, overlapping courses and conflicting completion records. Decide in advance which system is authoritative for which data, bring the owning departments in as a design group, and migrate the largest clean population first so you can prove the process before tackling the messy sources.

Will we lose historical training records when we switch?

Not if you map the data first. Give every field in the old system a destination in the new one, run a test migration of sample user records to confirm certificates and completion histories carry across intact, and keep the old system readable for a defined period after cutover.

Should we move all our old SCORM files to the new platform?

Only the ones that are still relevant and still work. A migration is the right moment to retire dated modules and rebuild them as content that runs on any device. Keep the completion records for retired courses even when the course itself does not move.

What is the biggest mistake organisations make when changing LMS?

The lift and shift. Moving poor-quality content and messy data into a new system reproduces the old problems in a new place, and the team concludes the new platform is no better. Audit and cull before anything moves.