A while ago, I was involved in a project to upgrade 50+ servers from v5.x to v6.5.4. Half of these servers' hardware had to be replaced with whizzy new IBM BladeCenters. Thousands of users, some all over the place over slow links. Nightmare ? No. Why ?
Remember. The clients - all clients - store things like bookmarks and replicator pages entries in an unmanaged structure - that is, you cant easily get at them programmatically. Which is a PITA. Still. Some third party vendors - such as ICODEX have tools which help gather information and fix these clients remotely. Which is very very cool.
Lets imagine however that the client doesnt want to purchase this tool. (Mad, I know, as Client.Genie from ICODEX really helps cut your TCO). In this case, you do NOT want to change your server names if at all possible.
So how do I migrate the server to new hardware ? A new version of Domino ? A new Platform ?
- On the night before the upgrade, do lots of maintenance on the old server - compacts, fixups and so forth, In other words, try and fix any possible existing problems before migration
- Understand which DNS address you use to find the server that you wish to migrate, and check that the users are using this DNS entry to find the server. Seriously. Dont skip this step. Sometimes, (especially with v6.x clients), users use hard-coded IP addresses to find servers. If you find a large number of these you have two options:
- Warn the users. Give then 10 minutes grace. Arm yourself with a baseball bat, and walk around the office threatening the users who still havent left. Or whatever your normal operating practice is
- Shut down the OLD server.
- Copy the data directory from the old server to the new server to an area outside the new data directory. This takes TIME. Assume data transfer rates of 20gb/hour as a broad yardstick of a "same site, old hardware to new hardware" disk transfer rate. You can improve on this by running multiple copies, but not by much
- Copy the Notes.Ini from the old machine to the new machine, and fix up any references if you have changed directory structure, etc. Also, be very aware of directory links to other parts of the old hardware. Do you keep them, or do you have enough disk space to make do ?
- DISABLE Domino as a Windows service or as a Linux "auto-startup". You wouldnt believe how many server people switch on decommissioned servers if they see them switched off..
- Once the copy has finished:
- Check the data has been copied.
- Copy the DATABASES from the "copy" data area into the data directory of the new machine. I usually miss out templates, Full Text indexes and so forth..
- Phew. Crunch time. Do you go forward, or roll back ? I usually disconnect the old server from the network at this point, and disconnect the new server from the network. I then start up the NEW server, and make sure that it comes up okay, and everything appears fine. This is your decision point. "Do I stay or do I go" sang the Clash in 1984, and its something that I sing at this point. Coffee overdose, usually.
- Okay. We're not happy. We're going back. What to do ? Well, just switch on the old server, figure out what went wrong, and do the whole thing again in the next migration window. DONT try and be smart. Usually its late, your tired, and under enormous pressure. In other words, Worst Practices prime time!
- In this case, we're going forward. Change the IP addresses on the servers (if thats what your doing), else get the nice network person out of his bed, and get him to change the DNS entry/entries for the server to the new Address. This will take several hours to propogate, and its well worth conducting PING tests from various locations (remote desktop/Netwop is good for this!) to just check that its fine. (Oh and be nice to the netork guys. They're usually even worse than Domino Administrators to deal with...)
- Bring up the new server, on the new IP address if appropriate. Start up the domino server, and start checking access from clients - initially using Hardcoded IP addresses (because DNS probably still isnt propogated yet).
- At this stage, I usually run Compact's on the critical databases, and run updall to update rebuild views and full text indexes.
- MAKE absolutely sure that the old server WILL NOT start!
- After a couple of days, remove the intermediate COPY data from the new server. You dont need it anymrore.
Straightforward, eh ? Now remember, Domino is multi-platform. I've successfully copied (via FTP) databases from iSeries to NT, NT to AIX, Solaris to Linux and Windows 2000, etc, etc. So this'll even handle a platform change.
Pros and cons: Pros
- Fast. The limiting factor is how fast you can copy that data.
- Relatively simple and therefore likely to succeed
- Backout strategy simple.
- "Big Bang". If it doesnt work, lots of egg meets lots of face. Or use the Excrement/fan analogy.
- "Its not standard". Some environments dont like people using their imagination..
DISCLAIMER.. This isnt a complete procedure, and it almost certainly wont work in your environment without testing and confirmation. So Dont print this out, wave it in your bosses face, and call it a plan, okay ?
What do you think ? Would you do this ?