« Impact 2006: Thursday Session 6: Automating Adminstrative Processes | Main | Impact 2006: Friday Session 2: Decentralized Administration and Faculty Support »
July 17, 2006
Impact 2006: Friday Session 1: How we Made Vista 4 Work - Administration and Migration
This session discusses how Northern Arizona University handled setting up their Vista 4 system.
For more, see http://www2.nau.edu/~d-elearn/conference/
Some Stats
This fall they had 80,000 enrollments in over 6500 sections. They make a course shell for every course offered. Their University has 30,000 students in one course, "Orientation to IT Survices".. They also have all their library e-reserves online. They are also using Elluminate (web conferencing), TurnItIn (plaigerism detection) and ITV (streaming video) powerlinks.
Migration
They started out over a year ago by migrating from CE 4.1 to Vista 3 in a pilot project. In the middle of the pilot, Vista 4 was announced. So they decided to migrate the remaining systems directly to Vista 4, then do a further migration of the courses already moved to Vista 3. They found the Vista 4 migration much easier, with much better migration tools.
Here's a list of things they did related to migration:
- They reviewed all classes before migrating the class.
- They realized most classes will require some sort of cleanup after migration
- They developed a recipe that students could follow to do this cleanup then trained four students to do this task.Thge recipe for Vista 4 ended up being about 1/3 the size of the recipe for Vista 3.
- They developed a "Migration database" to track the migration status of all classes. that makes sense for 6500 sections, but may not be necessary for our system.
Their migration database had some interesting features:
- Central IT / learning centre staff did the initial migration for the faculty. This was to make sure some of the strange issues with the migration were handled properly.
- The users had a "migration request" form where they indicated what courses they wanted to migrate (one at a time). They found it easier to ask people to cut and paste the course URLs into this form to avoid confusion. They also asked when the course should be migrated, and when it would next be taught.
- The data entered went into a database, where the hired students reviewed the form for correctness, checked the priority, and updated the status as they migrated the courses.
- Priority was set based on how soon the course is to be taught, and how much time was between the migration date and the teaching date.
- There was also areas for the college dean, department heads, etc. to enter comments related to the course migration.
- All migrations were initiated by the end users. Whatever was not asked tio be migrated was left behind.
- A report was written to give to the instructor noting any problems, etc.
Lessons Learned:
- Communication is key. You must drill into people that the old server is disappearing, and they need to migrate their courses. Don't let them wait until the last minute. Communicate early, and often.
- Utilize student workers if possible.
- Give users a blank shell option instead of migrating old courses. Some users may want to simply start from scratch.
- Run some "migration labs" to help instructors with the migration. A place where they can go to get assistance during the migration.
- When using students, make sure they don't have access to live data. Give them the big scary "FERPA" speach (they could be expelled for poking about, etc.)
- It takes time to move courses between multiple servers.
- Have dedicated instructor support, and dedicated student support.
- It is good to have several administrators to cover for each other for vacations, etc.
Posted by kvl014 at July 17, 2006 12:48 PM