10 Things That Can Go Wrong When Deploying a Website

If you are a web developer, you probably have one or more copies of the website you are developing for your client. You may be using synchronization tools available in your HTML editor. You may be using version control systems. These tools are setup to ensure the integrity of the website when it finally goes live. However, even if you have these tools and processes in place, Murphy’s Law is still in effect. These are the 10 things that can go wrong when deploying a website.

1. Complications during domain name transfer.

   Plan ahead by updating the email addresses of the Administrative and Technical contacts of the domains in question. Notification emails will end up being sent to invalid addresses if these email addresses are not corrected. Each domain registrar will have different processes and procedures for transferring domains away from them. Some will make it difficult to avoid accidental transfers. For example, domains are “locked” by default. You must first unlock the domain ahead of time or you will end up in domain name transfer limbo. Educate yourself about the processes of the registrar involved.

2. Old pages do not have redirects.

   One of the consequences of redesigning a website from scratch is that the old URL’s will be changed. This is expecially true if there is a change in the server side platform, or Content Management System (CMS) platform. If it is important for the client to preserve pages that have already been indexed by search engines, make a list of these pages. Then for each page, create a 301 redirect so that search engines can properly re-index the new URL’s of these pages.

3. Scripting interpreter version is incompatible.

   If you have a staging server for development, the version of the interpreter may be different from the version installed in the production server. If the version difference is only a minor upgrade, chances are the scripts will continue to work. However, if the version difference is major, for example, PHP 4 vs. PHP 5, many functions may throw warnings or in some cases, errors. Decide which version you should develop in ahead of time so that the staging and production servers are as similar as possible.

4. Incompatible database format.

   There may be cases where you have developed database tables in a certain format in your staging site only to change it to something different in production. If you did not test the application for these changes, you may be faced with format incompatibilities. Such incompatibilities may be caused by the collation, for example, if the staging database tables were in “Swedish, case-insensitive” and the production database tables were in “utf8”. Another formatting incompatibility is the database type (MyISAM vs. InnoDB). Make sure that both databases are using the same format on the staging site and the production site.

5. Client authentication issues.

   If your website requires logins on the application or data layer, make sure that the salt hashes are updated as intended. The salt is one of the inputs in creating a one-way function in encryption. Some developers like to keep the salt the same on development, staging, and production servers, while others like to make these different. For the later, you must ensure that any password hashes are re-generated where necessary, otherwise, the logins will no longer work.

6. Google robot crawl errors.

   When upgrading a static page to a page handled by a CMS like WordPress, make sure that it continues to be crawled by search bots. There are some plugins that will make the page render in a browser, while at the same time, throw Status 404’s in the HTTP headers. Use Google Webmasters to find out what Googlebot really sees, or other HTTP header sniffer tools to disguise your connection as a different client. Additionally, some CMS’s have the ability to block access to a site that is still in development. A common mistake developers make is forgetting to turn it back on after deploying to production.

7. Email transmission problems.

   Systems admin tasks often get buried under the overwhelming work involved in deploying large websites for the first time. It should be noted that systems admin tasks should come ahead of any web development task because if the production server is not configured properly, many functions will not work as intended. Email configuration should be one of the first tasks to configure and test. If you have forms that send and receive emails, make sure you test them ahead of time. Check that DNS MX records have been configured properly.

8. Data integrity issues.

   No one should be deploying data-driven websites while it is live. Doing so can cause data integrity issues caused by half-executed queries. Make sure that you always have a full backup before upgrading any database. This can be quite challenging for extremely busy websites, so a suitable time of the day when it is not as busy should be agreed upon with the client to carry this out. In most cases, the website may have to be taken out of commission during the upgrade, so an announcement must first be sent out ahead of time. Consult with your database admin to determine the best approach.

9. Web server permission problems.

   Again, systems admin tasks should never take a back seat to web development tasks. Make sure that proper permissions have been set to files and folders on the development site. See to it that sub-domains are resolving properly, database connection strings are correct, and passwords updated where necessary.

10. Invalid server configuration.

    There are many configuration parameters that may have to be updated on the production site. Such configurations include file size limits. If the web application allows users to upload files, make sure that a suitable file size limit is set in the server configuration. Certain ports may have to be configured to be open or port-forwarded. Some settings are have a different setting while being developed, for example, while being developed in a local machine. After deployment, these settings must be updated to the production server’s proper values.

There are thousands of things that can go wrong during deployment and this article only covers 10 of them. This does not even include many unknowns that mysteriously show up during deployment. To be on the safe side, make sure that you have a plan to prepare, execute, test, and roll back. You can also deploy in stages where you are only deploying a portion of the website. You can also deploy in iterations, or deploy in parallel so that you can “flip the switch” when it is ready. Avoid mistakes, but make sure you have enough time to correct them if you still make them by backing up your data, having proper support, and a roll back plan.