By Chuck Loughry
The article you are reading was part of a major overhaul of our website. We hired a great marketing firm to help us transform our message to better reflect the changes our business has undergone since first establishing the original content.
One of the requirements we established up front would be that we would host our own website. We would shut down our old site on our current host provider and change our DNS domain server to point to our new host provider, which would be Microsoft Azure.
Our new website was developed in WordPress and it would require a data migration/export of the WordPress assets from their environment to ours. Our company has handled many data migrations over the years, and one of the most important lessons we have learned in all that time is to prepare for the unknown.
We confirmed the versions of software that our marketing firm was using to make sure that the provisioned solution we had chosen (Bitnami’s WordPress on Ubuntu) would be compatible. We also identified the export package they were using to export the solution in order to eliminate any issues with export/import processing.
We also performed an export of the demo website we had created on our new environment, deleted the website from our server, and then reimported it just to make sure that we didn’t have any issues with the package. Everything worked perfectly – so far.
Even with all of the smooth sailing we were having, we knew that establishing some contingency into our planning would be crucial in order to get close to making our deadline. Our Go-Live date was June 1st and we were 3 weeks before Go-Live, so we chose to schedule a mock migration. We used the current version of the new website created by our marketing firm to see if our smooth sailing would continue. The process went very well up to the last step when we tried to run the new website.
That was when we received the WSOD (White Screen of Death). This is the generic, “The website is experiencing Technical Difficulties” message. We would need time to determine the issue(s) and we were now on the clock utilizing our contingency.
Fortunately, there is a debug feature in WordPress that allows you to turn on the flag and examine errors as they occur. However, when we turned this flag on, the WYOD still occurred. This was concerning, so we took a look at the wp-config file to see if we could see if there was anything above the debug flag line of code that might be causing the issue.
We couldn’t find anything above the line, but at the bottom of the file, we saw a line of code that was referencing a hard-coded path to a wp-settings file. We knew this path didn’t exist on our server, so we began looking for the software that was associated with this line. What we found was that this line was installed by the marketing firm’s hosting provider to add helper features to their WordPress environment.
Removing the line of code corrected the problem. Several more “tweaks” were also required to get us to a point where our site matched their development environment. Without the contingency, our deadline would have been in jeopardy.
Contingency is a risk mitigation tool, but you must be very careful that you minimize as much risk as you can without assuming all of your risk into a contingency bucket – or your budget (or your client’s budget) – will suffer. And if it’s your client, your solution may no longer be attractive.
Use it, but use it wisely.
