As some of my readers know my blog runs on Microsoft Azure Websites. Since I launched this new version back in summer 2014 I literally had no maintenance tasks to do. But about half a year ago I started getting notifications that PHP 5.3 will be deprecated on Azure Websites. Since my blog up until know ran WordPress 3.x with PHP 5.3 I finally had to do something to ensure a smooth transition.
I know the notification below is in German, but essentially it tells me that the Azure team is deprecating PHP 5.3 and they would move me to 5.4 automatically if I don’t do anything until January 31st.
Now, I definitely did not want to have any bad surprises. So I wanted to do the upgrade by myself, test it and also upgrade to the latest version of WordPress as part of that operation. Of course I wanted to have all of this in a safe way, with an option to roll-back if something does not work.
Azure Websites Backup
What I wanted is doing a backup using the out-of-the-box service provided as part of Azure Websites – Backup. Since you can only make use of that function in STANDARD-scale mode, the first thing I did, was switching to STANDARD (temporarily for the time of this activity).
With that I was able to create a backup of my website into my Azure storage account. The cool part of it is that backup includes everything needed: the site and its file contents as well as the linked ClearDB database.
Since I wanted to switch back to Shared-mode after this activity, again, to save costs, I did not create automated and scheduled backups. But for more serious workloads I’d definitely suggest to leverage this fairly cool feature, as well.
Of course I wanted to try if the backup really worked. So as a next step I thought I try to restore the site in a newly created, empty website. Again I created the site in standard mode so that I was able to leverage the functionality. Then I went to the Backup-tab and tried the restore option. With the restore option you can either restore backups made for this web site or explicitly select a backup file from your storage account. Since I wanted to restore into a new website I wanted to restore from the file, directly.
The restore did only work partially – it did run in an error because it also tried to restore the custom domain associated with the website which was still associated with my production website. But at least it was able to read and parse the backup file. That was enough for me to trust that in a worst case a restore would work:)
Next I did decide to upgrade the WordPress version before I upgrade the PHP runtime. I did not want to upgrade the runtime and then have eventually issues with my older WordPress version running on the newer PHP runtime. Upgrading WordPress could not be simpler. Just sign in into the control panel and it will offer you to upgrade, anyway. That’s then exactly what I did.
And what’s really cool is that just after 2 or 3 min. the browser opened back up with the following screen – bumm, my blog was upgraded to WordPress 4.1. Isn’t that awesome. That’s exactly how I’d expect such things to work:
Now the remaining upgrade-step was to move away from PHP 5.3 as it will be deprecated – which was the original motivation for me to start this whole effort.
Finally since I pay for this with my private check I wanted to run on the more cost-effective instance-tier, again. So after everything worked out well I switched back to “Shared”-mode (as I have the custom domain blog.mszcool.com associated with the website).
That’s it. With that and with a short period of time running in a more expensive instance mode the blog is backed-up and now runs on the latest PHP runtime as well as WordPress version. It’s impressive how well Azure Websites, PHP and WordPress plays together. Cool stuff…
Hope that how-to was interesting for you, as well…