In the past I have seen a lot of ERP project plans with a single-line entry called “go-live”, “cutover” or “final migration”. As I have argued in a previous post, this phase includes the cutover activity, which must be planned carefully in great detail and executed with precision.
Since I wrote that post, quite a few people have asked me:
“What should be in a cutover plan?”
In the following, I have tried to answer this question.
First of all, the cutover plan must contain a detailed list of all activities and their dependencies.
For each item in the cutover list I would normally record the following data:
- Status. In my experience the following status cover most scenarios:
- Failed, cutover continues.
- Failed, cutover terminated.
- Type of activity. In my experience the following types cover most scenarios:
- Automated script.
- Manual data entry.
- Application configuration.
- Infrastructure configuration.
- Physical work (e.g. change barcode labels on bins in the warehouse).
- Random control.
- Owner (who owns the activity and must report back to the cutover manager?).
- Planned start time.
- Estimated duration.
- Actual start time.
- Actual duration.
- Decision-maker (the person, who can make a decision to proceed or not, if an activity fails).
- Informed (list of people, who must be informed about this specific activity).
- Undo / Redo (a description on how to undo or redo an activity).
- Instruction (if an activity requires the owner to test a specific outcome or reconcile some data, a link to the instruction for this activity should be included).
- Dependencies (a list of predecessors to this activity – especially if activities are being executed in parallel).
Depending on your specific needs you may need other fields in the list, but these have served me well in the past.
In my experience it can be useful to place checkpoints in appropriate places throughout the schedule. If your list of activities is very extensive, some activities may fail, but the decision-maker decides to move forward anyway. Some activities may take longer to run or some unforseen event challenges the overall plan. The checkpoints can be used to gather key stakeholders to give them an overview and discuss how and if to proceed. If your activity list is short and the process well-proven probably you do not need checkpoints.
Ideally, the cutover plan should be accompanied by a plan that describes how you will fall back in the event of failure. It is difficult and cumbersome to align the fallback plan to each activity in the cutover plan so normally I align the two plans on checkpoint level. That also allows me to discuss more thoroughly with key stakeholders before deciding to fall back.
Key to a successful cutover is the ability to keep everyone involved informed at all times. The simple way is to give everyone access to the activity list (spreadsheet) and they can open it periodically to have a look. Alternatively, the cutover manager may send out the updated list at each checkpoint. On larger projects I have been involved with, the cutover manager has managed the list in SharePoint with a BI tool on top to allow users to see progress in a graphical format.
Using the cutover plan for trial migrations
The last topic I would like to touch on is this: in the past I have found that developing the cutover plan as part of the on-going trial migrations can be extremely useful and by basing each trial migration on the provisional cutover plan you also start testing and proving your plan. Very often I have seen trial migrations focusing on the technical side of migrating data without ensuring that this migration is aligned with manual activities and reconciliation activities. By going through the cutover plan each time you perform a trial migration you prove the plan and start building more accurate timings.
All in all, this is not an out-of-the-box template for a cutover plan, but I hope this gives you enough inspiration to build your own plan based on the spceific needs of your projects.
Good luck cutting over…