LMS Migration Plan: 8 Steps to Switch Without Losing Data

Table of Contents

Originally published 4 May 2024 | Updated 11 November 2026.

An LMS migration doesn’t have to mean moving everything at once. Decide what data you actually need, move users first, bring across the content and records needed on day one, launch with a pilot group, then migrate the rest. Most of the effort is in planning, not the technical move.

Are you putting up with an outdated, unsupported, not-fit-for-purpose learning management system (LMS) simply because the perceived effort of migrating the historical learning data to a new LMS feels overwhelming?

You’re not alone. Concerns about LMS data migration are one of the main reasons organisations stay stuck on an LMS that no longer works for them. In reality, LMS data migration isn’t as hard as it appears. It’s like all change management exercises – it needs to be broken into small steps. Like moving houses, it can also represent an opportunity to take stock of your training data and clean up!

On the flip side, sticking with your existing LMS when a better option exists means the ‘cost of doing nothing’ can be far larger than any ‘cost of migration’. By sticking with an outdated LMS, you may be incurring:

  • Higher subscription costs (particularly if you are stuck on a stored user subscription, rather than an active user model)
  • Higher labour costs in managing training (particularly if your existing LMS cannot easily generate reports or automate enrolments)
  • Higher labour costs in managing users (particularly if your existing LMS cannot integrate with your user-data platform, like an HRIS or Microsoft 365)
  • Higher business costs from ineffective training (particularly if you are reliant on generic training modules from a library and unable to create your own customised, relevant training modules)

So in this article, let’s look at a solid data migration strategy to manage your LMS migration and get you off a platform you’ve outgrown. It’s less effort than you think, and the savings from moving can be significant.

Step 1 – Clarify what data needs to be migrated

Duration: 1 to 2 days

Not everything needs to be migrated from your existing LMS to your new one…

Pause and contemplate that for a moment.

This one thought alone can dramatically reduce the effort of LMS migration. Yet too many organisations start with an assumption that ‘everything needs to be migrated’. The correct thought is ‘We need to extract all data out of our old LMS ’, but that doesn’t mean ‘We need to migrate all data out of our old LMS’.

It may be OK to simply store some data in a CSV from your old LMS, but not actually move that data into your new LMS. For example, your users may have completed a module five years ago. That module may now be completely irrelevant to your organisation, and no new enrolments may have occurred in several years. This module and its training data do not need to be migrated. It just needs to be extracted and stored. If you need to look up this old record, you can do so. If you need to migrate this old record, you could do so at a later date once that becomes necessary.

LMS migration is a terrific opportunity to take stock, particularly if you are in an LMS that allows learners to find and complete random training modules of their own. That data can often be simply stored for future use if ever needed. Your focus needs to be on what training content remains in use and needs migration, and what learning data needs to be accessible within the new LMS (typically compliance/licence data, or training data from the last 12 months). Let’s define this as scoping your migration to relevant training modules and data.

Step 2 – Clarify what data needs to be migrated by day one

Duration: 1/2 to 2 days

Not all relevant training data needs to be migrated by day one.

Let’s define day one as the day you cut over from the old LMS to the new LMS for all (or the majority) of learners. Day one doesn’t require every single piece of content or data to be migrated. It only requires that you have migrated training content and data that is actually required by learners on day one – typically compliance and induction training. 

All those modules on leadership or productivity can actually wait a few days or weeks. It’s OK if someone can’t access a module on Microsoft Teams for a few weeks. What is needed on day one is the essential training – the content or data which is required for learners to do their jobs, such as completing induction training or finding licence data.

Everything else can be migrated after day one – perhaps as soon as day two, but for some relevant training modules and data it may even be week two or month two! 

Let’s define this as scoping your day one migration to essential training modules and data (the relevant training modules and data needed on day one). 


Two colleagues sorting sticky notes on a whiteboard to decide which training content to migrate in their LMS migration plan

Step 3 – Migrate users first via spreadsheet or integration

Duration: 1/2 to 2 days

Now we have significantly reduced the size of the migration. From all data to relevant data. But then further identifying which relevant data is essential for day one. 

