Website Deployment Checklist

So, you have approved your specification and design concepts. The development is progressing well and is nearing completion. After giving your final feedback, at some point soon, your site will need to ‘go live’ onto the Internet for all to see.
 
Have you thought about how this will happen? Do you know what is involved? This article is aimed at clients, managers (production and IT) and developers in general.

There are a few fundamental things to remember:

1. Have you bought your domain names? It seems silly to ask but many people forget or assume the development firm will do this for them. You should aim for at least a .com.au and a .com address.
    
2. Have you chosen a host for your website? It is imperative you discuss this step with your web developer as not all hosts are the same. Depending on your site, you may require a dedicated hosting package rather than a shared hosting package, particularly if you need non-web application to run (for example, a scheduled task that sends email to your members every day; most shared hosting packages do not permit you to run any Windows applications). You also need to tailor your package to the language the site is coded in, for example, an ASP.NET host rather than a PHP host. Again, discussing this step with your developer is a requirement and to save the most time ensure they have all the information possible about your new hosting environment at the earliest opportunity.
    
3. Will you require an SSL certificate? SSL certificates are used to encrypt sensitive data between the end user and your web host. Typical use of an SSL certificate is on a page that expects credit card numbers. You will need to discuss this with your web developer and host prior or during the development phase as the site code will need to cater for your certificate.
    
4. Are you in control of your domain name and your DNS? Once a domain is purchased from your registrar it needs to be delegated to a DNS server. This may be offered by your registrar, your development firm or your web host.
    
5. Have you added your domain names to your DNS? You will receive an IP address from your host telling you the location of your new web server. This needs to be added as an ‘A’ record to your DNS so that users typing in your domain name in their web browser are directed to the correct location. Make sure you add records for the domain and its ‘www’ sub-domain, as most users are used to typing ‘www.domainname.com’ to get to a website. Your host will be able to help you in setting this up.
    
6. Does your site utilise a database such as Microsoft SQL Server? This is another question for your web developer, and the resultant answer needs to be provided to your web host. How big do your developers anticipate your database will be? Many web host’s fees for hosting a database are dependent on its size.
    
7. Will your site be sending email to anyone, including yourself? Perhaps from a Contact Us form or even a Forgotten Password request to your site members. Make sure you pass the details of the host’s SMTP server on to your web developers who no doubt will be involved in pushing your site live.
    
8. Does your site utilise any third party components to perform particular functions? This is a question for your web developer as these components will need to be installed prior to launch. A good example of this is a PDF generator.
    
9. For a dedicated hosting package, who will be setting up the required hardware and software? Many web hosts will simply install Windows and then provide you with access details. There are many pieces of software that need to be installed and configured before you can run a website on a server – examples including the ASP.NET framework and MS SQL Server – that your host should be able to help you out with. Your developer may request special access rights for the purpose of deployment, such as temporarily making your new live database directly accessible from their offices. Hosts firewalls rules also need to be in place so that your website can communicate with its database and its email server.

Is this a replacement of an existing site? Most of the above is applicable to an existing site; however there are a few more things to consider:

1. How will your old content get to your new website? Will your web development firm be copying your content across for you or will you be doing this yourself with your new CMS? The best scenario is both. Your web developer should during training demonstrate the abilities of their CMS by copying across some of your current content for you. You can then get to grips with your CMS by entering your content.
    
2. Is your old (and new) site more than simple content? Do you have hundreds of products and membership details you do not want to lose? You should discuss early on with your web developers how to get this data across to your new site in the most seamless fashion possible. Depending on your current website, this could be a lengthy and costly process to initiate. If your current site takes orders for example, you will want to import your existing data at the last possible moment so that members wishing to see their order history do not lose any information.
    
3. Who is going to be responsible for the cutover of old site to new site? I have seen on many occasions the web developer, the web host and the client all not sure who is handling the final ‘big push’ when the time has come. An open dialogue between the three parties is the best way to solve this and should be done as early as possible.
    
4. Be aware that if you are changing hosting providers the delegation of your DNS from your current web host to your new web host could take anywhere between 2 and 72 hours to propagate to end users around the world. You may want to anticipate this and replace your existing web site with a ‘Down for maintenance’ page so that there is no crossover of data. This can prevent users whose DNS have not yet updated to reflect your new website still be purchasing products from your old site. When your new site becomes available to the same user, they may be alarmed to find their order is not in the new website order history page. It is best to ‘take the hit’, as it were, and disable your current website at the same moment any final data migration takes place.

Hopefully this checklist is helpful to you as you prepare to launch your new website. Good luck!