Change Creates Cutovers
One constant in any software environment is change. New tools, new techniques, and new applications are appearing almost daily. Implementing something new inevitably means there will be a cutover. Cutover efforts involve stopping production operations on a current system and installing something different. For some initiatives, this is a small effort and can be accomplished during normal business hours. For other larger, enterprise-wide initiatives, this means evenings and weekends. Some projects plan for three-day weekends to limit the downtime on production operations during “normal” business hours.
High Stakes, Short Timeframe
These large projects usually have months of effort that have preceded the cutover. Often, the success of the project is imperative to the company’s success and profitability. There is much at risk and the stakes are high---as are the pressures. To limit impact to customers, these cutovers are typically performed after Friday at 5 pm and completed before 8 am on Monday. That allows 62 hours to install, convert, compile, build, setup, verify, and back up a new system. Plus, there are many people involved and many moving parts, and the cutover must include all interactions and connection to all outside systems and integrations. A great deal of work needs to be done in a compressed amount of time.
Characteristics of Successful Cutovers
I’ve been involved in at least 100 cutovers. Here are a few key characteristics of successful cutovers that I’ve observed.
- Confirmation of readiness – project members have planned, prepared, tested, and verified the system and can attest to the readiness of it for production use.
- Excellent communication – project members must first plan the work and then work the plan. Everyone knows the roles, responsibilities, and can track progress. After all, how would anyone be able to tell if the effort is on track and on schedule?
- Double check – triple check. There should be no surprises and no new efforts that haven’t already been performed during this final cutover. “Dress rehearsals” or “dry runs” should have been carried out numerous times to routinize the process.
- Expect the unexpected. The goal is to have no surprises, but a good cutover will include contingency plans and procedures for when unanticipated events do arise. How will they be handled? How will they be discussed? How will they be resolved? When and who can make the decision to pull the plug and abort the cutover?
|“I love it when a plan comes together.” John "Hannibal" Smith (George Peppard) of the A-Team.|
Developing A Cutover Plan
Some believe cutover planning should take place at the end of project. I consider it to be an activity that occurs all throughout the project. Every step of the project should be considered in view of how it impacts the cutover. What happens to historical transactions? What happens to the prior data after conversion? How will relevant hardware be decommissioned and when? All of these questions, and more, need to be discussed in advance of the cutover and should not be left until the last minute.
Verification Checklists: Your Best Friend
A verification checklist is absolutely critical for a successful cutover. For all production operations, the project team needs a fast yet thorough way to verify the new system. And this checklist isn’t just a one-time use document. It can be used for disaster recovery efforts, modification installations, or revision updates. It’s the one document that should be a “living document,” describing your business and the plan for rapid verification of all aspects of the functionality.
There’s no doubt that cutovers are stressful, but with proper planning and good execution, they can be both successful and rewarding. I don’t know of a better way to build teamwork and comradery than to push through a cutover together. Some view it as the end of a long project. I view it as the beginning of a long and rewarding relationship.