So now you have two migrations: 

  • Essential data for day one 
  • All other relevant data from day two until you are done (on a scheduled plan) 

With that in mind, we can now set out the order of migration. You will need to start by migrating users – since you need users in place to record any historical training data. 

Ideally, you would migrate your users by: 

  • Extracting a CSV from the old LMS and uploading it into the new LMS, OR 
  • Establishing a user data integration into the new LMS from your user storage portal (your HR or Payroll platform, or your Single-Sign-On environment like Microsoft 365) 

Either way, migrating user data is relatively quick. This is also a good time to cleanse your learner data – fixing labels and data, importing new data from an integration and so on. 

Step 4 – Migrate and update content at the same time

Duration: 1 to 4 weeks

After users are migrated, you may well need a second user migration at the time of cutover, but for now we have enough. We can now migrate your training content. 

This means (re)creating the training modules in your new LMS as they exist in your old LMS. However, this is another opportunity to take stock and improve your content. Typically, for each module in your old LMS, we need the migration process to follow five categories. 

Creating a simple spreadsheet listing all your modules and which category they fall into, and then assigning responsibilities for each module, is a great way to manage this step.  

Here are the categories: 

Use existing SCORM from the old LMS

If the module is SCORM and can be extracted from the LMS as SCORM (or you have the SCORM file), then reload the same SCORM into your new LMS. This is essentially an exact duplication of your existing content. 

Use a new library module from the new LMS

If the module cannot be extracted as SCORM from the old LMS BUT the new LMS has a library of ready-made content, then check if there is a similar module in that library. This is a ‘like-for-like’ swap and is a popular outcome for compliance training. 

Build a new module in the new LMS now

If the module cannot be extracted as SCORM from the old LMS AND there is no matching module available in the new LMS library AND this module is essential for day one, then consider if you want to recreate the module in the new LMS. Depending on your LMS, this may be easier than you think (and it’s a chance to improve and update your training content)!  

  • In Tribal Habits, for example, training is built in the browser from ready-made elements – text, media, interactive activities and knowledge checks. No design skills required. It’s no harder than creating PowerPoint slides, but fully interactive instead. There is also a low-cost content conversion service to transform an old SCORM into a new module for you. 
  • Of course, if your new LMS doesn’t have excellent training content creation tools, then you will need to build new training in an external e-learning authoring tool, pay an instructional designer to create a new SCORM module for you or buy a SCORM module from a third-party library. All the more reason to choose an LMS that can create content itself.
Build a new module in the new LMS later

If the module cannot be extracted as SCORM from the old LMS AND there is no matching module available in the new LMS library BUT this module is not essential for day one, then consider if you want to recreate the module in the new LMS at a later date. This allows you to stagger the creation of new modules over the first few weeks or months.

  • If creating many modules in weeks sounds daunting, it doesn’t need to be. Certainly, in older, complex e-learning authoring tools, this would be difficult. But with in-browser authoring built for non-specialists, creating training modules takes hours and days, not weeks and months.
Do not migrate the module at all

The final option is the old content that will not be migrated or recreated at all. This might be old training modules no longer in use or elective modules which are no longer required. You may still want to store the training history for these modules, but you don’t need to create them in the new LMS for the migration.

Migrations move fastest when existing modules can be matched to library topics (a few minutes each) and only a couple of essential modules need rebuilding.

Step 5 – Migrate essential training data for day one

Duration: 1/2 to 2 days

Once you have migrated the essential modules (the content required for day one) and your users, the next step is to migrate the historical training data for those essential modules and those users.

This typically means downloading a CSV of the training data from your old LMS and uploading that training data into the new LMS for the matching modules.  

A tip is to migrate only two types of enrolments: 

  • Completed enrolments from the old LMS should be migrated as completed enrolments in the new LMS, so that users do not have to repeat training they have already completed. 
  • All other enrolments – new, in progress – are migrated as new enrolments in the new LMS. This reduces the complexity of the migration (and it’s also usually difficult to migrate a partially complete enrolment between LMS platforms). A tip here is to give notice to users in the old LMS of the cutover date, and that only enrolments completed by that date will be migrated as complete. You can then watch the flurry of activity from learners who are partially completed! 

