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.

I stumbled upon the wikipedia definition of FUD which happens to showcase IBM and Microsoft for their examples.  It is worth reading the entry in its entirety, but here are two good exerpts.  While IBM is given credit with the original exploitation, they appear to have abandoned the practice while Microsoft has perfected it:

The idea, of course, was to persuade buyers to go with safe IBM gear rather than with competitors’ equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people who stuck with IBM, but Dark Shadows loomed over the future of competitors’ equipment or software. After 1991 the term has become generalized to refer to any kind of disinformation used as a competitive weapon.

And this:

Although originally associated with IBM, from the 1990s on the term became most often associated with software industry giant Microsoft. Roger Irwin said:^[8]

“

Microsoft soon picked up the art of FUD from IBM, and throughout the 80’s used FUD as a primary marketing tool, much as IBM had in the previous decade. They ended up out FUD-ding IBM themselves during the OS2 vs Win3.1 years.

”

The leaked internal Microsoft “Halloween documents” stated “OSS [Open Source Software] is long-term credible… [therefore] FUD tactics cannot be used to combat it.”^[9] Open source software, and the GNU/Linux community in particular, are widely perceived as frequent targets of Microsoft FUD:

• Statements about the “viral nature”^[10] of the GNU General Public License (GPL).
• Statements that “…FOSS [Free and open source software] infringes on no fewer than 235 Microsoft patents,” before software patent law precedents were even established.^[11]
• Statements that Windows has lower total cost of ownership (TCO) than Linux, in Microsoft’s “Get-The-Facts” campaign. It turned out that they were comparing Linux on a very expensive IBM Mainframe to Windows on a PC.
• Statements that “If an open source software solution breaks, who’s gonna fix it?”^[12]