I will attempt a short chronicle of everything including problems encountered.
We are running Linux on a shared hosted server.
Our upgrade path was from 1.9 to 1.9.19 to 2.2.11 to 2.8.5
The easy upgrades were from 1.9 > 1.9.19 and the 2.2.11 > 2.8.5 which really had no issues did not take much time. The "problem" upgrade was from 1.9.19 > 2.2.11
Here is a summary of a lot of the links that I read before/during the upgrades to help me out. It is worth your while to read the all BEFORE you start so you can have an idea of the problems you may encounter:
https://docs.moodle.org/19/en/Upgrading This is for 1.9 but you change the version and review from 1.9 up to 2.8
https://docs.moodle.org/20/en/Upgrading_FAQ This is for 2.0 but you can change the version and review from 2.0 up to 2.8
https://docs.moodle.org/19/en/Legacy_course_files This is for 1.9 but you change the version and review from 1.9 up to 2.8
UPGRADE 1.9 to 1.9.19
This is where I did all the major preparation work. You want to do this BEFORE you do the 1.9.19 to 2.2.11 upgrade.
(1) Turned on Maintenance Mode and did the backups of moodle web folder, moodledata folder and moodle database.
(2) Check plugins: Installed a separate test moodle installation of 1.9.19 and compared what plugins were the standard ones versus what ones we had added to our version. Go to Manage Blocks and Manage Activities to do this. Fortunately for us, any additional plugins beyond the standard ones that our 1.9 version had, were not being used, so I just deleted all these extra ones. Test your site to make sure it is still working properly.
(3) Changed the theme to the "standard" theme. This is important because the standard will work from 1.9 to 1.9.19 to 2.2.11 and it will automatically get updated to the Clean theme from 2.2.11 to 2.8.5. By switching it now, you just have one less thing to worry about for the rest of the upgrades. Test your site to make sure it is still working properly.
(4) Did all the required database upgrades including switching it all to utf8 (collation = utf8_unicode_ci) and switching it to InnoDB engine. Test your site to make sure it is still working properly.
(5) The other database issues I fixed were the Indexes and Bigints. To check these go to XMLDB editor and run Check Indexes and Check Bigints, then use the provided SQL statements to fix db. Test your site to make sure it is still working properly.
(6) Go to moodle/admin/health.php and fix any issues that show up here as well. Test your site to make sure it is still working properly.
(6) Last step just before upgrade was to add password SALT to config.php ( $CFG->passwordsaltmain = 'my-really-long-salt-string'; ). Make a COPY of your config.php and change the copy, not the original one. This is another important step to do now so you do not have to worry about it for the rest of the upgrades.
(7) UPGRADE: Remember do NOT overwrite your existing moodle web folder. I just rename the moodle web folder to moodle19orig and then download/extract v1.9.19 into a new moodle folder. Copy over the modified copy of your config.php file with the salt and then go to moodle/admin page and the upgrade should start.
UPGRADE 1.9.19 to 2.2.11
All the major preparation work was done back in the 1.9 > 1.9.19 upgrade, but this is still where I had the most problems. I think had to restore everything back to 1.9.19 at least 6 times before finally getting a proper upgrade to 2.2.11. The three major issues I ran into was (1) server timeout and (2) legacy files being moved to repository and (3) restoring site back to 1.9.19 which is tedious and can take a long time (especially on a hosted shared server). Here are some hints to help you thru these issues:
HINT #1 - Server Timeout (500 Internal Server Error) - There is lots of info on how to change your php setting timeouts and memory limits, but the issue turned out to be something that I could not access myself. The first 3 times I tried to upgrade the process stalled at the 30 minute mark with a 500 Internal Server Error. With the help of the great support at my webhost, they determined that the issue was a php setting called mod_fcgi which was set to a max of 30 minutes. They temporarily raised it to 120 minutes for me which ended up being sufficient.
HINT #2 - Legacy files being moved to repository - All your files in moodledata will get moved to non-human readable filenames but will remain in moodledata. I had about 60 large .zip files ranging from 20MB to 50MB in size that were linked from courses that users could download. I made two attempts to upgrade were the upgrade completed but all my linked files gave the dreaded error "This legacy resource type (file) was not yet migrated" which then caused all my links to files (not just the links to the big files) to be invalid and not work. My final solution was to create new versions of the zip files with the same name, but they simply contained an empty text file, so the size was very small. (Remember to backup the original ones before you replace them). This time the upgrade went thru fine and all the links were working fine. The only downside to this method is I had to go into all the courses after the upgrade and replace these zip files that contained the small text files with the original big zip files. However at least all the links worked!
HINT #3 - Restoring back to v1.9.19 - If you have never had to restore a site back to previous state, then I recommend you install a test version of older version of moodle, back it all up, upgrade it, then restore it back to the previous version. It is NOT as simple as "I backed everything up so it should be fine"! So do your regular backups however you normally do them, but then do this as well:
- copy moodledata folder to moodledataBACKUP1919
- copy web folder moodle to moodleBACKCUP1919
- using cPanel create a new empty database called my_moodle_dbBACKUP1919
- using phpMyAdmin set the new database collation to utf8_unicode_ci
- using phpMyAdmin copy your my_moodle_db to my_moodle_dbBACKUP1919 (use the OPERATION tab and UNcheck the "create database" option
If the upgrade fails and you need to restore back to the previous version you can just do these steps and have it back up and running about 10 minutes:
- delete the web folder moodle
- delete the moodledata folder
- using cPanel delete the my_moodle_db database
- using cPanel create a new empty database called my_moodle_db
- using phpMyAdmin set the new database collation to utf8_unicode_ci
- using phpMyAdmin copy your my_moodle_dbBACKUP1919 to my_moodle_db
- copy moodledataBACKUP1919 folder to moodledata
- copy moodleBACKCUP1919 folder to moodle
UPGRADE 2.2.11 to 2.8.5
Everything went fine here as I already dealt with db utf8 issues, added salt to config.php, was using standard theme and legacy files were already converted to repositories. I cannot think of any issues I had with this step.
After each upgrade you should:
- check notifications at moodle/admin/
- run admin/cron.php
- check moodle/admin/tool/health/
- check XMLDB Editor and do all the checks listed there
- test your site as a user to make sure all files and courses are working properly and everything is accessible
Hope this helps!
Thank you for taking the time to post this. Hopefully it will help other users when they run into these issues.
I'm happy that my webhost gives me ssh access even on shared hosting, so I was able to do the backups and upgrades from the command line which eliminates the timeout and restore issues. It's still my recommendation that if you have ssh access to your server, use it for the upgrades. It solves all kinds of strange issues.
Once of my Clients has approached me with a view to upgrading to Version 2.9 (Currently on 1.9), and require some consultancy work, but I am struggling to find answers, I wondered if you would be kind enough to help.
Listed points are
· 360 schools running Moodle – all on version 1.9
· Moodle running on Azure in some instances, has been tested on a Win7 machine and the test was successful, (Windows 10 ) within 24 months
· The project objective is to upgrade all Moodle versions to version 2.9
· Post Project the aim is to keep Moodle updated to with 0.2 of the most recent stable version
I particularly seeking advice on:
· Assessment of current setup ( Win 7 )
· Best Practice in terms of what platforms to run Moodle on – the target frame being Azure
· Recommendations around completing the upgrades / migration
Any Advise you can offer at this stage would be invaluable
resurrecting old threads sometimes is overlooked by community members, better start a new or Moderators will move this to a new thread. But I do admire your searching for solution in Community forum first before typing your own, I mean this should always be an ideal case, searching in forums first to find solution, if you can't or have some additional questions of your own, then start a new thread.
Anyway, I could not understand you mentioning "Windows 7" test, Moodle is browser based script and not an application that has to interact with underlying operating system, as long as your browser is good to go, moodle will run perfectly and all common browsers with their latest versions installed works perfect with Moodle regardless you're running Windows 98, XP, 7, 10, Linux or MAC OS.
Now regarding the upgrade jump, it wont be straight jump from 1.9 -> 2.9, you have to do dual upgrade, first from 1.9 - 2.2, and then from 2.2 to any afterwards. so in all, Moodle 2.2 is underlying requirement for any higher versions to be upgraded to.
Also, because until 1.9, resource requirements were low, so you have to keep in mind also that you MAY have to add more resources (could be in terms of memory, CPU, or drives), while keep in in mind the new versions of PHP/MySQL required to run Moodle.
Before upgrading, you will make the list of all additional plug-ins installed, and find f they are available for the target Moodle version or not. As there are plenty of plug-ins that are not updated as per latest Moodle versions.
While others will add more to this, A recommendation is, upgrading to Moodle 3.0.1 or higher, for this Moodle is tested to support PHP 7.x being latest version of PHP, and has doubled on performance of Moodle while cutting down memory requirements to run Moodle in half.