A Plumber's Confessions

The blog of Doug Lawty, Microsoft Services Infrastructure Consultant

Blogs

Cutover vs. Migration

  • Comments 3
  • Likes

I had lunch with a friend today. He paid for it so he could ask my advice on a project he's undertaking. I'd have given him my advice without the lunch but it's hard to turn down an offer like that.

Phil's a one-man IT shop at a business with under a hundred desktops and he's completely changing their messaging system. As the appetizers came, we began to formulate an implementation plan.

It wasn't long before I realized that we had two different approaches in mind for the transition. I'll call them the “cutover” and the “migration.”

To complete the transition, changes at both the server and the client would be needed. And, since small companies don't often invest in automation tools for managing the desktop, a visit to each client was going to be necessary.

The cutover approach involved going in on Saturday when no one was around, ripping out the old mail system, building the new system, and moving all the clients to the new system by visiting each desktop. If everything went well, we'd end the day with a great sense of accomplishment.

The migration approach was all about doing everything needed to install the new system in parallel with the old. Test the new system while working out new processes with some carefully selected pilot users. Then, when confident in the new system, methodically (leisurely?) convert users over to it. Finally, when everybody's converted, decommision the old system.

It will take a little extra work to keep the two systems operating in parallel. But, the migration work can be done at any time without impacting users. This means Phil won't have to work Saturday and he'll have more time to work out the kinks in the new system.

I prefer the migration approach for its advantages in spite of the extra planning, additional effort and longer transition time. I think all projects should consider if this is a viable option.

Although this migration was a relatively small project, I should mention that I've seen the same concerns in projects much bigger when you'd think a cutover would be impossible. One large online banking migration chose the cutover approach and posted a “We'll be back at...” sign on their website Saturday morning while their dev team worked three shifts over the weekend. They were successful but there was a lot of risk in the approach and a lot of stress that weekend.

In the end, though, it was clear to me that cutover approach appealed to Phil's strong work ethic and his desire to get this project over with. I must reconsider my position and ensure that it's not rooted purely in selfish protection of the weekend (or even worse, sloth). What do you think?

(In case you're interested, by the time we completed our entrees, we had settled on a compromise between the two approaches and I'll be lending Phil a hand on an upcoming Saturday.)

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

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

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