Hi Michael,
 I don't mean to have both working in parallel. I mean test and have a quick 
and safe plan B in place.  If testing is OK go ahead with the real migration to 
the well tested new environment. If the blank install on the new environment  
doesn't work well, roll back an fix, then try again.

Jee


Michael Leone <Michael.Leone AT PHA.PHILA DOT GOV> wrote:

>> This upgrade is quite a major change. I would keep the old server 
>> untouched and perform a DR procedure on the target followed by an 
>> upgrade. That would let you revert to the old server immediately 
>> without having to make any changes on it.
>
>So you suggest doing the rename LAST. Instead, do a DR recover onto new 
>hardware (using existing name and NW 7.6.2 version), then upgrade to 8.x 
>(whatever the latest I can download is).
>
>I can remove the old server from the domain before shutting it down (and 
>disabling the NW services), this will allow me to add the new Windows 
>server to the domain with the same name. That way, I can build the new 
>server with the new hardware (i.e., different model FC cards), zone it to 
>the SAN, etc. Then install NW 7.6.2, re-install the same licenses, then do 
>a mmrecov to get my list of clients and all their history.
>
>Then, rename a week or two later, after I am sure all is well.
>
>SO: 
>
>1. Migrate to new OS and hardware first.
>2. Wait until everything has been working for a couple weeks or so (enough 
>time for all schedules to have run on the new hardware).
>3. Upgrade to NW 8.x (including all SNs). Wait a couple weeks.
>3. Rename server.
>
>I have 9 SNs that must also be upgraded, to match the new NW server 
>version. Half of which use the SQL Module. That will be a separate email 
>...
>
>> Before doing the DR I would test the new environment using a new 
>> install of the current version with an empty configuration. That 
>> will help to test and prepare the new environment thus avoiding 
>> unexpected glitches during more advanced stages.
>> 
>> You can bring the services down or 'unplug' one server while working
>> with the other. The target server can use a dummy name for the blank
>> install and rename it later,  after the DR, to get the final name 
>> linked to the old server,s client id. You will need to create a 
>> client using that client id and the final name before the DR. Then 
>> rename the server from dummy to that name after the DR. 
>
>I don't know, that sounds more dangerous to me than just doing the upgrade 
>- renaming to match old client IDs. Especially for a server.
>
>> Before a client is created it has to be possible to resolve it (just
>> adding an entry on the hosts file on the server). No need to ping or
>> connect to it.