Try this:
Currently every new server is assigned a new name. This was an effective system in the past because it was time consuming to move applications currently in use (production) to a new. Compatibility with changes in server software on the new servers was also a problem.
Times have changed. Compatibility is not the problem it was in the past. Transfer of applications and data to a new server can be accomplished much more quickly than was possible in the past.
While transfer of applications and data to the new server can be accomplished more quickly, reducing down time to a minimum, the greater use of networked applications and databases has elevated what was previously an annoyance to a major problem.
We now work in an environment where there are many users of each application and the users may not be all located in one centralized area of a building. In fact, they can be in locations physically separated by many miles.
The current policy of assigning a new name to the replacement server, rather than using the same name as the server it replaces, has now become a major problembecause of this combination of greatly increased numbers of users and users who are diversely located.
Most applications and related software include links that reference the server name. With more applications, more users, and more diversely located users, fixing these references for everyone and every application becomes a daunting, time consuming process. It is prone tocause expensive delays and other costly problems when users try to use applications on the replacement server.
Change this policy so that the replacement server will be assigned the same name as the server it replaces. This will eliminate the costs of loss of productivity, sales, and customer relations due to problems caused by the current policy of assigning a new name to the replacement server.
