System deployment is a complex endeavor which is a critical aspect of the software development lifecycle (SDLC), an endeavor that is all but ignored by writers in favor of sexier topics such as distributed object development, components, or the latest version of an SDK. If you can't get software into the hands of your users then what is its value? Absolutely nothing. The following tips and techniques should help to make your system deployment efforts successful.
Identify and understand your deployment audience. There are at least three distinct groups that you need to consider your end users, the operations staff responsible for running the software once it is in production, and the support staff who is responsible for aiding your users with the software once it is in production. You need to identify the level of control that each group has over your actual deployment. Can one group stop your deployment if you don't meet their specific requirements? For example, it is quite common to discover that operations departments have defined criteria for the release of new software, criteria that your deployment approach must meet. I once worked for an organization where the users were unionized and any software that was deployed to them had to be first accepted by their union representatives, otherwise you couldn't ship. Early in your project you need to identify the deployment hoops that you need to jump through to be successful.
Identify your deployment strategy early. Will you run the new system in parallel with the existing system or will you perform a cutover? Running the system in parallel offers the advantage that you can easily back out to the original system if the new one runs into problems. However, parallel operations requires significant effort on the part of everyone involved: Your users need to do double entry, operations staff need to run both systems, support staff need to support both systems, and development staff may need to create integration code that temporarily works behind the scenes to synchronize data. For many systems, particularly ones supporting online customers via the Internet, a cutover is your only option – few customers would be willing to place their book order with both Amazon version N and with Amazon version N+1. With a straight cutover you will need to plan for a downtime period in which the cutover occurs, anywhere from a few seconds to a few hours, or even a few days depending on the nature of the system being deployed.