• Learning Management Systems
  • Cover
  • Chapter 1. What in the World is a Learning Management System?
  • Chapter 2. Types of LMS Deployment & Common Features
  • Chapter 3. Stakeholders and Usability
  • Chapter 4. All About the LMS
  • Chapter 5. LMS Evaluation and Selection
  • Chapter 6. LMS Implementation and Transition
  • Chapter 7. Evaluating LMS
  • Download
  • Translations
  • LMS Implementation and Transition
    • Chapter 6

    LMS Implementation and Transition

    Migrating from one Learning Management System (LMS) to another can be a big undertaking, depending on the size of your organization as well as the number of people using the LMS and how they use it. The implementation truly begins with a conversation: defining what a LMS is, what is the core functionality and why are we considering this? To explore these questions a committee should be formed and composed of key stakeholders (Wright, Lopes, Montgomerie, Reju, & Schmoller, 2015). Asking the aforementioned questions while engaging in conversations, especially with the stakeholders, brings people together and gives everyone a voice. When it comes to implementing a new system as big and as far reaching as a LMS, a grassroots approach is helpful. Giving a voice to as many people as possible will help with adoption and buy-in from the people that use the LMS regularly (Levasseur, 2001). This chapter will cover a case of an LMS implementation and transition at a public higher education institution. The next sections of this chapter will discuss the steps taken in the LMS implementation and transition process. 

    The LMS Evaluation Committee and their Charge

    First, a committee was established for the overall process. The committee was co-Chaired by the director of the Office of eLearning and the LMS manager. The committee was composed of 17 members representing all organizational units. Specifically, ten instructors and seven staff members. The instructors were selected based on the different areas of the organization they represented. The staff members consisted of additional representatives of the organization that either utilize the LMS within their group or help support the LMS (Wright et al., 2015).

    The charge of the committee was to review the current learning management system, which had been in place for approximately seven years at the time. On average, universities evaluate LMSs approximately every 8 years (Brown, Dehoney, & Millichap, 2013), and this review gave the organization an opportunity to reassess its learning management needs and evaluate alternatives. 

    The objectives of the review were to:

    The committee met multiple times to discuss, analyze and undertake the following: selecting an appropriate LMS to pilot that meets the current needs and can accommodate future growth while taking into consideration what the next generation of digital learning environments will look like (Brown, Dehoney, & Millichap, 2015). Additionally, the committee members also created a survey for current end users (i.e., people who are currently using the LMS within the organization) on their satisfaction level and usage of the current LMS, focusing on core functionally, and a list of the criteria for selecting a new LMS (Wright et al., 2015).

    While it is important to include as many people as possible when gathering feedback; at the same time, it is almost impossible to gather feedback from an entire organization. Therefore, to ensure everyone has a voice, representatives from a respective area of the organization were involved and part of the committee, including learners. These representatives were tasked with decimating information from the LMS committee to their respective areas as well as reporting back to the committee any comments and feedback received. If these representatives were opinion leaders within their areas, they could potentially influence and receive the support of others . This was another tactic that the co-chairs utilized to ensure that not only were people receiving communication about the pilot and evaluation, but that people whose opinions are respected were a part of the process (Chen & You, n.d.).

    At many organizations, the purchasing department needs to be involved from the beginning as well. Usually, there are multiple LMSs available, and in order to get a comprehensive overview of the best options, a request for proposal (RFP) most likely will need to be written and sent out. The RFP is typically written by the individual(s) leading the LMS migration. The purchasing department then reviews and sends out the request. Once a list of potential LMSs has come back, the committee decides on one LMS to pilot. Throughout the pilot and the migration phase, at least two LMSs will be running concurrently, i.e., the existing and the pilot LMS. It is advisable to keep one LMS pilot at a time. This step can ensure that the pilot runs smoothly, avoiding confusion and allowing personnel enough time to learn a new system. It also helps to provide support for the pilot and existing LMS. 

    Facts and Figures of the Pilot

    Once the LMS had been selected to pilot, the committee helped identify pilot members. When selecting the pilot group, the first thing to consider is the parameters set by the company whose product is being piloted. For example, depending on the terms of the pilot contract, there might be a limit to the amount of courses, instructors or students that can participate. In this particular case, there was a restriction on the total number of students allowed in the pilot. Although there was not a precise number imposed by the vendor, an approximate number was established. This restriction turned out to be a positive aspect in this process as it helped to keep the pilot size manageable, allowing support personnel to provide a much more hands on approach.

    For this pilot, a group of faculty volunteered to teach their courses using the selected LMS for the entire semester. Included in the pilot were:  

    While the committee could not accommodate all of the requests received from instructors to be a part of the pilot, they were able to create courses and LMS accounts for all instructors. This step allowed for those interested in participating to at least build a course and to give them an opportunity to share their opinion about the piloted LMS. This decision was grounded on the grassroots approach taken in this process and getting as many people involved as possible. Additionally, having a limit on the number of students that could participate in the pilot, which was imposed by the vendor, gave the committee a way to keep the pilot size manageable.  

    Along with the limitations aforementioned, it is also important to consider any limitations imposed by the organization. These organizational limitations can be defined as internal restrictions. For example, in a currently running LMS, there are most likely multiple third party tools integrated. These tools could be free or require a licensing fee. With an LMS pilot, it might be difficult to integrate all of the third party tools that are currently being used. Either the pilot committee or a sub-group of that committee need to make the decision on what additional resources may or may not be included with the pilot. This decision also needs to be communicated to the pilot faculty as soon as possible so there are no surprises or missed expectations throughout the pilot phase.

    Another consideration is the tools, which are available in the current LMS, may not be available in the pilot LMS. These tools need to be identified quickly because there may be a need for concurrent pilots or testing additional tools that instructors have come to rely on such as plagiarism detection software. These tools can place additional time constraints not only on the evaluation committee, but also the pilot group. Any new tools introduced will require additional training and time to learn how to use them. The tools need to enhance teaching and learning while connecting seamlessly to the LMS and being relatively easy to learn (Abel, Brown, & Suess, 2013).

    A third consideration identified during this pilot was to exclude specific academic programs from the pilot. For example, the organization has accelerated programs running 7-week fully online courses as well as traditional programs running 15-week courses. Switching between two different LMSs could be confusing for students and instructors. To help avoid confusion and unnecessary stress on students, the LMS evaluation committee elected not to have any of the 7-week courses participate in the pilot.

    Support and Training

    The next steps in this process were identifying a support/training plan. A pilot is only going to be as strong as the support and training provided. This includes both instructors and students as well as system administrators and support staff. Questions to ask include: What type of support is needed? and Who will provide it? Additionally, training needs should be addressed well ahead of the pilot to give instructors time to build their courses and ask any questions prior to the start of the pilot period.

    Ideally, you want to train system administrators and support staff first. This will allow system administrators to configure the application to meet the needs of the organization and disable settings that are not needed. When getting ready to introduce a new application like an LMS, it is best to start small. In other words, if possible, the system administrators should disable anything that is not relevant to the pilot. Additional tools can always be introduced at a later time.

    In the beginning, focusing on the key tools and functionality of the LMS is most important. This can and should be discussed within the LMS committee. This process is all about openness and transparency. System administrators also need time to create courses and enroll pilot instructors and students. Depending on the scope of the pilot and the system administration resources, this could be an automated process or a manual one.

    In this LMS pilot example, the system administrators had a manual process. The needed course and enrollment information was pulled from the Student Information System (SIS) and formatted into a CSV file that was manually uploaded into the LMS. There were two main reasons to set up as a manual process. The first was timing. There was very little time between deciding to run the pilot and actually starting the pilot. The second was because this was a pilot, and setting up the automation can be a time-consuming process. It was decided that the automation can be worked on once a decision was made to move forward. 

    Once system administration and support staff training has been completed, it is time to schedule the instructor training. It is also advisable for support personnel to attend the instructor training as well, especially if it is being conducted by an outside trainer. This will ensure that support staff will gain the same knowledge and skills that the pilot instructors were trained on, thus, giving the ability to provide better support. It is also important during these early pilot stages to reach out to the pilot group often, asking how they are doing and reminding them of the support options available. A smooth pilot really requires quality support, multiple means of support and communication.

    The Course Building Process

    Once a pilot group has been trained, it is time to start building courses, which brings up important questions: Does the institution import course materials from the existing LMS? In following this step, a “cleaning up” would be required since moving course content from one to another LMS is not seamless as it may seem. Or does the institution build from scratch? With this LMS pilot, there was a multi angle approach taken. The team gave the pilot members three options: 

    1. Have their content migrated and “cleaned up” by support staff. 
    2. The instructor could import their own course material and “clean up” the course themselves. 
    3. The instructor can build the course from scratch in the new LMS. 


    All three options were selected by multiple instructors. The first option gave the support staff time to learn the migration process and get a sense of how much time a “clean up” would take. Meanwhile, the second option allowed the team to get a sense of the time that an instructor would take to go through this process. Finally, the third option provided similar information with building a course from scratch. Throughout the pilot, the co-chairs sent multiple follow up emails asking the group how it was going and asking the instructors to reply all to share their experiences with all of the pilot instructors.

    Plan for LMS implementation

    Once it was determined to move from the pilot to implementation, the next step was to develop a timeline. Much of the implementation plan was pulled from the pilot plan. Given that LMS migrations can be a long, multi-year project depending on the size of your organization, the co-chairs established a LMS transition team to help facilitate the migration. The team consisted of the LMS administrators, instructional designers and 3 graduate assistants. 

    Communication, Communication, Communication

    A project of this size requires multiple meetings with multiple stakeholders and various committees across an organization. Schedules can fill up fast so the sooner a timeline can be developed and meetings scheduled the better. These meetings are all about spreading the word, as communication is key to a successful project of this scope.

    One of the biggest challenges with implementing an application widespread as an LMS, which has a diverse population using it, is getting the word out. Misinformation can spread quickly and having a solid communication plan in place is very important. Keeping that communication flowing throughout the process will help avoid any miscommunications. 

    In this example, a very detailed communication and roll out plan was created by the LMS evaluation committee co-chairs. The plan was then sent to the LMS evaluation committee for review and approval.

    Communication Plan

    The communication plan began with the co-chairs establishing a multimodal approach in communicating with the organization, starting off by identifying the various modes of communication available at the organization. In this example, that included print materials, email, web based newsletters, a new website and scheduling meetings with various stakeholders, organizational leaders and any relevant committees within the origination. The communication plan also focused on mass communication as well as very targeted communication as the migration progressed. 

    From the beginning, the co-chairs stressed that communication was key. Their goal was to have a high communication in flux to the point that the organization would be happy when it was over because they would not need to hear about the migration anymore. The first messaging that went out was an announcement in the organization newsletter informing everyone within the organization that the decision to move forward with implementing the piloted LMS had been made. In this case, the team began the transition during the Summer and was completed at the end of the Spring semester. To help with this timeline, the committee also recommended that the organization purchased the 24/7 live chat support provided by the vendor. This decision was  made to help ensure a smooth transition and provide as much support for faculty and students as much as possible especially during off business hours.

    The second part of our communication plan was a messaging campaign with a goal of ensuring that all members within the organization were aware of the transition. This consisted of the creation of a website dedicated to the new LMS and transition. The site included training dates, a calendar for signing up for trainings, self-help guides as well as links to our internal ticketing system for instructors to easily submit requests or ask for help. 

    Multiple training fliers were printed and distributed across the organization throughout the transition. Weekly announcements were posted in the organization's newsletter, highlighting a different aspect of the new LMS. Monthly emails were sent to leaders across the organization and a countdown timer was set up and placed in a very visible spot in the existing LMS. This countdown timer was by far one of the most effective communication strategies employed. There was more feedback received about that timer than any other method of communication. Meetings were also scheduled specifically with program coordinators and leaders of fully online programs. Again, the goal was to ensure that the entire organization was aware of the transition and there were no surprises. 

    Since the pilot had been successful, much of the rollout plan was based off of what was done during the pilot. For example, limiting new tool integration and new customizations until the migration was complete. This was communicated early and often to ensure expectations were set from the beginning.  This also allowed the support staff’s time to focus on course migrations, trainings and learning the new LMS. The goal was to make sure support staff were comfortable with the new LMS before adding additional functionality and customizations. 

    The implementation plan really started with the communication plan and evolved from there. As mentioned, the implementation team met with program coordinators and leaders for fully online programs. While meeting with these groups, timelines were established for transitioning each of the respective programs. These fell into two distinct groups, the first were fully online programs that follow a 15 week schedule. The second fell into the accelerated 7 week course schedule. With the 15 week fully online programs, each department established a plan for migration that would be implemented over the course of the Fall and Spring semesters. The goal was to get the Fall courses up and running on the new LMS while the Spring courses were being migrated during the Fall. 

    Communication Plan Timeline

    In this particular case, the Summer was designated as a soft launch since the majority of instructors are off contract and not required to teach during that semester. It was decided that the official announcement would wait until the Fall. 

    The communication plan included organizational wide announcements as well as targeted communications to specific groups. 

    Course Migration Plan

    With the 7 week accelerated programs, courses were migrated in groups based on program and course availability. This was planned in coordination with the respective departments to cause the least amount of impact to the students and to ensure new cohorts of students would be able to start on the new LMS.

    To confirm courses were migrated in a timely manner, the team hired 3 additional graduate assistants to facilitate trainings and course migrations. A course migration request form was created in the organization’s internal ticketing system to help streamline the process and stay organized. Expectations on migration times were established up front so instructors were aware of timelines, i.e., 2 to 3 weeks, and this was communicated on the migration request form. Priorities were given to courses that would be running in the upcoming semester. This information was also communicated and part of the migration request form. As part of the communication plan, faculty were given the same options for migration as were offered during the pilot, with an additional fourth option. 

    The fourth option was having the vendor migrate the content. As part of the contract with the vendor, there was the option to send them a set number of courses from the old LMS that they would migrate into the new one. Two bulk migration times were established for the vendor to migrate the courses. The first was halfway through the migration and the second was towards the end of the migration. In all, the team received approximately 1,400 migration requests that were completed based on already established criteria. Having the established criteria helped the team easily prioritize work and identify courses that could be sent to the vendor for migration. The vendor’s turnaround time was approximately 2 weeks. This gave the team time to focus on the higher priority courses. 

    This graph below reparents the total amount of courses migrated each month during the migration.

    Figure 1

    Number of course migrated per month during the migration process

    The timeline for the transition broke down as follows. The transition to the new LMS began for all non-accelerated programs as soon as it was determined that the new LMS would be implemented, which was at the end of the spring pilot.

    Figure 2

    Timeline for the transition

    Trainings

    Throughout the migration process multiple training opportunities were offered. A breakdown with the number of attendees per month can be found below.

    Figure 3

    One-on-one faculty meetings during the migration process

    Ngnk_3.png

    Multiple open training sessions were scheduled in computer labs. These were set up in two-hour blocks in which faculty and staff who needed help could drop by at any time during the timeframe period.

    Figure 4

    Training sessions during the migration process

    Ngnk_4.png

    Department specific trainings were also offered and scheduled as part of the targeted approach to the migration. Below are the training numbers for the specific trainings based on the respective colleges.

    Figure 5

    Participants in trainings based on colleges

    Ngnk_5.png

    There was also the option to enroll in online asynchronous training throughout the migration. A breakdown of the numbers of participants that signed up for the asynchronous training can be found below.

    Figure 6

    Participants in asychronous trainings 

    Ngnk_6.png

    Implementation Strategies/Lessons Learned

    Have a soft rollout - If possible, have a soft rollout of the LMS. With the timing of the pilot and the choice to move forward with implementation happening at the end of the Spring, many of the instructors had already left for the Summer. Unfortunately, the official announcement about the LMS migration was not made until the Fall. As a co-chair, the author of this chapter wanted to get the word out as soon as possible because not announcing it sooner could be a disservice. However, letting faculty know they could use Canvas over the Summer and holding the official announcement until the Fall allowed the team some wiggle room to make changes and adjustments that were not anticipated up to the moment of a larger population joining the new LMS.

    Policies and Procedures - Have policies and procedures in place prior to the launch. With a new LMS, it is a great time to establish best practices early on, especially from the administrative side. Also, if possible have a moratorium on any new tool integration or customization until after the migration is completed. Although faculty and support staff were very eager to start working in the new LMS, there were not enough resources to run two LMSs while also integrating and learning new tools and customizations. 

    Stakeholders and Champions - To ensure a successful LMS implementation, it really boils down to having a strong and well respected LMS committee and pilot group. These are your champions who will help get the buy-in from their peers.

    Support - Knowing the needs of the organization and communicating those needs to instructors and other personnel will lend itself to better support and training. If the end users feel like they are not getting the help they need, they will become discouraged. This discouragement can spread as they share about their experience. Additionally, training system administrators before instructors will allow the administrators time to make configuration decisions based on the current needs of the organization.

    Communication - Creating a solid migration/communication plan up front will help the team once the workload and activities increase. It will also be important to have a plan to fall back on. Setting up the countdown timer in the old LMS was one of the best communication methods we employed. It was highly visible and sizable. We received the most feedback from the timer and anyone using the old LMS could not miss that information when they logged in. Being able to identify instructors still using the current LMS was also a useful strategy for providing targeted communication. Throughout the last few months of the migration, the LMS administrators identified instructors that were either still using the old LMS or had not yet logged into the new LMS. Emails and trainings were targeted at this group specifically. This allowed us to continue to provide support to those that needed.    

    Grade Disputes - Ensure to have a plan for the old LMS. For example, there might be a need to access the former LMS in case there is a grade dispute or other similar circumstances. Often organizations must retain grades for a specific time period. Questions to ask: How long will grades need to be kept? Will there be a need to extend the contract with the old LMS vendor?

    Common problems that could have been avoided

    Learning - As system administrators, it is extremely important to learn the LMS well to avoid any confusion in the future. For example, if there are tools in the new LMS, which are unavailable in the current LMS, it is beneficial to disable them until the system administrators have had a chance to learn how the new tools work. In our case, there were a few tools we would like to have disabled as they did not function as expected. This caused additional workloads on the support personnel.

    Training - Plan for administration support training prior to instructor training. During the pilot in this example, there was a very short turnaround time between scheduling the trainings and instructors leaving for the winter break. The co-chairs ended up scheduling the instructor training before the administration training. If the administration training would have happened first, it would have given the LMS administrators the chance to configure the system to better meet the needs of the organization instead of making changes after instructors started using the new LMS. It is always easier to introduce new features versus removing once instructors have started using them.

    Policies/Procedures – When integrating a new LMS, it is a good time to not only check that existing policies and procedures are up to date, but also to verify whether there is a need to introduce new ones. Additionally, make sure to have any new policies and procedures worked out prior to rolling the new LMS out to the organization.

    Prepare for the Unexpected – This is easier said than done. It is important to have some flexibility in the migration or make sure those that are responsible for the implementation/migration have the resources needed throughout the process to handle anything unexpected. For example, looking at the graphs presented previously on the multiple open training sessions and the department specific trainings, there is a dip during the months of September and October. This was due to the institution being shut down for nearly two months because of a natural disaster. The migration/implementation team made sure to stay in contact during this time as well as to ensure they had the resources needed to continue working remotely.

    References

    Abel, R., Brown, M., & Suess, J. (2013). a new architecture for learning. EDUCAUSE Review, 48(5), 88–102. Retrieved from https://edtechbooks.org/-qkV

    Brown, M., Dehoney, J., & Millichap, N. (2015, April). The Next Generation Digital Learning Environment A Report on Research. Retrieved February 13, 2020, from https://edtechbooks.org/-Qaie

    Brown, M., Millichap, N., & Dehoney, J. (2015). What's Next for the LMS? EDUCAUSE Review, 50(4), 40–50. Retrieved from https://edtechbooks.org/-QaM

    Chen, C. M., & You, Z. L. (n.d.). Community detection with opinion leaders’ identification for promoting collaborative problem-based learning performance. British Journal of Educational Technology, 50(4), 1846–1864. Retrieved from https://edtechbooks.org/-IQx

    Levasseur, R. E. (2001). People skills: Change management tools - Lewin's change model. Interfaces, 31(4), 71-73. Retrieved from https://edtechbooks.org/-FCZa

    Wright, C. R., Lopes, V., Montgomerie, C., Reju, S., & Schmoller, S. (2015, April 21). Selecting a Learning Management System: Advice from an Academic Perspective. Retrieved February 13, 2020, from https://edtechbooks.org/-rVL

    Thomas Dorgan

    Thomas Dorgan is the Learning Management System Manager at the University of North Carolina, Wilmington (UNCW). He holds a B.S. in Secondary Education from State University of New York at Oswego and an M.S. in Instructional Technology from UNCW. Tom began his career as a middle school computer resource teacher before transitioning into higher education in 2008. Focusing more on the technical aspects of teaching and learning, Tom worked at the Savannah College of Art and Design as a Learning Management System Administrator prior to coming back to UNCW as one of the LMS admins and eventually managing the LMS team.

    This content is provided to you freely by EdTech Books.

    Access it online or download it at https://edtechbooks.org/learning_management_systems/implementation_and_transition.