Responding to Migration vs In-place Upgrade comments

There were some interesting comments from the last video entry, and they distilled into a few interesting themes that I wanted to respond to:

1) Perry, you seem to be living on a different planet than I do—one where spindles don’t last much longer than 4 years and where the capacity is doubling  every 18 months or so.

2) The key is virtualization

3) It is bad that software companies ‘decide’ when you should do your hardware upgrades

4) Users of Notes/Domino seem to be pretty interested in the Exchange upgrade experience

Before I go through those themes, I thought it would be good to put some data around what we saw in previous releases of Exchange.  One key data-point that was looked at carefully during Exchange 2007 planning was, even though the upgrade from Exchange 2000 to Exchange 2003 was a very straightforward process, as painless as the Exchange 2000 SP2 to SP3 upgrade, we were seeing 80% of customers choose a migration route and a large chunk of the upgraders had a considerable remorse when the inevitable migration of the hardware platform hit them a few months later. 

In some ways the product choices made back then constitute a good case study now that the results can be measured.  In Exchange we had some tough decisions about how hard to bet on 64bit architectures and whether to make some other pretty significant architectural improvements.  We went down this path—optimizing for 64 bits heavily, dropping 32 bit support in Exchange 2007 and a set of other big architectural bets. Forward ahead 7 years later and Exchange has drawn dramatically ahead in Enterprise Share with analysts like Gartner giving Microsoft the only “strong positive” rating in their 2010 MarketScope for E-Mail Systems report.

On to the themes…

1)  I framed this one a little unfairly. The lifetimes and the Moores Law constant for disk drive capacity growth are facts not opinions (and disk drives have been doubling every 18 months or so very reliably for a long period of time) so it really isn’t these facts that are in question but the implications that people are reacting to.  For Example:

“Well, I have the feeling we don't live on the same planet.
In my world, the servers hardwares keep running for more than 3-4 years.
The storage is not even part of the server hardware but rather attached to it and can be upgraded without impact on the server itself (SAN).
The CPU is hardly ever a limit, memory is. We, real admins, all know that memory can be upgraded fairly easily and we take hardwares that can evolve.
On the other end, that's true that roll-out migration gives up more work. We don't have enough, I guess.”

Ok, so you may be using a SAN but the fact remains even SANs benefit from the underlying trends. If you wait longer than 4.5 years to upgrade (8x improvement in $/byte) you can double the server storage and cut the storage cost by enough to get a less than 12 month payback just on the maintenance cost on the SAN.  You can get paybacks that are measured in a couple months if you replace the  expensive SANs with DAS storage and take advantage of the big HA investments in Exchange.  Going through the upgrade overhead and without taking advantage of the opportunity to drastically reduce your costs is not rational. 

2) Virtualization is basically orthogonal to the storage issue.  If the on-disk structures change, virtualization of the cpu-nodes won’t eliminate the need for a migration.  It will make deploying the new image on your servers pretty easy.  BTW if you are thinking about using virtualization and the implication of that is to consider SAN’s, don’t.  You can read more about my views of Virtualization here - Storage performance and my take on virtual storage

3) I would agree, that it would be bad for Exchange to decide when customers upgrade their hardware.  We don’t.  Admins get to decide.  We have a strong yearly cadence of  upgrades that includes significant new functionality through the Service Pack pipeline, and these are strictly in-place.  For our major release cadence we have found over the past two releases that significant physical schema changes drove huge ROI’s for our customers, however it is possible to reuse your hardware (and by implication forgo the ROI’s).  More importantly, you can upgrade and largely reuse your existing hardware even for the major releases.  This is especially doable in a virtualized space where you CPU nodes are very fungible and you are backed by a SAN-base storage utility.  It is basically a rolling upgrade.  It has the benefits of always being reversible, with no user downtime and should not require significant new hardware.  Again, you will necessarily miss out on most of the economic benefits of the upgrades.  But you do have the choice.

4) Great to see some Lotus fans on the site.  If, as so many of your peers have already done, you are getting interested in a migration to Exchange, it really is pretty easy.  This link is a great starting point: www.whymicrosoft.com/ibm

Perry