Thursday, May 19, 2011


Ask My Readers: CMS Migration

Wise and worldly readers, I need the benefit of your experience.

This summer, my college will migrate from one Course Management System to another. (A CMS is the web platform used to run online courses or the online components of hybrid courses. Common examples include Blackboard, WebCT, Angel, Desire2Learn, Moodle, and Sakai.) The motivation is partly based on features, and partly based on a history of shoddy treatment by the sole vendor of a proprietary product.

I’m not entirely sure what to brace for this September, when the new system goes ‘live’ with a huge influx of new students.

We’ve got technical staff migrating existing online courses from the old platform to the new, and we’re running training workshops over the summer so online faculty can get up to speed. I’m told that the difference is akin to the difference between web browsers, so someone who can use one well can learn another without too much difficulty. Of course, the devil is always in the details, and I’ve been through enough tech adventures over the years to know that little things can quickly become big things.

My question is really for those of you who’ve been through CMS migrations before. Where are the land mines? What should I brace for? Having been through it, what do you know now that you wish you knew then? Or is it really not that big a deal?

Public comments are always welcome, or I can be reached at deandad (at) gmail (dot) com.


The key issue will be how well it handles a huge influx of students.

There's the issue of quickly creating accounts for each student and getting them linked to the right courses. Sounds obvious, but my employer used a system which required each account be created by hand (the vendor was used to business systems, where new hires don't outnumber permanent employees by two orders of magnitude). The new system is better, but we still wait up to two months for a new student to get their own account.

Reliability is an issue. Some minor problems scale exponentially. Again, our promised system(1) crashed under the load of full implementation, and they seem to have decided to scrap it.

Platform support is another issue. If you don't require students to have a particular platform, then make certain that it works under something other than Windows and Internet Explorer.

(1)Academic Workspace was the name given. No idea what the underlying technology was, except that it needed Microsoft Silverlight to be installed on computers accessing it. And they were very proud that every instructor got 500 MB of storage for course materials, student work, etc. (Yes, that's megabytes — which gives you an idea how out-of-touch the system designers were with what actually happens in a computer-enabled classroom.)
It is one thing for faculty to know how to use the new system as a result of the summer training workshops. What about students? Get your support folks to provide a step-by-step guide for students, explaining (at a minimum) exactly how to access this new system. We are finding that to be a much bigger deal to the students than expected, as we migrate.
Going along with Anon 4:25, adequate IT support for students is a must - because IT support for students is, actually, IT support for faculty. If as a faculty member I'm spending all my time trying to teach students to use the technology, I am not able to teach the content of my course. That is not a good thing.
Do you know if the login details will be the same? If not, get prepared for m a n y support calls. Also, if faculty still have access to the old CMS, you probably want to remind them to back up their stuff (grade records, files posted to the site, etc.), even if old courses are going to be copied to the new system.
We've just gone through a migration, from Blackboard to Moodle. From my perspective as a faculty member, the switch was welcome. I'll shed no tears for Blackboard, and there's lots I like about Moodle, including the open source model.

Faculty members will need to be involved/consulted on the migration of their specific courses, even if technical staff are doing most of the heavy lifting. The organization of the course site could be different enough that there needs to be thought given to that organization. That was true with Blackboard, which makes heavy use of folders and sub folders, versus Moodle which does not.

The least concern is with the students. It's just another web site to them, and even older, non traditional students pick it up quickly - particularly if the new organization style is straight forward. A technical challenge could be the new authentication/log in for the new system. IT can assure you they have it covered, but implore them to beef up their Help Desk resources when the students arrive.
I am managing this process for my own institution right now, and am one of many hundreds of institutions going through this as everyone jumps ship for the open source options. We are, in a sense, coddling our faculty by doing everything we can to make it their experience of course creation, rostering, and conversion of old sites seamless. But the big thing that I have to keep reminding our faculty is that students will adapt quickly. They are not the technical gods that some faculty assume they are, but if you put a web-based platform for communicating in front of them, they'll usually figure things out. The glass is half full (which I have to believe, or else I'd pull all my hair out over this transition) -- if you don't have much choice about a change, find a way to use the opportunity with faculty to talk and think about what they do in the CMS. Of course, it's a different story for fully online learning, and a much bigger deal since any change to how you use the CMS for a specific course involves lots of people, but generally speaking my goal is to convince faculty that it's a good opportunity. Plus, we're saving money and faculty always like to hear that other groups on campus are tightening their belts....
Migrating from one platform to another will have to be a larger pain than migrating from one version of a pplatform to another version of the same platform, right?

Well, we're into year z (it's taking so long I can't quite remember when we started this) of migrating from one version of Sakai to another. The testing module has yet to be completed satisfactorily (no joke; but it's not like testing is a crucial part of a CMS or anything) and won't be until after I retire (also no joke; it's *scheduled* for completion by the fall of 2012 and I'm gone in May 2012).

