(Editor’s Note: This is the third of five articles by Steve Foreman on learning management systems.)
As I described in part one, the LMS implementation process involves six major steps: planning, LMS configuration, systems integration, course and data migration, user acceptance testing, and go live (Figure 1). I addressed the first three steps in part one, along with the key communications and change-management activities that must be part of an LMS implementation if you want the highest likelihood of success.
- First article
- Second article
- Third article
- Fourth article
- Fifth article
Figure 1: The LMS implementation process
In part two, I cover the last three critical steps.
Course and data migration
If you are changing LMS products or moving from a custom LMS to an off-the-shelf product, you will probably need to move the training data and courses from your legacy system to the new LMS. This is one of the more complex tasks in an LMS implementation. You must do it in a specific sequence, and you must address any incompatibilities between the way the data and courses were stored in the legacy system versus the new LMS. This can sometimes require some creative problem solving.
For example, your new LMS may enforce stricter data integrity rules than your legacy system does. For instance, some of the courses in your legacy system were entered in such a way that their end date was earlier than their start date. The new LMS will reject these courses. So you may need to adjust the dates in the old system before moving them to the new LMS.
Data retention policy
The first step is to decide how much data to migrate. A good rule of thumb is to move as little data as possible—the more data you migrate, the greater the potential for errors and problems that may delay your implementation project. Check with your IT and legal departments. They may have already established an information-retention policy for your organization that you can use to guide your decisions.
For example, if your organization’s policy is to retain employment records for three years, then you may not need to migrate the last 10 years of training data. You may instead decide to migrate only three years of data and create a database archive of all older data. If the need arises to access the legacy data, you can ask IT to restore the backup and run a report. Since the older data is not immediately accessible in your LMS, retrieving archived data may take several days, but it keeps your LMS clean and simplifies your implementation project.
There may be some exceptions to the policy. For example, you may need to consider courses that are prerequisites to other courses. If you do not move data related to prerequisites, some users may not be able to register for a course for which they have already completed the prerequisites. Consider courses that result in compliance and certification as well.
User data
Once you have decided how much data to move, the next step is to load your users into the new LMS. If you are establishing a feed from an HR system, the feed must be developed, implemented, and tested before you migrate anything else. Otherwise, you will need to move the user accounts from your legacy system to the new system.
Standards-based courseware migration
The courseware migration process varies depending on the type of LMS. If you are moving from one academic LMS to another you will need to export your courses to the appropriate format for your new LMS and then import it. A nonprofit standards organization, IMS Global, has developed a number of standards for doing this, including the IMS Common Cartridge (CC), IMS Learning Tools Interoperability (LTI), and IMS Question and Test Interoperability (QTI) standards. Check to see whether your legacy and new LMS support these standards. It will make course migration a lot easier.
If you are moving from one corporate LMS to another, the process is a bit more complex. First, if you have implemented SCORM-based courses, then you will need to reinstall the SCORM package for each of the courses on your new LMS. Some LMS products provide a batch method that enables you to queue up the installation of multiple courses. Other LMS products will require you to install each course, one at a time.
Even though the SCORM courses may have worked well on your legacy system, they may need some adjustment to work optimally on the new LMS. A good approach is to start with an inventory of your SCORM courses; here’s a method that works well:
- Categorize the SCORM courses by the authoring tool or vendor that produced them
- Then install and thoroughly test one course from each category
- Test course launch, player compatibility, bookmarking, navigation, audio, video, animations, graphics, and embedded links, as well as test score, and module and page tracking
- Make sure the course shows up properly in the transcript of the new LMS
- If you run into problems, make any needed adjustments to the course and the manifest, reinstall and retest
- Replicate your adjustments to all other courses in the category; install and test them all.
- Manage an exception list of any courses that don’t work properly
- If you no longer have the source code for the course, you may need to redevelop the course using a more compatible authoring tool
Course data migration
If you are implementing an academic LMS, your course data probably transferred via the IMS standards described in the previous section. For a corporate LMS, your IT organization will need to extract your course titles, descriptions, schedules, locations, instructors, metadata, and other course-related data, format the data according to your LMS vendor’s specifications, and import the data into the new LMS. If your IT department is not equipped to do this, you may need to hire your legacy LMS vendor to create the extracts.
Transcript migration
Once you have populated your new LMS with users and courses, the last step is to move your legacy transcript data to the new system. Transcripts represent the relationship between users and courses, which is why the users and courses must be present in the system before you move the transcript data.
Test a sample of the user, course, and transcript data to ensure the migration process worked properly.
Migration stages
You should perform the user, course, and transcript migrations in three stages. Clearly, you’ll want to avoid any data loss, so in the first stage you’ll migrate a relatively small sample of the data and test it to verify that the migration programming works properly. The second stage is to migrate all data to date. Once you’ve done this, you will be able to enhance the course setups by configuring any features and functionality that you may not have had in your old LMS and you will be able to perform user-acceptance testing. The third stage happens just prior to go live, where you will perform a transfer of the data that was added or changed since the full migration you performed in the second stage (this may sometimes be referred to as a “delta transfer”).
User acceptance testing
The last major step before going live with your LMS is to conduct user acceptance testing. Your organization is the “user,” and you are testing the LMS to make sure the vendor has delivered a fully working, bug-free system. You are also testing to make sure your configuration, courses, and data are available in the system as you expect them to be. Once you are satisfied with this testing, you are essentially “accepting” the system from the vendor.
The key to user acceptance testing is to be thorough in testing every part of the system. You want to find and correct all the bugs before you go live so that your end users don’t have a bad experience in the first few weeks or months after the LMS is introduced.
Start by convening the core team to brainstorm a list of procedures to test. Include procedures performed by administrators, learners, report users, instructors, and any other security roles you have defined.
Once you have your list of procedures, divide the list between team members (you may want to engage some of the extended team) and ask each individual to run through the procedure and make a note of every action performed: menu items selected, fields entered, checkboxes checked, buttons pushed, etc.
You may want to provide a spreadsheet format for the test designers to use. You can create a worksheet for each test. Each worksheet may include a header with the test name, the role of the tester (e.g., administrator, instructor, student, etc.), and any requisite data that is required to be configured in the system in order to run the test. For example, if your test specifies that a student is to find a course and register for it, the student’s account and the course must both be present in the system. The rows in the worksheet may represent the steps in the procedure. You may want to include three columns to represent a description of the action to be taken, a description of the expected result, and a place for the tester to enter the actual result.
After you have defined and documented all the test procedures, create a test schedule. Do your best at placing the tests in a logical order to make test setup easier. For example, run the test in which an administrator creates a course before you run the test in which a student registers for the course. You may want to schedule no more than one or two hours of testing per day for each tester so that they can continue to perform other work duties.
Assign a test lead to debrief testers and record bugs. Convene the core team at the end of each testing day to discuss the status of all open bugs. Prioritize each bug as critical (must be fixed immediately; prevents further testing), moderate (must be fixed prior to go live), or low (should be fixed in a future release). Route bugs related to the content and data to the appropriate people in your organization. Route bugs related to the system to your IT organization, the vendor, or both. Keep track of who owns each bug at any given time until the bug is corrected. Be sure to retest corrected bugs to verify that they have been fixed.
Once all tests have been completed, end-to-end, and all critical and moderate bugs have been fixed, you are ready to go live with your new LMS.
Go live
The final step is to go live with your new LMS. To prepare for go live, it is a good idea to meet with the core team to brainstorm a list of risks and a contingency plan to mitigate each risk. Notify your course owners and administrators well in advance of the go live date. Advise them to avoid scheduling critical training during the week before and the week after the go live date, if possible.
Helpdesk preparation
Consider providing a helpdesk script to your support staff, who will respond to questions and problems reported by end users. Create a list of anticipated call topics and describe how to respond. Examples include how to get to the LMS, how to recover from a lost password, what to do if something does not appear in your transcript, how to register for a course, etc. Provide an escalation process indicating who to contact if your helpdesk staff cannot resolve the problem, and what information to collect when escalating a problem.
Blackout period
There will be a period where neither your old system, nor the new LMS will be available. During this “blackout” period, you will want to shut down your old LMS, perform the delta data migration, spot check the data and functionality in the new LMS, and redirect the legacy system’s web address to the new LMS.
If anything goes wrong, you will need to reactivate the old system and postpone your go live date until the problem is diagnosed and resolved.
To minimize disruption to your end users, you may want to schedule the final go live tasks to occur over a weekend, provided the resources involved in your go live process are available.
Concluding thoughts
There are many moving parts in an LMS implementation. As the old saying goes, “The devil is in the details.” Implementing an LMS is a rigorous and resource-intensive process. It’s almost never the case that an LMS, right out of the box, will suit all your needs, so it’s important to be prepared for what is involved in LMS implementation when you decide to evaluate and select a product.
Many organizations remember their last LMS implementation as a nightmare. Looking back, they could have avoided many of the problems they encountered. With the appropriate resources and planning, and lot of attention to detail, your new LMS can serve you well for many years to come.