We often find that businesses’ investment in terms of money and effort in their websites is out of line with what would be optimal. For example, you have people that spend over a thousand dollars a year on a security service that doesn’t even really attempt to secure the website, while more basic maintenance is often neglected or done by those that don’t have the necessary experience to handle it properly, even when the business has the means necessary for to avoid that and the website is critical for the business.
We recently had someone contact us looking for emergency support after a Drupal upgrade went wrong that lead to a website that they said was critical to the business not working. One way to handle that situation would be to revert to a backup, but they said the most recent backup was three months old.
If a website is critical to business then frequent backups should be made outside of any done before upgrades, so there should have been a more recent backup than that, but what about properly preparing for an upgrade outside of that? At the very least, a backup should be made before upgrade is started. If the website is critical to business though that probably isn’t enough.
One reason for that is that there is always a possibility that there is some issue that would make restoring a backup a difficult or impossible. Let’s say for some reason the backup method being used isn’t actually fully backing things up (which can happen). Someone that knows what they are doing can usually ensure that the backup is complete without having to do a test run of a restoration, but one way to test a restoration also provides a better method for handling potential issues for an upgrade.
If a website is truly critical to a business then the best thing to do is to do a test of the upgrade before the production website is upgraded. That will significantly lessen the chance of something going wrong when the production website is upgraded, which would then require trying to quickly fix it or revert to a backup. Instead time can be takem to understand what is going wrong and how to ameliorate that before the time comes to upgrade the production website. Setting up the test copy of the website also allows testing out the restoration of a backup as well.
Usually a test copy of the website can simply be set up in a directory in the existing website’s hosting account/domain name. A more advanced way to handle it is to use a separate hosting environment, say a separate hosting account, though with that it is important to make sure the server environment is the same as the production website, so that some inconsistency between them doesn’t lead to an issue only appearing when the production website is upgraded.
Finally, testing out the test of the upgrade. For some types of website a quick check over few pages will be enough but in others more extensive manual or automated testing may be needed. Another sometimes overlooked area of testing is becoming familiar with functionality changes in the backend of websites when significant upgrades are made. We have been involved in situations where that hasn’t happened and someone then was panicking because they needed to do something in hurry, but weren’t aware of how to do that it in the new version, so trying out normal activities in the test copy we a significant upgrade is being done is very good idea.