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 http://moodlemoot.ie

1. IRELAND & UK
MOODLEMOOT
2012
Daniel McSweeney
Kyle Goslin
Institute of Technology
Blanchardstown

2. Twitter
@DanielMcSweeney
@KyleGoslin

3. Moving to Moodle 2.3 from 1.9 -
Our experience bridging the gap

4. PRELUDE
Moodle moot 2012 was a
great experience but also
unnerving!
Lots of presentations on
moving from Moodle 1.x to
Moodle 2.0 and 2.1
Very few stories ended with
“it was all so simple and
went really smoothly”

5. SEE MY SCARS!

6. OUR USE OF MOODLE
•Started moodle use in 2003
•First year we had 3 courses
and 80 students (approx.)
•2012 we had grown to just
under 2,000 modules and a
user base of almost 4,500
•Core academic system

7. OUR PROBLEMS - INFRASTRUCTURE
• Our moodle server was a little on the old side…..

8. OUR PROBLEMS- DATABASE
• Our database was a
little bloated
• Years of data and
updates, tweks etc
• Did we really want to
update this to moodle 2?

9. OUR FILING SYSTEM
• Years of data and files
collecting on server
–Old courses
–Backups
–Redundant or removed files
–JUNK!!
• Asking users to clean
folders does not work.

10. THE IDEAL SOLUTION
Start 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. THE GOAL
1. 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
courses
4. We needed the process to be seamless / encapsulated
from our end users.

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

14. 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.

15. 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

16. 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

17. 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

18. Records of
courses for
migration
Moodle 2.3 Box
Moodle 1.9 Box
Backups

19. THE EASY PART
Purchased new server
1. Single box solution – not ideal BUT meets our needs
2. Running IIS and FastCGI
3. SHAMELESS PLUG – Gavin Henrick hired to manage
install and configuration
4. Installed Moodle 2.3, clean setup – no courses etc

20. 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 moodle.org
• New release due by end of February
• Used by freemoodle.org!

21. 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

22. COURSE REQUEST MANAGER

23. COURSE REQUEST MANAGER

24. COURSE REQUEST MANAGER

25. COURSE REQUEST MANAGER

26. COURSE REQUEST MANAGER

27. COURSE REQUEST MANAGER

28. MANAGING MODULES FOR
MIGRATION

29. What we and they expect
Academic Staff
- Have their course
- Have new features
- Nice and new Moodle
with great new features

30. What we and they expect
Moodle Admin
- Have a moodle ready on time
- We don’t lose too much data
- It actually works as expected
- No arguments!!

31. What we needed to do..
1. Get rid of all junk data and old user accounts
2. Set up the new servers physical hardware
3. Set up new server with Moodle 2.3 and clean DB
4. Keep staff data
5. 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 needed
7. Switch to the new server with as little down time as
possible

32. Migration Link
Link added to settings of course page to allow the
lecturer to flag the course as being ready for
migration to the new server
Serves 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

33. Migration Link

34. Course Page Notice
Little notice added to the top of the course page to say that the course
has been flagged for migration

35. 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…

36. And then all courses were migrated to the new
server!

37. 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.

38. Migration Manager
A simple interface was created on the old Moodle 1.9 server to
keep track of the status of the backups.

39. Migration Status
1 - Flagged for migration
2 - Backup process completed
2F - backup process failed
3 - Course has been migrated successfully
3F - course migration has failed
3 - 10 All other strange combinations and failures we identified
during the process.
Some really strange combinations did happen
as a result of browser crashes, timeouts, gremlins & leaving it for too
long without looking…

40. 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

41. Status Review

43. Selecting number of instances to run per call

44. 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.

45. 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)

46. Restore Manager
A Restore Manager was created on the Moodle 2 box, which
consisted of one feature, the “Dispatcher”.
The dispatcher selected a record from the list of backups and
then ran the Moodle process to restore a course.
A little hack was done on the restore process to “automate” this
process

47. Automated Restore
1. We had the name of the original
course catalogue location
2. We had a catalogue that looked like
the original 1.9 catalogue
3. The Moodle course restore
functionality already existed

48. Automated Restore
How 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 restore
2. 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
successful
6. The window was closed
7. The dispatcher launch the next course to be restored

49. 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!

50. 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.

51. 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

52. Old Server – Archive

53. 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.

54. Avoid

55. Questions?