I'm fully in accord with what Anon (at 2:53 AM) says. Our single largest problem is the freeze-up of the system *every semester* for the first week or so. Its eems unable to handle an extremely predictable load.

Anon (at 4:25 AM is also correct. Students will need to learn the new system as well. If your institution is like mine (a fair number of older students), that transition will also be somewhat difficult (but less difficult, I think, than for the faculty).

Have fun (heh) and let us know how this transition goes...and how the next upgrade goes.
Well, if you conducted a pilot, you should already have some sense what some of the issues are likely to be, right?

I certainly hope that you've conducted a limited pilot, where some courses migrated to the new CMS to see how it went. If you haven't done that, oh boy, you are running a live experiment on all your students and faculty -- is it too late to delay and roll out the new CMS to only a subset of classes?
I think making sure there is a training session on the new software adjuncts can actually attend is hugely important. As an adjunct I've been asked to learn three different CMSs in four semesters and only got trained on one of them. Training at 10:00 am or 2:00 pm is not useful to those of us who have full-time jobs elsewhere, which is every adjunct in my program.
Have a pilot over the summer with a limited number of faculty spread across the campus so there are a few expert early adopters in each department.

Make the course shells available in the summer so that people can start migrating their stuff and tinkering before the Fall.

Consider purchasing software like Respondus which makes migrating exams between platforms easier and get some free or low cost licenses for individual faculty who are willing to be part of the pilot.

Write up a change document for faculty (including adjuncts!) which summarizes the major differences between the two platforms.

All things being equal, I would have Fall be your pilot with a robust number of participants and go campuswide in Spring. It would allow you to give the system a test with a real semester but with early adopter faculty who are more likely to have patience with the inevitable bumps and hiccups that are a part of this kind of change. With all the crazy of Fall with new students and classes and everything else, it might make sense to push this little piece of stress off some.
That freezing people are talking about is almost surely a hardware issue, which if you're hosting your own stuff is your system administrator's issue. I suspect the load at the beginning of a year is higher than at other times and perhaps even higher because it's a shiny new thing.

I came on board after a migration, and people complained about it for years afterwards. If you don't make the training sessions mandatory, only the faculty that are interested (all 3 of them) will show up. The other 275 will either figure it out or complain loudly or freak out in some way. Be prepared for that. Better yet, offer a token prize if you can. People like that.

It'll be bumpy, but it will all work out in the end.
As any transition, it needs to be prepared. And much of it has to do with diverse users whose diverse needs and attitudes may imply diverse reactions.

[I'm not an administrator and I haven't been that directly involved in LMS transition, but I've been observing the LMS scene for a while and my experience is relatively diverse, teaching at eight institutions using five different LMS (Sakai, Moodle, Oncourse, Blackboard, WebCT).]

During these transitions, teachers need to be accompanied, as much as possible. Appropriate tech support is essential, of course, but it's even more a question of bringing people through the transition. At least, if you want them to appropriate the new platform, to use it in a way which actually enhances learning and facilitates teaching, instead of being a burden.
Concordia, where I've been mostly teaching during the past few years, transitioned from an in-house platform (Site Generator) to Moodle, back in 2005. I'd say the transition isn't even over. Sure, people can't use the old platform. Every course has a Moodle site (outside of the business school, where they use FirstClass!). And many people are used to Moodle. But as was painfully obvious during a MoodleDay event in which I participated with a colleague from our Centre for Teaching and Learning Services, Concordia isn't using Moodle very appropriately.
Part of it is lack of human resources. There's pretty much one person handling Moodle for the whole campus (40k+ students, IIRC). But there's also been a lack of insight in the transition itself. It's been treated as pretty much a technical issue, disconnected from pedagogy.
Haven't mentioned students, yet. They're the main users of the platform and they matter a lot. And the Prensky-style “digital native” ideas often miss important points about students. In my experience, students' comfort level with learning management systems is much lower than administrators realize. But there are key things about students which makes them more indirect targets in LMS transition.
One is that they're there to learn. If learning the LMS is framed as a learning experience, chances are that a rather large number of students will be able to transition efficiently from one platform to the next. In fact, it can be a great occasion to have students involved in discussions about pedagogical issues or even about the future of the academic institutions. There's a lot of things to discuss when community colleges and public universities “compete” with for-profits, Khan U., tutorial services, on-the-job training, and even personal learning networks. A migration of this kind is an ideal context. Even something so simple as animating a forum about the migration can produce amazing results in terms of both learning and consultation. But it's still not the primary target of the transition. The transition can be relatively smooth without it.
The other dimension which makes it counterproductive to target students that directly is the turnover. New students are already migrating from other environments, including other LMS. Upper-level students may not care so much about the transition if they're getting ready to leave anyway, going to new environments. And those in the middle need not be that tricky a challenge if everyone has been prepared.
In other words, if instructors have made the transition, it's much easier to get everybody else on board.

Including, hopefully, non-teaching staff. Just think about the power given a course-based platform when it's being used to organize campus events, send internal memos, notify the community about pressing issues, or even keep track of the institution's media coverage. Portals have typically been used for this but LMS can be even more powerful. It requires a bit of care, maybe, but it streamlines a lot of things. I know it may sound weird, but please give it a thought.

Overall, this type of transition can go relatively smoothly if you think about broad issues, not just narrow ones.
First, I hope you have looked at browser and hardware independence before making the switch. Does it run under Firefox and Safari, and on Macs, not to mention iPads, or just one specific version of IE under Vista?

I mention the iPad because "flashy" systems don't work there. It is important to tell students in advance that your CMS will not run on certain systems.

Second, our college is treating migration from one version of Bb to another version of Bb about as carefully as a switch from one CMS to another. It is already being used in some classes this summer before a full roll out in fall, and we will get access to our fall courses at least a month before the semester starts. Whether bugs that have reportedly been found will be fixed by then is a separate issue!

However, at least we know that single signin works and students are being put in the right place when they register for that section. We also get experience with how it integrates with courseware from the textbook publishers, and the guinea pig faculty can also gives tips on what to prepare for and what students might need to be told.

Here is hoping it works when running full scale in the fall!

PS -
I don't like the term LMS. You can't manage learning, you can only facilitate learning with a good CMS along with faculty that integrate those tools into the courses, both f2f and online.
Two thoughts as someone who just transitioned from Blackboard to D2L.

(1) What feature do the students use most? Instead of hiding this in a big long list of links, bring it up front. In our case, it is the dropbox feature, hands down. Make this location OBVIOUS to the student. Also, make sure that the 'save as draft' button is clearly marked as such so it doesn't get mixed up with the 'ok'=submit button.

(2) It is not enough to run pilots and trainings. Take 4 different professors who teach the largest class size in your college. Set up some sort of faux assignment for that largest class. Then ask them to test their work flow for grading. HINT: If it takes 4 clicks per student, it will make 75 person or even 36 person courses are painful. Repeat with the class divided into permanent small groups. (It is actually fairly ironic that D2L will give you all these pedagogical hints about small groups but utterly fails in easily linking 5 groups to one grade.)

Finally, my personal pet peeve about D2L is the insistence on having it so damn flexible that you have to create everything in 3 places (the assignment in a dropbox, the grade book, the course content) with 2-3 date options a piece (release, due, exception date... all often hidden behind tabs, etc) that then have to be linked! It takes forever and is very easy to mess up nuanced due dates because you think you've hit one thing and really you did a similar process elsewhere.

Ahhh. That felt good.
We're in the middle of the LMS evaluation phase, trying to figure out the difference in the gradient of the implementation curve from one solution to another. I've come to the conclusion that the answer is: steep, in all cases.

Regular, reliable and realistic communication will make the difference between an awful experience, and something that brings people together. If you're candid about how tough you expect it to be, everyone will be prepared for the things that can go wrong, and they'll feel appreciated for the extra effort they'll have to put in. If you also put aside a thank you budget to get your key technical and faculty together to celebrate milestones, you'll send a strong message.

Whatever vendors tell you, they care much less about your faculty, adjuncts and students than you do.
Coming late to the party, a question:

Can anyone recommend a good app for the iPad/Mac that will let me handle standards using most-recent/most-consistent grading?

I'm currently using EasyGrade on my Mac and Palm Pilot, but the old Palm probably won't last another year. I love EasyGrade and the way I can track each student's progress towards the 100+ mandated expectations, but I'd much rather use an iPod/iPad in the classroom than carry my computer around.
I'm with fivetomatoes. I've worked with Blackboard a bit in the past, and we switched over to Moodle. Our CC has wanted me to take multiple training sessions, which were offered during normal working hours, when I was at my other job. The guy who does Moodle has a bit of an obsession with us being properly trained, which I would support, if it weren't for the fact that I've used Moodle before, and the training exams feel like scavenger hunts for answers.

But, it's mostly six of one and half a dozen of the other as far as switching. The people who used the old system will continue to do so well, people who struggled will continue to struggle.
Any college system should be introduced in the summer semester so you CAN find the problems with fewer course/profs/students
My main advice is to staff up with reasonably competent IT people on short term contracts. Even someone unfamiliar with your system can handle basic hardware maintenance and "free up" your core staff for managing the transition.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?