Udostępnij za pośrednictwem


Why Migrations Instead of In-Place Upgrades?

After a brief break from blogging, I was back in the studio recently recording more videos to answer questions about Exchange design decisions.

Now most of the time I talk to customers about new functionality that we have added to Exchange, and for the last few blog entries I have focused on some of these changes related to storage and archiving.

In this entry I wanted to cover another topic which gets asked about a lot – why did the Exchange team not include an in-place upgrade option in the product in recent versions? Is it that the Exchange team is filled with a bunch of lazy developers or are there valid reasons for doing this? 

I was going to stop there and let you watch the video (which I encourage you to do!) but I thought I’d give you a sneak peek into what the answer is, so here are some of the major points:

  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.

The video covers a lot, including the online mailbox move feature. I'm interested in any questions or comments these answers generate. Let me know what you think.

Perry

Comments

  • Anonymous
    January 01, 2003
    Thanks for all your comments -- I've just published another blog entry to answer many of the issues which were raised. blogs.technet.com/.../responding-to-migration-vs-in-place-upgrade-comments.aspx

  • Anonymous
    November 08, 2010
    Excuse me, but did you ever hear about virtualization? You know, you can add RAM and processor power dynamically there. No need to move to a new machine. Luckily, I don't really have to care. My last major version upgrade ( 7 to 8.5) of Lotus Domino was done in 45 minutes. Remotely from home. No coexistence needed.

  • Anonymous
    November 08, 2010
    It is ridiculous that a software vendor gets to decide that their clients need to replace their hardware, no matter how large your technical changes are.

  • Anonymous
    November 08, 2010
    I've upgraded the last few versions of Domino on our overseas servers from my desk in the US for the price of a FedEx envelope.  Upgrade time:  30 minutes.  You've got to be kidding me.

  • Anonymous
    November 08, 2010
    Yeah I'm sorry, but that sounds a lot like a desperate defense of the indefensible.  We administrators are perfectly capable of analyzing our hardware and it's capabilities ourselves.  We don't need Exchange Developers deciding for us whether or not we need to upgrade our hardware with every single major release. Name another major corporate application that requires a hardware refresh with every upgrade?  I can't think of one. This is a HUGE flaw in your product that you keep forcing on us because you are large enough to act with impunity.  That makes me very angry and less willing to recommend your product to anyone.

  • Anonymous
    November 08, 2010
    I'm guessing this is part of 'herding' existing Exchange customers to the Microsoft 'Cloud'.  "Exchange Hosting offers you the latest and greatest without ever having to upgrade your hardware again for the sake of well, upgrading."

  • Anonymous
    November 08, 2010
    We are currently migrating to Lotus Domino 8.52 from Exchange 2010.  The time where Microsoft dictated our IT strategy is over.  Do not believe that MS's strategy will fly with Generation Next.  When Steve Balmer is selling 50 million of his MS shares, he know this.  Good Luck with migrations, you still have the choice to upgrade to Lotus.  

  • Anonymous
    November 08, 2010
    I did a Lotus upgrade for a company that only supported MS, it was a 6.5 to 8 from memory. They had allowed 2 days to do it, when it was finished in under 10 minutes they stopped bagging Lotus...

  • Anonymous
    November 08, 2010
    The comment has been removed

  • Anonymous
    November 08, 2010
    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 faily 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. Also +1 with Thomas comment.

  • Anonymous
    November 09, 2010
    The man said: businesses change their hardware every 3 to 5 years. I really don't believe that there is a single admin in the world who doesn't want this. There are more products that can deliver, so stop bashing and be happy with the products you use...

  • Anonymous
    November 09, 2010
    Sorry Perry, but I can't even believe you're trying to justify this as anything that a customer would want.   Sure, give them the option to migrate and use new features/architectures, but to not offer in-place upgrades is effectively to tell them that you have no interest in protecting their investment in their hardware, OS and other infrastructure. Ah hang on, of course, by mandating migrations, you can ensure that your customers also upgrade the latest MS OS, management tools and the rest of the stack.  Thus ensuring that they have no choice but to continue paying for vital (to MS) software assurance dollars.  Now, that makes more sense...

  • Anonymous
    November 09, 2010

  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?  Our company doesn't give a rat’s a** 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.
  • Anonymous
    November 09, 2010
    Is everyone really that concerned to save a 2 hour server build every 3 years?    If it makes more sense in your procurement/project schedule to wait a year until you buy more hardware, that's no cause for alarm.  Hold out for a year. But I'd really recommend virtualising Exchange to anyone who hasn't done it yet.  It all becomes moot.  In a virtual environment, hardware purchases & software upgrades/server migrations are unrelated to each other anyway. In fact, once you've virtualised, choosing to rebuild a server because you have to change hardware is the choice that starts looking back-to-front.  All you need is a bit more capacity, or maybe the hardware maintenance/lease has run out - why be reinstalling everything then?  Just bolt your new servers into your vSphere farm.  The busiest server VMs will just move across, no software reinstalls needed. Personally I'd rather do rebuilds when software actually changes.  You get a clean build without the cruft of the last version.  And the admins learn how the server hangs together.  But you don't need new hardware, just a replacement VM.  Move one storage group across at a time, live, during business hours, and the load on the farm remains constant (the load on the old VM decreases to match the increase on the new VM). Microsoft have changed Exchange storage engine substantially, that's good.  Sure, they could have kept the technology unchanged for ages, and yes, that's right, you then would end up with something like Notes. (Sorry, couldn't resist!)

  • Anonymous
    November 09, 2010
    The comment has been removed

  • Anonymous
    November 12, 2010
    I'd never do an in-place upgrade of my mail system.  I'd always prefer to deploy new hardware (really now deploy new VMs) and have them co-exist.

  • Anonymous
    November 16, 2010
    The comment has been removed

  • Anonymous
    July 12, 2012
    Garbage. In place is about making things simple. All they have to do is make a new scheme and database based on the old information. The devs are lazy and no-too-sharp and they want to charge for a new product without helping out the people with the old generation. I 100% reject no in place upgrades, even with virtualization and ll the rest of the rubbish going on. Nothing changes. The User is being told we have to endure pain for the greater good. All the time. In every direction.