Depending on what's involved, it's possible you spent anywhere between a few hours and a year creating your new website. Eventually, there comes a point when it's ready to go and take on the big bad world and fend for itself online. At this point you should be completely confident that everything works and that there aren't going to be any nasty surprises. Here's a list of things you can do before and after deployment to minimize your risk...

Test on multiple browsers

It might sound like a pedantic pain in the backend to have to download and install a multitude of browsers, but what works in one won't necessarily work in others and a perfectly good site on browser x can be utterly unusable on browser y.

I use Firefox for development and test everything on IE (new and old) and chrome and safari, and an example of the type of problem one can run into is IE's inability to handle png images correctly - it becomes necessary to strip out gamma information otherwise IE renders them in a darker color, which can ruin... everything.

Clean up the file system

Often during the course of development, a multitude of scripts and files are added, removed, modified and left lying around. It is very easy to forget about these, bundle them up with the site and send them off to the live server where they represent a potential vulnerability. A quick example might be a short script that displays server information for testing. If this is on your live server it can tell hackers a lot of juicy information about your system.

Another important thing to remember is clearing out any cached information that isn't required by the new site. Caches can add huge amounts of data to the database and this information is ultimately useless since your website is only just going live. Rather backup your database without the cach, and begin afresh.

Be security concious

It's quite easy to make the mistake of thinking that no-one would come across your site and find anything valuable enough to want to spend time trying to hack it - at least initially. The problem is that hacking is automated and a bot will sniff out any usernames and passwords it can and use these to access your account. You didn't use an administrator password to FTP your site to the live server over an unsecure connection, right?. If you did, it's possible you've been hacked without even knowing it - change your passwords to be safe.

You might also want to consider not transferring across usernames and passwords in clear text as part of your configuration files. You don't have to, so don't.

Monitor your webserver

Once a new website has been safely deployed it is possible that things start going wrong through no fault of the website itself. You might find that your hosting plan caps bandwidth, or that something is making it run slowly. It's a good idea to try and find out as much as possible about how the website is utilitizing the webserver's resources. This will also help you to predict when it might be necessary to upgrade based on expected increases in traffic volumes - and that's always something that's useful to know.

Test thoroughly

Your site may have worked on your development machine, but will it work on a dial up connection? How about if the user's browser is resized to unusual dimensions? Are all the file references working on the new server? Do links work, and are all the images displaying properly? It's important that you try and test as broadly and comprehensivley as possible - to avoid losing readers and customers who experience difficulties.