Lotus Domino is the central component in a messaging and document retrieval system capable of far more than email and scheduling - it can, for example, host a professional firm's knowledge management efforts or a collaborative work environment for ad hoc teams.
In the long run it's those other capabilities that could make consolidating to Domino a good idea for your organization - because you'll be able to do stuff, like deploy multiple portals concurrently or skip the Active Directory, Exchange, and Outlook upgrades coming with the next Microsoft server release, that just aren't practical in the traditional Microsoft client-server world.
From a quick and dirty porting perspective, however, Domino's simplest use is as the core element in a Microsoft Exchange replacement scenario aimed at consolidating multiple Windows based Exchange servers on one larger machine. The key to this is that you don't have to change all your Outlook clients to do it - according to IBM's features support comparison almost everything Outlook can do in an all Microsoft environment is now also fully supported in Domino.
Domino runs on just about everything too: meaning that your consolidation options include servers running major Windows variants, zOS, Linux, Solaris, and even AIX.
My hypothetical Sun pod, regular readers will recall, costs around 80K and includes the rack, oversize UPS, network gear, disk arrays, and at least one 16GB or larger T2000 processor. That gives it the throughput and reliability needed for the heart of a corporate messaging system - but the question for today is whether or not the T2000 hardware is a good choice for the job?
There's a very interesting three part series by IBM's Lotus performance team: ( Lotus Domino 7 server performance) that bears on this. Look at their stuff closely and you should conclude that the typical Domino server workload is a pretty good fit for the UltraSPARC T1 - high on I/O, heavy on context switching, naturally multi-threaded, and low on floating point demand.
By happy co-incidence, two of the latest filings with the Notes Benchmarking group, notesbench.org, offer just the comparison we need. The most recent of these features a four way, eight core, 3.0Ghz Xeon from HP running Windows/XP Server while the older, from last November, features a pre-release 32GB T2000 running Solaris 10 from Sun.
The results are extremely close. The eight core Xeon achieved a notesmark score of 15,395; the Sun T2000 reached 16,061. HP recorded an average response time of 0.434 seconds; Sun an average of 0.400 seconds. HP's listed total cost was $79,281 or $4.97 per notesmark; Sun's $82,860 or $5.16 per notesmark.
Be aware, however, that HP's pricing is highly suspect. For example, HP's on-line pricing as of February 12/06 puts the basic eight core, 8GB, 580DL/G3 at $36,313, not the $28,044 claimed in Appendix G of the detailed costing report. Similarly HP counts the cost for only four Domino licenses despite having eight cores -contravening IBM's stated policyk on licensing cores as processors.
Make the obvious corrections and Sun looks about 15% cheaper than HP before consideration of things like the additional 1,200 watts needed to run the HP. The real zinger lies in something that isn't obvious at all: these results were obtained before ZFS was integrated into Solaris 10 for SPARC - meaning that the same test done today would be a few thousand bucks cheaper and likely to produce a higher notesmark count.
Becoming an expert with Domino is not trivial, but the defining issue in moving from Microsoft Exchange on a bunch of Windows servers to Domino on one UltraSPARC T1 pod isn't technical. It's networking bandwidth: if your Exchange servers aren't centralized now you'll need to spend a lot of effort making sure that the bandwidth your users need to access the Domino server is in place and tested before proceeding.
In my experience most Windows services consolidation projects fail to adequately account for the network consequences of several thousand users doing something at about the same time - in this case checking their email on arriving at work, on returning from scheduled breaks like lunch or coffee, and just before going home. The network may not be your responsibility, and the local network guru may be assuring that all will be well, but users - and ultimately your bosses - will hold you responsible if your change to the email system causes delay for them.
Bottom line: test the bandwidth, and if it isn't there, abandon the project.
If the network isn't a constraint you probably won't run into anything else that qualifies as show stopper - or even much of a challenge.
A few years ago, for example, when IBM's Redbook: