- How to move your WordPress blog to Azure VM (Part 1 of 4)
- How to move your WordPress blog to Azure VM (Part 2 of 4)
- How to move your WordPress blog to Azure VM (Part 3 of 4) (removed)
Restore WordPress database
To restore the database, I chose to use MySQL Workbench which can be downloaded here: https://www.mysql.com/products/workbench/
After install, when you launch MySQL WorkBench, it should recognize the local instance of MySQL and allow you to connect. You will need to provide root password to connect. This is the same password you provided during installation of MySQL using WebPI.
Once connected to local MySQL instance, it showed me all the databases that existed. When we installed WordPress using WebPI, it also created a database. I chose to create new database instead that matches the name of the database on my web host. That allowed to me keep migration headaches to minimum and process simple. This also allowed me to simply ignore the database that was created by WebPI. This database can be removed later if you wish.
First, I created a new database (also referred to as new schema). You can do so by right clicking in the empty space below the list of schemas:
I named the database the same as the one on the live site (on my current web host). Once you click apply, it should create the database successfully:
Next I created a user, also matching the same username that is in my wp-config.php file from the backup. This would keep my transition very easy, but you can chose to name the database and user to your liking. Just make sure the wp-config.php file reflects the changes when restored to the Azure VM.
After providing log on details, make sure the user is assigned appropriate schema privileges:
Apply the changes and you are ready to restore the database from the backup.
Start the Data Import wizard from “Server” menu:
On the wizard page, select the self-contained SQL file from the backup created in earlier steps. Select the database you created in the previous step, and start import:
Depending on amount of data you are importing, it may take some time for import to complete. After the import is complete, you can move to the next step of restoring WordPress content.
Restore WordPress content
Restoring WordPress content is a simple file operation on the Azure VM. Go to the folder where you installed WordPress earlier. Instead of deleting them outright, I chose to move existing WordPress files to a Backup folder. This allows me to revert to the default installation quickly if I need to. You can delete the backup folder after your restore is successful.
After moving the files, copy the files you backed up from your current WordPress site in the steps outlined earlier. The benefit of doing restore using this method is, you don’t have to download and install your plugins or configure your redirects, among many other settings. This is a simple forklift of your existing blog which saves lot of time you would spend otherwise, installing and configuring plugins and other settings.
After restore of WordPress files and content is complete, you should not have to make any changes to your wp-config.php assuming it is referring to localhost for MySQL database host. You may have to change the database host to “localhost” if your current host provides MySQL database on separate host.
At this point, you should be able to test your restored site. Here’s mine, showing the hosts file pointing to the Azure VM and the browser showing my restored site:
Last, but not the least, is the configuration change that will actually direct your readers to your new location. You may want to set your hosts files back to normal so the local browsing uses DNS as well. Remember that we did not install FTP or any other utilities on the Azure VM. So all you need to do is change your DNS entries for the domain contoso.com and www.contoso.com (depending on your WordPress configuration) to point to the public IP address of your Azure VM. If you are not sure of the IP address assigned to your VM, you can check it on Azure portal:
After you make the DNS change it may take up to 24 hours to propagate. Your visitors may end up on old WordPress site until their DNS servers notice the change of records. Don’t rush to decommission your old site until DNS propagation is complete.
It’s also worth noting that you won’t be able to update wordpress or plugins using dashboard until you tweak permissions on the folder where WordPress is installed. I don’t have authoritative source to refer you to, but I simply apply “IUSR” full permissions on website root folder (I know, bad idea!) only temporarily and remove them after updates are complete. You can also chose to manually update the plugins and WordPress but it’s more involved process and I try to avoid that for many reasons.
That should be it folks! Until next time when we discuss WordPress on Linux VM and WordPress using Azure Web Apps.schemas