Software Suicide: Microsoft’s hangs itself with “Why Migrations Instead of In-Place Upgrades?”

In response to Perry’s blog at Microsoft: “Why Migrations Instead of In-Place Upgrades?” He gives 5 bad reasons:

  1. Surprise! It’s not about the laziness of the Exchange Devs
  2. In major releases we tend to make substantial changes to our architecture to take advantage of exponential changes occurring on the hardware front. Doing this in a backwards compatible way often leads to substantial compromises that leads to a more expensive and less reliable TCO.
  3. Certainly to fully take advantage of the changes in the release requires rethinking the hardware design. Over the past couple of releases, doing this properly will reduce costs so substantially that continuing to run the old hardware would be un-economic even through it is fully depreciated.
  4. Given the rapidly improving hardware and the fact that the most expensive component (storage) wears out. Regular hardware refreshes in the order of every 3-4 years are needed. Doing both a major-version in-place upgrade followed by a migration to new hardware is a model that combines the worst of both approaches
  5. The migration model is well suited to most organizations because it allows you to move your least sensitive mailboxes first, your most sensitive mailboxes ( execs? application mailboxes?) last and have a great coexistence story.

Here is why I say they are so bad:

1.  Yes, it is a sign of laziness.  Not lazy developers, but lazy product designers and product managers.  Henry Ford’s engineers insisted they could not make a car for $800, but he kept sending them back to work until they did it.  You could learn a lot from Henry Ford.

2.  That just  reflects a poorly designed product.  Other brands of products are able to take advantage of the new hardware architecture without compromising cost or reliability.  In fact, NO OTHER SOFTWARE on my computer or in my server room requires a hardware replacement to be upgraded. Not any software by any other manufacturer.  NONE.

3.  If your software design requires rethinking every 3 years and forces a redesign of the hardware and a replacement and is intolerant of backward compatibility, then not enough vision and planning is going into the product.  That is also driving up the TCO unnecessarily.  As a business owner, I would be willing to give up some of the minor performance gains you provide through tweaking the hardware with every new release if it means I can let *my* needs drive hardware replacement rather than *yours*.

4.  Thanks for forcing me to make my hardware upgrades when you want them instead of letting me decide.  Your assumption of a 3-5 year hardware life cycle is true for some companies, but not all.  That is a very broad range and I expect software upgrades more often than I expect to upgrade hardware..  If you provide a major release every 3 years and I plan to upgrade hardware every 4-5 years, then you are forcing me to either replace the hardware before I am ready or to continue to use old software.  Also, even if I am replacing my hardware as often as upgrades are provided, the timing of those events do not necessarily coincide.  I may have to replace the hardware before you come out with that major release.  What do I do then?  Wait another 4 years for my hardware to get old before I upgrade the software or do I buy all new hardware again?

5.  Great coexistence story?  I don’t give a rat’s ass about stories.  I am not running software to provide stories for your marketing.  I want to be able to use the latest software with the least amount of risk, pain, expense and disruption in my business as possible.  I want the flexibility to manage my computer systems as my business needs, not yours.  If I have to make a migration anyway, I think this is a great opportunity to look at migrating to a different platform.  I know Lotus Notes and Domino don’t strong-arm me into purchasing hardware and they come out with major releases about every year.

I don’t know anyone who looks forward to migrating their software.  Why on earth would you intentionally build this requirement into the design of your product?  That is software suicide.

If you have an executive looking to migrate to Microsoft, share these points to scare some sense into them.


Posted on November 8, 2010, in Uncategorized. Bookmark the permalink. Comments Off on Software Suicide: Microsoft’s hangs itself with “Why Migrations Instead of In-Place Upgrades?”.

Comments are closed.

%d bloggers like this: