Cutover vs. Migration

re: Cutover vs. Migration

BillT — Thu, 17 Jun 2004 06:49:00 GMT

Hmmm. Reminds me of the old saying "safe or sorry".

re: Cutover vs. Migration

Brian Schkerke — Thu, 17 Jun 2004 12:30:00 GMT

Even with automation tools there is an advantage to a cutover approach if you can afford it. Turning the key on a project is like starting a car engine. You either succeed and go full throttle, or you fail and fail hard.

Failing hard on a cutover isn't difficult. You roll back to the untouched old system. And you might go full throttle but have an extra loud engine, or some other unforeseen circumstance. Yet would you have found that problem with a slow ramp up? In my experience, probably not.

The biggest advantage to a cutover, IMHO, is that you don't get the stragglers -- the people who don't want to move to a new system because they hate and resist change. These guys can single handedly destroy a small shop project because they're so vocal.

I wager it all depends on the application and the company, and the risks the people involved are willing to take.

re: Cutover vs. Migration

Phil — Thu, 17 Jun 2004 21:24:00 GMT

I usually choose the all-at-once approach, and I usually regret the time it takes, since I'm a one man band.

My initial question to Doug was, "how long does testing take? Let's roll it out in the a.m., test it over lunch, complete the transition that night." But he's absolutely right, with all the destop visits to make it work correctly, particularly the more sticky bits, better to walk through it with plenty of sleep than force through it while working on fumes.

re: user whining: usually disappears like a bad dream when they see the [hopefully good] outcome.