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