Kevin Wright’s blog

Your development server and your production server may be one and the same, and you may have been developing the site ‘blind’ by using a dummy home page, or not attaching the domain name; however, you may be using an offline development server instead, with the intent of posting it on the production server for public use when the site is finally done. Why would you choose to do so? Following are some scenarios where it would make sense:
1. You have a large, complex website that needs to be built and tested truly offline, not in any way connected to the Web.
2. You already have a website in operation, and you are building new features for it. Obviously, you do not want to build and debug new features on a site that is in active use.
3. You have hired outside developers to build the site. They are working on their own server, with the intent of moving the site to your server when completed.
These three cases, combined with the various kinds of websites and technology in use, can generate many different situations. Regarding going live or adding new features, and the procedures for doing so, far too many situations exist to examine each one; however, let’s consider some common situations:
* A large, database-driven e-commerce site going live for the first time and being developed out -of-house: In this situation, the site is being developed on a development server (the outside developer’s server). Therefore, it needs to be moved over to the production server and tested before the site can go live. A good approach would be to use password protection until final testing and debugging on the production server is completed.
* A new Java-based game is being added to a Web page on an already live, internally hosted website: In this situation, the Java game can be placed on a copy of the target page on the live server. The file for the page with the game on it should be renamed and placed on the server in the same directory, so any path or linking information remains valid to the current home page. The page with the game on it can be tested and debugged in place on the live server, without affecting the current page that users are accessing. Once the game page is debugged and final, you can simply revert to the home page file name, overwriting the current page, and the new Java-game home page will be live.
* You have an existing website and are switching over to a new ISP: In this case, the domain name/IP address connection is the only real issue. To handle it, start by copying the old site over to the new server, without touching the existing live website. Next, get the IP number of your new site established and test the new site using the new IP number instead of the domain name. When the new site is ready to your satisfaction, ask your ISP to have the domain name switched over to point at the new IP number.
Many development projects involve a transition to a new server. If this is the case, it makes sense to communicate this information with technical personnel who will be maintaining the server, giving them as much lead time as possible. An outside hosting service deals with multiple customers with all kinds of projects going on. In vendor relations, it is a courtesy and often a necessity to give an early heads-up to an outside hosting service. You do not want to be the customer who says, ‘You’ll have the files by 5 p.m., and, by the way, the site needs to go live tomorrow.’ Even if your service can scramble at your behest, you will have lost goodwill.
The irony is that in an in-house hosting scenario, the technology staff may be much less responsive to your needs. No matter what the internal accounting setup is, it tends not to frame you as a ‘paying customer’ in the same way a vendor-client relationship does. A fact of organizational life is that projects are often prioritized by the status of the requester rather than by business objectives. In short, the project manager is called on again to use interpersonal skills and political acumen in this transition to a new server. You absolutely have to be on top of some technology issues here; but don’t kid yourself, it takes people to make it work.
Internal technology personnel hold the keys to the kingdom. No matter what their position in the company hierarchy, they hold power over what goes on the machine. They also tend to be territorial about it. Communication as early as possible is important to gain their buy-in on the project. The technical specification is a key document for this communication. If you’ve kept the document current during the development, it will give technology staff a good idea of the technical requirements and the issues involved in making the site work.