SNL Online is in full mobilization mode preparing for the migration of eighty-eight online courses from Blackboard to Desire2Learn. A lot of experienced, well-educated, and well-intentioned folks have argued for a university-wide switch, and so we will have it.

Like all real change, the migration is and will continue to be disruptive; old ways of producing, teaching, and taking online courses will necessarily be uprooted and swept away with new theories and practices. Already there have been revelations and lessons learned; here are a few thoughts:

Hope for the best; plan for the worst.

D2L has a migration tool that was pitched as a magic bullet that would make moving over course content a breeze. That’s likely true for certain kinds of course configurations under certain conditions. Your results may vary. Ours certainly did: our requirements for course structure and design make the migration tool essentially useless, and migration will take more time and resources than anyone had imagined.

The demo is not what you’ll get.

Know how automotive writers always insist you drive the exact make, model, and trim level you intend to buy? On the roads you normally drive? The same principle holds true with your new LMS. We’re discovering to our dismay that some of the key features we’d planned on using in our new course designs don’t work when D2L is integrated with other systems—PeopleSoft in our case. The IS boys and girls at our university strongly suggested this might be the case, and so far they’ve been right. Not the end of the world, but definitely a buzz-kill.

Test. And test again.

This certainly applies to the LMS and its features as a whole (see above), but here I’m thinking about our actual course template, or master design. What was argued for in design-planning meetings as being best for users turned out to be unwanted, disregarded, or disliked by actual users in actual user tests. We took the results, revamped our designs, and will run more user tests. User tests aren’t infallible, but they help us make informed decisions and, we hope, better user experiences.

Get everybody on board.

Migrating from one LMS to another is a huge, complex endeavor. We realized early on that a successful migration was going to be more than just our instructional-design team could handle; course authors had to be consulted, faculty needed to be trained, student workers hired and trained, roles and permissions within the LMS defined and assigned, tasks identified, processes created and tracked—and all this in addition to the actual design and reconfiguration of courses.

Our school’s operations team excels at project management and planning, so our design group met with them to map out the project and set up systems to implement, record, and track our process and progress. Seeing all our tasks written on sticky notes and posted to the wall was intimidating at first, but it gave us a realistic look at the challenge we faced and a means of organizing, prioritizing, and delegating. While the project is still enormous, we now have a plan and structure in place that will help us succeed.

Remember to breathe.

While certainly daunting when looked at as a whole, the project is really a set of discrete tasks, most of which can be broken down into still smaller tasks. If I remember that, and take some deep breaths every now and then, there’s actually a certain amount of fun involved. Then migrating to a new LMS becomes just a complex puzzle to be solved, and I can concentrate on finding and fitting the appropriate pieces. Stay tuned.