Mootie13 Moving to moodle 2.3 from 1.9 - our experience bridging the gap


Published on

This paper / presentation outlines a the practical solution, pitfalls and problems encountered over a two month period during the migration to a Moodle 2.3 server for the looming deadline that is the start of the academic year in September 2012.

Presented by Kyle Goslin and Daniel McSweeney at

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mootie13 Moving to moodle 2.3 from 1.9 - our experience bridging the gap

  1. 1. IRELAND & UK MOODLEMOOT 2012Daniel McSweeneyKyle GoslinInstitute of TechnologyBlanchardstown
  2. 2. Twitter@DanielMcSweeney@KyleGoslin
  3. 3. Moving to Moodle 2.3 from 1.9 -Our experience bridging the gap
  4. 4. PRELUDEMoodle moot 2012 was agreat experience but alsounnerving!Lots of presentations onmoving from Moodle 1.x toMoodle 2.0 and 2.1Very few stories ended with“it was all so simple andwent really smoothly”
  5. 5. SEE MY SCARS!
  6. 6. OUR USE OF MOODLE•Started moodle use in 2003•First year we had 3 coursesand 80 students (approx.)•2012 we had grown to justunder 2,000 modules and auser base of almost 4,500•Core academic system
  7. 7. OUR PROBLEMS - INFRASTRUCTURE• Our moodle server was a little on the old side…..
  8. 8. OUR PROBLEMS- DATABASE• Our database was alittle bloated• Years of data andupdates, tweks etc• Did we really want toupdate this to moodle 2?
  9. 9. OUR FILING SYSTEM• Years of data and filescollecting on server –Old courses –Backups –Redundant or removed files –JUNK!!• Asking users to cleanfolders does not work.
  10. 10. THE IDEAL SOLUTIONStart again with • A new hardware setup • A clean instance of Moodle 2.3 including clean database and file system • Migrate all required courses to the new server • Allow staff to set up new courses where migration was not required (a new system for requests would be required) • Migrate uers to new system
  11. 11. THE GOAL1. We needed to design a process that could be designed and implemented by two people.2. We needed a process that would allow our users to mark their courses for migration. It needed to be very simple quick and foolproof.3. We needed the process to automate the backup of marked courses on 1.9, to move them to the new server and to restore them into new Moodle 2.3 courses4. We needed the process to be seamless / encapsulated from our end users.
  12. 12. FIRST STEP - INFORMING USERS • Academic staff informed before summer break of 2012 • I informed them that the migration would require them to mark courses for migration. • Set timeframe. • One time only offer • Provided an overview of the advantages of Moodle 2 • We advised that many courses could be rebuilt in minutes on Moodle 2.3 using drag and drop • I then demonstrated the drag and drop feature
  13. 13. STAFF REACTION• Very positive• For them the drag and drop function was the first major improvement in saving them time and making moodle easy to use.• Concerns over availability of courses at the start of the semester and risks• Wanted a full picture on how this would affect them.
  14. 14. OUR ENVIRONMENT• Our migration was simpler than many larger scale sites • Users authenticated via LDAP • Did not need to migrate users and activity as we were doing this over the summer break (clean slate in September) • Not integrated with any student enrolment system, we use enrolment keys • Mainly use core plugins or plugins that have a history of development • Our migration issues where therefore somewhat simplified
  15. 15. THE PLAN – OLD BOX• We needed to add a simple link to the admin panel on the view course page which would allow users to mark the course for migration• The view page should display an obvious migration status at the top of the page.• Once selected, the migration function needed to record • Details on the course to be migrated • The user ID of the requestor • Invoke a backup
  16. 16. THE PLAN – NEW BOX• It should have access to the database of the old box• Read list of courses to be migrated• Process one record at a time• Copy backup across from moodle 1.9 box• Restore into new module on 2.3 box in same category• Restore all academic users
  17. 17. Records of courses for migration Moodle 2.3 BoxMoodle 1.9 Box Backups
  18. 18. THE EASY PARTPurchased new server1. Single box solution – not ideal BUT meets our needs2. Running IIS and FastCGI3. SHAMELESS PLUG – Gavin Henrick hired to manage install and configuration4. Installed Moodle 2.3, clean setup – no courses etc
  19. 19. SETTING UP NEW COURSES• We needed a way to quickly manage large quantities of requests for new courses which users chose not to migrate.• We didn’t feel that the current course request feature in Moodle core worked for us• Over a few months we developed course request manager plugin for moodle • Now available from • New release due by end of February • Used by!
  20. 20. COURSE REQUEST MANAGER• Add a request block to frontpage• Approved users can request courses• Administrators can • build their own customized request forms • Quickly approve, deny or comment on requests• Users sent confirmation emails etc with enrolment keys• Saves hundreds of hours work at the start of each semester
  28. 28. What we and they expectAcademic Staff- Have their course- Have new features- Nice and new Moodle with great new features
  29. 29. What we and they expectMoodle Admin- Have a moodle ready on time- We don’t lose too much data- It actually works as expected- No arguments!!
  30. 30. What we needed to do..1. Get rid of all junk data and old user accounts2. Set up the new servers physical hardware3. Set up new server with Moodle 2.3 and clean DB4. Keep staff data5. Link in with LDAP system and existing mail server.6. Keep the older server live as an archive to allow staff to go back if needed7. Switch to the new server with as little down time as possible
  31. 31. Migration LinkLink added to settings of course page to allow thelecturer to flag the course as being ready formigration to the new serverServes Dual Purpose:- We know what courses are ready to be migrated- Non-flagged courses are not longer needed on the new server: e.g. automatically cutting down what needs to be moved
  32. 32. Migration Link
  33. 33. Course Page NoticeLittle notice added to the top of the course page to say that the coursehas been flagged for migration
  34. 34. Flagging for migration• Lecturers were given a time window to flag their course for migration.• If they did not migrate their course, they would need to request a blank course to be created, nothing would be carried over for them.• As usual, a handful of lecturers, forgot to, were too busy, weren’t bothered to click the link.• This process was repeated only once to allow the last few courses to be flagged for migration…
  35. 35. And then all courses were migrated to the new server!
  36. 36. Migration Process• During the night at a quite period, a custom cron job was created that would select courses that were flagged to migration and backup the course.• ID numbers of the course and associated lecturers user IDs were saved along with the backup of the course.• A modified backup process was creating allowing specific resources to be included or excluded from the backup process.
  37. 37. Migration ManagerA simple interface was created on the old Moodle 1.9 server tokeep track of the status of the backups.
  38. 38. Migration Status1 - Flagged for migration2 - Backup process completed2F - backup process failed3 - Course has been migrated successfully3F - course migration has failed3 - 10 All other strange combinations and failures we identifiedduring the process.Some really strange combinations did happenas a result of browser crashes, timeouts, gremlins & leaving it for toolong without looking…
  39. 39. Cron Backup• A custom variation of the backup process was created – To cut down on the amount of junk retained all created user data was discarded from the backup – All modules and resources to be retained were specified before the cron is run• An admin account was given to the backup tool which had a public cron interface• External cron service called the page and ran the number of specified backup instances during every call e.g. 2• If completed successfully, the status was changed to 2
  40. 40. Status Review
  41. 41. Selecting number of instances to run per call
  42. 42. File Transfer• Once all the backups were created the files had to then be moved from the 1.9 server to the 2.0 server.• The files were simply put into a public directory and and automatic downloader pulled down all of the backup files.
  43. 43. Moodle Course Catalogue• To keep things tidy, the original course catalogue was set up in the new course.• This wasn’t a very time consuming process and would ensure that all the courses could be placed in the correct location (matching old location to new location)
  44. 44. Restore ManagerA Restore Manager was created on the Moodle 2 box, whichconsisted of one feature, the “Dispatcher”.The dispatcher selected a record from the list of backups andthen ran the Moodle process to restore a course.A little hack was done on the restore process to “automate” thisprocess
  45. 45. Automated Restore1. We had the name of the original course catalogue location2. We had a catalogue that looked like the original 1.9 catalogue3. The Moodle course restore functionality already existed
  46. 46. Automated RestoreHow we did it…A browser based restore tool was then created to automate the process.1. A record was selected containing the backup information and a window was opened to run the restore2. A string match was done using the original catalogue name and the new catalogue name (it did get a little messy!)3. Some JavaScript was added to the top of the original restore process page that took into consideration the current step of the restore process and even the title of the page to help identify the steps it was on.4. Once we were identified the page we were on, we dynamically set defaults and moved onto the next page allowing the restore process to be automatic.5. When a restore was finished, the record was updated to say the restore was successful6. The window was closed7. The dispatcher launch the next course to be restored
  47. 47. A little overlooking..• The new enrolment process was modular• … We didn’t create any enrolment records to allow people to manually enroll in courses…• … No lecturers were assigned to the courses ..• A bridge was then created to take the original roles of the staff and then create the associated enrolment records in the Moodle 2 server along with enrolment records to allow students to manually enroll in the courses!
  48. 48. Conclusions• Sometimes* the process did fail, when it did some duplicate courses were created. These generally were not to much hassle to clean up.• If a catalogue location wasn’t found, things where just thrown into the “Miscellaneous” category.• It helped to keep an eye on things, because when it fails, it really fails.• Overall only about 5 courses oficially failed the process and needed to be manually recreated.
  49. 49. Post the migration process• Staff offered 2 hour training workshops on new moodle.• No attendance at a workshop meant no support.• Series of support videos and screencasts added to moodle to assist.• Additional staff added for supporting staff queries
  50. 50. Old Server – Archive
  51. 51. Whats next?• Move to Moodle 2.5 in late summer• Upgrade server to SSD and performance tweaks.• Look to build in greater levels of failsafes etc.
  52. 52. Avoid
  53. 53. Questions?