How to Implement an LMS, Part 7: Final Steps

In this seventh article about How to Implement an LMS, it’s time to take a look at the remaining steps of implementation, which include Systems Integration, Course and Data Migration, User Acceptance Testing, and Going Live. Without further ado, let’s dive right in!

How to Implement an LMS

Systems Integration

What are the different systems your company uses with which your new LMS must integrate in order to achieve optimal efficiency and robust functionality? Some of the possibilities to consider include the following:

  • User Data. In the last article I mentioned user profiles and demographic information. Your LMS should be able to pull much of what you want included from other systems, most likely your HRMS (human resources management system). If your LMS is going to grant access to a wider range of stakeholders than just employees (such as customers, suppliers, dealers, agents, distributors, and so on), what systems contain information about those potential users? You’ll need to build integration interfaces for each system from which your LMS needs to extract information. This will most likely be a responsibility that falls with your IT team member(s), who may also need to work with the vendor to develop the necessary interfaces. For constant updates, these can often be scheduled to run automatically, such as overnight. Whatever integration interfaces are developed, make sure they are thoroughly tested! If this kind of data needs to be entered from scratch, be clear about who has the access permissions to create user accounts. It’s probably best to limit that to a system administrator to avoid users making errors and messing things up. This can work well for limited numbers of users, but if you’re going to have a lot of users, you may want to consider setting up self-service user account creation. Just realize that you’ll likely have to deal with duplicate accounts and other headaches, some of which can be avoided by requiring a unique email address that must be validated in the user account creation process.
  • Single Sign-On. Users dislike having to remember multiple log-on credentials for various programs and systems. If your company has setup a single sign-on (SSO) solution for company network access, you’ll want to integrate your LMS sign-on with it. Make sure your IT folks have talked to the vendor about this for your company’s SSO if you have one.
  • Portal. If you have a company portal, your LMS should be able to integrate with it, typically by two different methods. One is where there are links on the portal that take you to courses in the LMS (this is called deep linking) and the other is an API (application programming interface) where your IT people set up a program that pulls data from the LMS and posts it to the portal.
  • Enterprise Searching. More and more companies are setting up enterprise-wide search functions that allow users to search everything in company systems for the information they need. If you integrate your LMS with your enterprise search function, then part of what will come up in search results will be related training and learning information. Once again, it is your IT people who will need to set up access to the LMS by the search engine. This is no small feat, but it may well be worth the time and effort.
  • eCommerce. If your company is interested in opening up access to courses to people who want to pay for taking them, you’ll want to build an integration interface with an eCommerce credit-card processing solution. Note that some LMS products have this functionality built-in.
  • Integration Assistance: Ask our integration assistance experts for help.

Course and Data Migration

If you’re switching from LMS product to another, you’ll more than likely want to move existing courses and training data from the old system to the new one. This is often the most difficult piece of the implementation process, and will probably require close collaboration between your LMS Project Team, your IT people, and the vendor. Keep the following points in mind:

User Data Retention/Migration. You’ll need to decide how much of the data from a legacy system should be brought into the new system. In general, because of the headaches often involved, the less data you migrate the better! Your legal folks or IT people may already have some policies in place about how much data needs to be retained from the prior system. If your company is only required to keep employee data for 5 years, then you certainly wouldn’t want to try to migrate 10 years worth of data. Older data could then still (theoretically) be accessed through IT system backups if/when needed (although it won’t be easy or fast to do that). Other points to consider are when some courses require prerequisite courses to have been taken first – if some of that data goes back further than retention guidelines, you may still want to migrate it in order to avoid some users not being able to register for a course because there’s no record of them having taken the prerequisite courses. Another area where this can be an issue is when courses result in compliance or certification standards being met.

Courseware Migration. In a corporate setting where you’ve used SCORM-based courses in your prior system, SCORM packages must be reinstalled in your new system for each course. Some LMS products allow for batch-processing to make this easier, but in many cases it will involve dealing with each legacy course individually, and the courses in the new system may still need further adjustments for optimal use in the new system. And you need to thoroughly test each course in the new system to make sure it’s working correctly. Again, with a large bank of courses, this can be very time-consuming.

Course Data Migration. In addition to the courses themselves, there’s also each courses metadata that need to be transferred over. The data must be extracted from the old LMS and formatted to work in the new LMS, the specifications of which can be provided by your vendor. If your IT people can’t handle this, then you may have to hire your previous vendor to set up the extractions.

Transcript Migration. Only after migrating all the user data and courses can you bring over the transcripts to show which users have taken which courses. Again, conduct a thorough test to be sure this data has been transferred successfully.

Running the Migration. Doing the actual migrations should happen in stages in order to avoid losing anything. Start with a small sample and then test it to see how it worked. If things look good, then do the full migration. When that’s complete, then you can make all the needed adjustments to courses, such as activating any functions or features that weren’t present in your previous system. Because all of this takes time, you’ll probably have to perform one more migration for any recent changes in data from the legacy system before shutting it down entirely.

User Acceptance Testing

Having achieved the full migration (or inputting if you weren’t migrating anything), you’re ready for a full test of the system. This testing process not only confirms that everything is working the way it’s supposed to, but it also provides the opportunity to verify that the new LMS is going to meet all your expectations. This is why you need to be very thorough in this testing phase. This is your chance to ferret out any bugs or glitches or issues and get them resolved before going live. This is extremely important because it helps you ensure that your earliest users will have a great experience using the new system rather than pulling their hair out because it’s not working. Be sure you’re not just testing end-user functionality, but all of the administrator functionalities your team will be using. Expand your project team as needed to conduct the testing, and set up a schedule for completing the tests. Have testers keep a very detailed record of each and every action performed during their tests with copious notes about any problems encountered. Assemble the documentation and determine who is responsible for dealing with and resolving each issues or problem that needs to be addressed.

Going Live

When all the testing is complete and all issues have been resolved, you’re ready to Go Live! Think ahead about what might go wrong and how you’ll deal with it. Make sure your end-user support folks are ready, such as creating a list of anticipated call issues and scripts for responding to those (login problems, how to register for a course, and so on). Also, there will necessarily be some period of time where the old system has been shut down but the new system is not yet fully operational – just keep people informed of this time period so they aren’t left wondering what’s going on. Also, don’t discount the possibility that something goes so wrong that you have to reactivate the old system for a period of time in order to resolve a major problem and re-schedule your Go Live date.

Congratulations! Through this seven-part series of articles, you’ve learned everything it takes to prepare your organization for a new LMS and implement it. Give yourself a pat on the back, because as you now know, it’s no small feat! Be sure to as our LMS implementation experts for help.


Don’t Miss These Essential Tools

Leave a Reply

Your email address will not be published. Required fields are marked *