Why Migrations Instead of In-Place Upgrades?

re: Why Migrations Instead of In-Place Upgrades?

Mick Russom — Fri, 13 Jul 2012 04:41:37 GMT

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.

re: Why Migrations Instead of In-Place Upgrades?

Ask Perry — Tue, 16 Nov 2010 19:40:53 GMT

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

re: Why Migrations Instead of In-Place Upgrades?

Darren — Tue, 16 Nov 2010 19:31:13 GMT

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.

re: Why Migrations Instead of In-Place Upgrades?

birdy — Fri, 12 Nov 2010 22:03:13 GMT

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.

re: Why Migrations Instead of In-Place Upgrades?

Fred — Wed, 10 Nov 2010 04:27:38 GMT

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

re: Why Migrations Instead of In-Place Upgrades?

Luke — Tue, 09 Nov 2010 22:50:33 GMT

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

re: Why Migrations Instead of In-Place Upgrades?

David — Tue, 09 Nov 2010 17:55:17 GMT

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.

re: Why Migrations Instead of In-Place Upgrades?

Stuart McIntyre — Tue, 09 Nov 2010 13:23:18 GMT

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

re: Why Migrations Instead of In-Place Upgrades?

Leen Kleijwegt — Tue, 09 Nov 2010 08:57:51 GMT

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

re: Why Migrations Instead of In-Place Upgrades?

Patrick — Tue, 09 Nov 2010 06:39:53 GMT

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.