In a platform like Tribal Habits, you upload your old training enrolment data by CSV, matched to the relevant modules in Tribal Habits. Each upload handles up to 1,500 records, so larger histories are split across several files. Each row is a single enrolment to be migrated. We can accept the old completion date, plus existing expiry or certification date, so that the migration is almost a duplicate of your existing data. A template CSV is downloadable from within the upload wizard, and our Australian-based team can help you map your old data to it.

One practical tip: switch off notifications before you upload historical records. Otherwise, learners may get a flood of enrolment and completion emails for training they finished years ago. In Tribal Habits, you can turn off training notifications per user, either on their profile or through a CSV column. Invitations and password resets still go out. Once the historical upload is done, switch training notifications back on the same way. Skip that step, and learners won’t get future enrolment, reminder or completion emails, so due dates and recertifications can slip without anyone noticing.


An administrator reviewing a spreadsheet of training records before uploading them to a new LMS.

Step 6 – Launch with a pilot group before day one

Duration: 1 week

Now it’s time to launch with a pilot group.

This is a final test of your new LMS. It allows you to check that the migrated data is accurate and that learners can access the new LMS and find their way around it. You can then adjust your communications for subsequent users. 

Step 7 – Cutover on day one with essential training data for all users

Duration: 1 day to 1 week

Now you can cut over from the old LMS to the new LMS for remaining users. 

You might need a final ‘interim’ migration to pick up any enrolment data updated in the old LMS between the first migration and your cutover date (so maybe 1-2 weeks of data). At this point, all new learning is happening in the new LMS. 


A pilot group of staff testing a new learning platform together before company-wide launch.

Step 8 – Migrate the remaining relevant content and training data over

Duration: Staged over several weeks to a few months

Now you can plan out the remaining migration of other relevant training modules and training data over the next few weeks and months. 

How Tribal Habits handles LMS migration

If you’re moving to Tribal Habits, here’s what comes across and how:

  • Users: upload staff by CSV, or on Business 50+ plans, connect your HR or payroll system through a managed integration (an add-on) so users stay in sync.
  • Historical training records: bulk-upload past completions and external records, so each person’s history is in one place from day one.
  • Existing courses: import SCORM packages from your old LMS (SCORM import is an add-on), or rebuild key courses quickly with the course builder.
  • Compliance content: replace old compliance modules with verified AU/NZ library topics instead of migrating outdated versions.
  • Support: our Australian-based team helps plan your migration and onboarding.

Questions to ask a new LMS vendor about migration

  • Can we import our users by CSV, and keep them in sync with our HR system?
  • Can we bring across historical completion records and certificates?
  • Can we import our existing SCORM courses?
  • Who helps us plan the migration, and are they in our time zone?
  • What does it cost, and is any of it an add-on?

Successfully managing LMS data migration 

So there we have it – an 8-step process to manage your LMS data migration.

Add up the durations above and steps 1–6 come to roughly three to seven weeks. The critical decisions are in steps 1 and 2 – defining the scope of essential training content and data for day one.  

Like a house renovation, you don’t need to complete the entire renovation at once! You can focus on the key rooms you use every day and then update the remaining rooms as you go. This staged approach turns what looks like a huge amount of work into a manageable project. It takes a few weeks to reach day one, and the rest follows in stages. You get the benefits of a new LMS sooner rather than later.

Planning a move from your current LMS? Book a demo, and we’ll walk you through what your migration to Tribal Habits would look like.

FAQ’s: LMS Migration Plan: 8 Steps to Switch Without Losing Data

What should a data migration plan include?

