From the IT prospective a WordPress web site requires:
- A web server like Microsoft IIS or Apache
- mySQL database
Migrating a WordPress website includes copying all its files/folder structure, and its mySQL database, and changing the wp-config.php file to point to the new mySQL database. These tasks could be complicated for a large site and may require specific skills related to web site configuration and mySQL database administration. This post goes over a very simple way to migrate a WordPress web site to Azure, using the Duplicator WordPress plugin.
- Add Duplicator WordPress Plugin
- Create New Package
- Create new Azure WebApp
- Add mySQL database
- Upload the Duplicator package to the new Azure WebApp
- Run the Duplicator Package Installer
If you don’t have it already, add the WordPress Duplicator Plugin. On the Plugins page click Add New
Search for Duplicator, click Install Now
Create New Package
Click on Duplicator link on the left, then click Create New
Accept the defaults and click Next to scan your WordPress site
Duplicator scans your current WordPress site
and displays the result like:
In this example, I have a couple of warnings about large site size, and some large files. I check the box and click Build.
Duplicator builds the package:
The package consists of an Installer (installer.php file) and Archive (.zip file). I download both to my desktop. The zip file contains all the WordPress site files and folder structure + a scripted copy of the associated mySQL database
Create new Azure WebApp
In the Azure Portal, click New/Web+Mobile/Web App
In the Web App blade I type in the new Web App name ‘MyWebApp407’ which must be unique under .azurewebsites.net. I pick the Azure subscription from the Subscription drop down menu. I choose to create a new Resource Group. I give it a name; ‘MyWebApp-RG’. I click the arrow to create a new Service Plan
In the App Service Plan blade (middle) I click Create New, type in MyWebApp-SP as the name, select East-US and accept the default Pricing teir of S1 Standard.
Finally, I click OK and Create
In a few minutes Azure complete MyWebApp deployment
Add mySQL database
I browse under Resource Groups/MyWebApp-RG, and click Add
I search for mySQL, and select MySQL Database by ClearDB
and click Create
I give it a name ‘MyWebAppDB’ (avoid using other than alphanumeric characters in DB name), pick East US for the location, click the arrow and OK to accept the terms, and finally click Create
Click Refresh and note the new blank mySQL database:
Upload the Duplicator package to the new Azure WebApp
If you browse to the new web site now you may see a temporary page like:
First zip the 2 files downloaded from the Duplicator Package above into 1 file:
Next browse to the KUDU page http://MyWebApp407.scm.azurewebsites.net
Click CMD under the Debug Console menu
Browse to d:\site\wwwroot
Drag the zip file from prior steps and drag it on the right side as shown below:
Azure will upload
and unzip the file
Run the Duplicator Package Installer
Browse to the installer.php file as in http://mywebapp407.azurewebsites.net/installer.php
You will see a page similar to
Back in the Azure Portal, click MyWebAppDB/Properties
Note the Database Name, Hostname, username, and password
Back in the installer.php screen, enter the required information as shown below:
Click ‘Connect and Remove All Data’, click ‘Test Connection’, check the box to acknowledge the notices, and click ‘Run Deployment’
Click OK to continue..
The installer extracts the Duplicator Package zip file restoring the file system and rebuilds the mySQL database from the script contained in the zip file
Accept the defaults and click Run Update
The Installer makes the selected changes to the WebApp config files
Follow the installer instructions to do final testing:
Step number 2 above is actually important. Clicking on the link next to ‘2.’ above will take you to the site admin login page:
Use the same credentials from the original site.
Adjust your permalinks setting as it is on the original site.:
As a last step, once the site users have tested that everything looks OK, add a custom domain to the site and switch the domain DNS records to point to your new Azure site.
StorSimple Hybrid Cloud Storage array is an on-premise iSCSI SAN that extends seamlessly to the cloud. iSCSI volumes provisioned from a StorSimple device can be expanded but cannot be shrunk. So, a typical recommendation here is to start a volume small and grow it as needed. Growing a volume is a process that does not require down time. This script grows a StorSimple volume automatically based on set conditions of volume free space and a not-to-exceed value.
The input region of this script is the one that should be edited by the script user:
Similar to the script that monitors StorSimple Backups, the values for SubscriptionName, SubscriptionID, and StorSimpleManagerName variables can be found in the classic Azure Management Interface under your StorSimple Manager node Dashboard and Device pages:
and the RegistrationKey:
and the SSDeviceName (StorSimple Device Name)
The value for the SSVolumeName (StorSimple volume name) variable can be found under the device\volume container:
Notify variable can be either $true or $false. This instructs the script whether or not to send email notification when an expansion is triggered,
Similarly, Expand variable can be either $true or $false. This instructs the script whether or not to expand the volume when an expansion is triggered, When set to $false (and Notify is set to $true) and an expansion is triggered, the script will send an email notification that an expansion is triggered but will not do the actual expansion.
ExpandThresholdGB and ExpandThresholdPercent variables are used by the script to identify the amount of free space on the volume below which a volume expansion is triggered. Only one of these variables is needed. If both are provided the script will use the larger value.
- Example 1: If the volume size is 100 GB, and the ExpandThresholdGB is set to 10 (GB) and the ExpandThresholdPercent is set to 15 (%), the script will trigger a volume expansion if the amount of free space is at or below 15 GB
- Example 2: If the volume size is 100 GB, and the ExpandThresholdGB is set to 10 (GB) and the ExpandThresholdPercent is set to 5 (%), the script will trigger a volume expansion if the amount of free space is at or below 10 GB
Similarly, the ExpandAmountGB and ExpandAmountPercent variables instruct the script on how much to expand the volume once expansion is triggered. Only one of these variables is needed. If both are provided the script will use the larger value.
- Example 1: If the volume size is 100 GB, and the ExpandAmountGB is set to 10 (GB) and the ExpandAmountPercent is set to 15 (%), the script will expand the volume by 15 GB once expansion is triggered.
- Example 2: If the volume size is 100 GB, and the ExpandAmountGB is set to 10 (GB) and the ExpandAmountPercent is set to 5 (%), the script will expand the volume by 10 GB once expansion is triggered.
The value assigned to the variable NotToExceedGB is used by the script as volume maximum size that the script must not exceed. For example, if the prior 4 variables instruct the script to expand a 900 GB volume by an additional 200 GB and the NotToExceedGB variable is set to 1024 (1 TB), the script will expand the volume by 124 GB only to reach the NotToExceedGB amount but to not to exceed it.
DiskNumber and DriveLetter are values that the script user should obtain from the server’s Disk Management screen of the file server using this iSCSI volume:
As of the time of writing this post and script (1 April 2016), there’s no way to correlate a volume on a file server to a volume on a StorSimple device. For example, if you create 3 volumes of the same size on a StorSimple device and call them data1, data2, and data3, and present them to the same file server and format them with the same file system and block size, and use volume labels data1, data2, data3, there’s no way to tell if data1 on the StorSimple device is the volume labeled data1 on the file server. This is why it’s recommended to provision and format StorSimple volumes one at a time and use the same volume label when formatting the volume as the volume name on StorSimple. Long story short, it’s the user’s responsiblity to:
- Make sure the DrviveLetter and DiskNumber correspond to the SSVolumeName, and
- Update the DrviveLetter and DiskNumber values if they change on the file server due to adding or removing volumes.
One last point here; if this iSCSI volume is presented to a Windows Failover cluster, this script must be run on the owner node.
LogFile is the path to where the script will log its actions – each log line will be time stamped. This could be on a network share.
EmailSender is the name and email address you wish to have the email notification appear to come from. For example: StorSimple Volume Size Monitor <DoNotReply@YourDomain.com>
$EmailRecipients = @(
‘Sam Boutros <email@example.com>’
‘Your Name <YourName@YourDomain.com>’
is an array that takes one or more email addresses in the format shown above.
SMTPServer is your SMTP relay server. You need to make necessary configuration/white-listing changes to allow your SMTP server to accept and relay SMTP email from the server running the script.
Sample script output:
and example of email notification:
Possible future enhancements to this script include:
- Rewrite the script as a function so that it can handle several volumes
- Rewrite the script to use Powershell remoting, so that it does not have to run on the file server.
- Add functionality to detect if the target file server is a member of a failover cluster, and to automatically target the owner node.