You might be a Domino geek if ... you enjoy upgrading your server more than watching Cheerleaders and the Superbowl commercials!

One of the things that I get asked about most frequently regards hardware upgrades and replacements. Whether it's a rip-and-replace, or a migration to a new box, if you really DO enjoy upgrading your server more than watching cheerleaders and the Superbowl commercials ... you just might be a Domino Geek!

Rip and replace.

This is where you really can't wait to "Adios" that old clunker and replace it with a new system (my C20 knows she's safe, I can see her cursor blinking at me in a very familiar way).

Probably the easiest and least complex way to upgrade your Domino system is the scenario where the box that you can't wait to get rid of is going to be completely replaced with new hardware.

Step by step, you just need to do the following.

Install and configure the OS for the new system
Tune the OS to get it running like a rocket-ship
Shut down the "old" domino server
Use the OS to copy the \Data directory from the old system to the new one
Don't forget the notes.ini (or configuration) file
Install the appropriate Domino Server software, pointing the \data directory to the appropriate location from step 4
Pull the plug on the old box
Change the OS settings (host name, IP config, etc) on the new machine to match those of the old system
Commission the new system onto the network
Start Domino.

It really is that easy.

Since the Domino server has already been configured with the host options, if the new OS has settings (as mentioned in step 8) that match the system Domino previously inhabited, users will be able to connect and interact with the Domino system as though it were still located on the old host.

Of course, there are situations when you need to be mindful of copying everything from the old Domino server's data directory (some anti-spam or virus databases, old templates, redundant applications, etc), as implementing new hardware is often a good opportunity to do some initial examination, prior to the rip & replace to do some housekeeping.

To give yourself an even better chance to clean up your system, you might consider the situation where the hardware you intend moving Domino from is still going to perform some role within your network. Migrating to a new box is the other scenario Administrators quite often find themselves facing.

Migrating to a new Domino server.

Every now and then you are in a position where a piece of hardware performs multiple roles within your organisation, where Domino is just one of them. Often this is as a result of a growing organisation, where Network admin, file and print, DNS, proxy, Domino and a multitude of other roles have been performed on one system. Often Domino is the first choice to move off the overworked system and onto it's own dedicated piece of hardware.

It would be possible to use the same methodology as rip & replace; however, it can be easier to commission a new server and move your users over to the new box.

The first two steps to perform are the same as rip & replace, as one of your primary considerations is to ensure that the platform hosting Domino is performing to it's expectations. That's where the similarities end, as your primary concern once the new system is up and running is to cause as little interruption to your users as possible during your transition.

Install and Configure the OS.
Tune the OS.
Register the new Server.
Install the appropriate Domino server software on the new hardware.
Commission the new server into the Domain.
Run a Decommission Server Analysis to compare the two systems.
Use the DSA to identify applications and configurations that you need to maintain within your environment.
Create or modify configurations on the new server, as appropriate.
Create replica's of all applications that are going to continue in operation (especially users mail).

And then the key step in the process to migrate to a new server on different hardware...

Implement Domino Clustering. (Place the old and new server into the same cluster)

Once clustering has been in operation for a few days, test the configuration regularly to ensure users are "failing-over" to the new server.
Start migrating users, mail-in apps, etc "Home" server to the new system (either manually, or via agents).
Leave the configuration operating for an appropriate length of time.
Pull the plug on the old system (or just shut-down Domino).
Remove the new server from the cluster.

The key to this process is Domino clustering. By using the fail-over capabilities of Domino clustering, users transparently have their client configurations (replica's, bookmarks, etc) transferred over to the new server without the need for complex system migration instructions, visiting individual workstations, or even writing complex scripts and agents.

Another point to highlight is the amount of time to leave step 13 in the above process active. This should obviously be long enough for you to move the user's home severs, and also to cater for fail-over "tests" to make sure users bookmarks and replica's are going to be re-directed to the new system. The longer you are able to maintain the configuration, the less likely you will encounter staff who were on leave, on the road or otherwise off-line during the process.

Additionally, since you're configuring a new system and moving users, it might also be a good opportunity for you to implement policy-based user administration, if you haven't already done so.

And finally, don't forget to modify MX or other DNS records that were pointing to the old system that Domino was responsible for (ie, Mail-routing, web, etc) during your transition period.

Whether it's rip 'n replace, or migrate, It's not a hard process to perform, all thanks to the flexibility of the Domino system.

Notes Rulez!

&nsbp