A good LMS data migration plan covers seven areas:

  • Scoping: Identify the essential training content and data required for users on day one of the new LMS launch. This helps prioritise migration efforts and reduces the overall workload.
  • Data Selection: Determine what data needs to be migrated (e.g., user information, course completion history) and what can be archived or excluded.
  • Migration Tools & Methods: Outline the methods for migrating data (e.g., CSV uploads, integrations) and any tools required to facilitate the process.
  • User Migration Strategy: Define the approach for migrating user data, including potential integration with existing user directories like HRIS or SSO platforms.
  • Content Migration Strategy: Determine how training content will be migrated, considering options like SCORM uploads, recreating content in the new LMS, or leveraging pre-built modules from the new LMS library.
  • Testing & Cutover: Establish a plan for testing the migrated data and the new LMS with a pilot group before launching to all users. Define the process for transitioning from the old LMS to the new one (cutover) and potentially address any interim data migration needs between the initial migration and cutover.
  • Post-Migration Activities: Outline any additional data migration for non-essential content or historical records after the initial launch.

What are the 4 types of data migration?

  • There isn’t a universally agreed-upon categorisation of data migration types, but here are four common approaches that can be applied to LMS migration:
  • Full migration: This involves transferring all data from the old LMS to the new one. It’s thorough, but slow, and rarely necessary.
  • Partial migration: This focuses on migrating essential data for day-one functionality, such as user profiles, core training modules, and completion history. Non-essential content or historical data can be migrated later or archived.
  • Content-focused migration: This prioritises migrating training content (e.g., SCORM packages, modules) while potentially leaving user data behind or migrating it through separate means (e.g., integration with existing user directories).
  • Staged migration: This breaks down the migration into phases, prioritising essential data for launch and then migrating remaining content and historical records over time.

What is data migration strategy?

A data migration strategy defines the overall framework for moving data from one system (old LMS) to another (new LMS). It encompasses the planning process, including defining the scope, selecting tools and methods, establishing a timeline, and assigning resources. An effective strategy considers factors like data volume, complexity, downtime tolerance, and budget constraints.

How do I document a migration plan?

There’s no single format for a data migration plan, but it should be clear, concise, and easy to follow. Here are some suggestions:

  • Use a step-by-step approach, outlining each stage of the process.
  • Include tables or diagrams to visualise data flows and migration processes.
  • Define roles and responsibilities for each stage of the migration.
  • Specify timelines and milestones for completion of different tasks.
  • Include a communication plan for keeping stakeholders informed throughout the process.

How long does LMS data migration typically take?

The timeframe for LMS data migration can vary significantly depending on several factors:

  • Complexity of data: The amount and type of data you need to migrate will impact the overall time. A simple migration with basic user information and course completions might be completed faster than one involving complex learning paths and customised content.
  • Migration approach: A full migration will take longer than a staged approach focusing on essential data first.
  • Available resources: The size and experience of your migration team will influence the speed of the process. Expertise in LMS migration and data management can expedite the project.
  • Toolset and integrations: CSV imports for users and records, plus an HR or SSO connection for user data, cut down on manual handling. There’s rarely a direct connection between two LMS platforms, so plan around exports and imports.

There’s no one-size-fits-all answer. Steps 1–6, which cover everything up to day one, usually take three to seven weeks. The remaining content and records then move across in stages over the following weeks or months.

What are the biggest challenges of LMS data migration?

Here are some common challenges to consider:

  • Data cleansing: Your existing LMS data may contain inaccuracies, inconsistencies, or outdated information. Fixing them before migration means the new system starts clean.
  • Content conversion: Converting legacy training content to a format compatible with the new LMS can be time-consuming, especially for complex modules or those not built with SCORM standards.
  • Downtime considerations: Depending on the migration approach, there may be some downtime for users while transitioning from the old LMS to the new one. Planning and communication can help minimise disruption.
  • Project management: Coordinating various tasks, resources, and stakeholders throughout the migration process requires strong project management skills to keep things on track.

What are the benefits of LMS data migration?

Done well, migration gets you off a platform that costs more than it should. The common gains:

  • Lower subscription costs: moving from stored-user to active-user pricing means you pay for people who log in each month, not everyone who’s ever had an account.
  • Less admin: automated enrolments, reporting and user syncing replace manual spreadsheet work.
  • Training that fits: building your own modules means training reflects your policies, not a generic library.
  • Cleaner records: migration forces a data clean-up, so compliance and completion records are accurate from day one.
  • Room to grow: adding teams, locations, or new training doesn’t mean starting over.

Further Reading