Making changes in the software that runs your business can be a very stressful decision. The larger your organization, the bigger the project. This is particular true with learning management systems.
If you are in a company with thousands of employees and they all have to access the LMS at some point then you are looking at a migration that could take months, not weeks.
There are a few key defining items of an LMS migration that you should consider. The way you answer these will directly influence the project scope. There is one consideration in particular that will impact the entire project more than any other item: Dd you need legacy user data?
I’ll be honest, most people’s knee-jerk response to this question is, “Yes – absolutely!”
They hate the idea of throwing away all of the user data from their current system as it seems like a waste of money. I totally understand this sentiment, but it’s a terrible reason for attempting to keep legacy data.
What should really be considered is if the current data is actually leveraged. For example, are you using the legacy data as a factor in pay-raises and promotions? If yes, then you have a case for keeping it.
The natural follow-up to the legacy data question is whether or not you need all of the user data, or are only pieces of it useful?
Since you are switching systems you have a real opportunity to “clean house” on information you have been storing but never using. Your IT department might relish the opportunity to purge anything that isn’t being used.
Most organizations would do best to bring over only the information from their current LMS that they are actively using for their business.
That said, this doesn’t mean it’s wrong to not bring any of the old data over.
Sometimes this gives an organization a much-needed fresh start. They can implement new policies around their learning program without feeling captive to the old ones just because there is data stored somewhere.
Once you have a grasp on the data question then you can start to formulate your plan of attack.