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.


Comments (18)
  1. Anonymous says:

    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

  2. thomas says:

    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.

  3. Ferdy says:

    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.

  4. Irv says:

    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.

  5. Mark says:

    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.

  6. Joe says:

    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."

  7. Siggi says:

    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.  

  8. Andy says:

    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…

  9. David says:

    I don't 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 this and scare some sense into them.

  10. PatRick says:

    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.

  11. Leen Kleijwegt says:

    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…

  12. Stuart McIntyre says:

    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…

  13. David says:

    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.

  14. 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!)

  15. fred says:

    @Luke… I can't believe I am feeding the troll, but ok. That's what it needs to be.

    Upgrades of Exchange are painful affairs. It's not 2 hours to upgrade a server, it's much longer. And, judging by all this, it won't get any simpler, faster or better. Great Innovation there. Microsoft.

    Microsoft has changed its storage engine substantially… Wow, that's really great. This after all the FUD that it was sooooooooooo superior to the NSF file format. Yup, so good they had to change it SUBSTANTIALLY. As for the crack that if it had remained unchanged, it would have wound up being something like Notes, that's an ignorant thing to write. There is something called "ODS" which is the On Disk Structure, which has been incrementally improved over the years to be faster, better and more efficient, including with the latest release 8.5.x to bring some amazing disk saving benefits. Ah, and all this, without breaking backwards compatibility. Something Microsoft can't do either.

    Yeah, bravo. I agree that IBM should become better at marketing, but Microsoft should try to live up to its hype. Its products come up short no matter the product line and Exchange is no exception, that's for sure.

  16. 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.

  17. Darren says:

    My general observation is that Microsoft make "substantial changes to [their] architecture" to implement things that clearly can't be fixed in the previous version. Remember active-active clustering, which had a dismal reputation? Rather than fix it, it was just removed, and came back at a later date along with a 'substantial' architecture change.

    Remember how Microsoft used to bang on about Domino taking up more disk space because of the separate mail box architecture? Maybe, but if someone else's mail box screwed up at least mind wouldn't be affected. I've been onsite with a prospective customer when the announcement went out – "sorry everyone, no e-mail until tomorrow". Now Domino handles the attachments in a more storage-friendly fashion while the mail boxes are still handled in that resilient way – meanwhile Exchange seems to have gone in the opposite direction in a bid to stabilise those all-affected corruptions. That Domino capability came in with version 8.5 which was a straightforward in place upgrade.

    "The migration model is well suited to most organizations" – I know of a company with 130 Exchange servers. The lack of in-place upgrade makes the process a mind-boggling effort. So I guess when you say "most" you're not including that customer.

    "Certainly to fully take advantage of the changes in the release requires rethinking the hardware design" – only if your solution of choice ends up being deficient on the up-to-date hardware. Don't assume that every e-mail solution falls into this category, because you'd be wrong.

  18. Mick Russom says:

    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.

Comments are closed.

Skip to main content