My success was due in part to what I included in the plan — and what I left out. When creating a plan, some activities such as those unrelated to the final production cutover do not need to be included. Others need to be in your plan but not in detail. These activities can be summarized so the plan doesn't become unmanageable. Conversely, certain tasks must be included along with key points. Regardless of where you end your plan, for example, you must begin with data conversion and extend out from there.

I will provide you with definitions and examples that you'll need to develop your own cutover plan based on five key elements. As a result, you'll have a cutover plan built on a solid foundation that prepares you for the inevitable surprises.

Case Study

Let me tell you a little more about my project. Initially, I was the supply chain consulting lead, but by asking questions about the project's cutover plan, I suddenly found that I had "volunteered" to co-lead.

With go-live only six months away, the cutover strategy was increasingly critical to the success of the project, which was enormous in scope. In terms of applications, the implementation included SAP R/3 SD, MM, WM, LE, FI, CO, and BW, as well as delivery of 20 EDI transaction sets for customers, transportation service providers, and third-party warehouses. The project also called for installing a greenfield Siebel CRM system, while continuing to interface with legacy manufacturing, demand requirements planning (DRP), and forecasting systems. The deadline was November 1, 2003, for cutover across three customer service centers and 60 warehouse locations all over the US.

A cutover plan did exist, but it was very narrow — essentially a list of development objects. Critical components such as the conversion programs were in the plan, but to be successful the scope needed to expand. That was one of my first orders of business.

Five Key Elements

Figure 1 shows a sample cutover plan and the structure that I have been using for the past few years. On the top row are the key elements that experience tells me are necessary to manage the plan: task name, name of the team that owns the task and its cutover lead's name (Status), duration of the task, number of hours of work assigned to the task, predecessors, successors, start date, end date, percent completion, and resource.

Figure 1

A sample cutover plan

In addition to these columns, your cutover plan needs to allow for these five key elements:

• Data Conversions
  
  
• Validation
  
  
• Contingency Plans
  
  
• Blackouts, Freezes, and Downtime
  
  
• Dual Data Maintenance

Let's take a detailed look at these five elements so you can fully appreciate the importance of each. I will also offer insight into what to keep in mind while making critical decisions as well as a great chart that will allow you to closely monitor the progress. Note that the charts in this article are partial examples taken from the grids I created for my cutover plan.

Data Conversions

Converting data is one of the first issues people think of when considering a project, and this was the starting point for my cutover project. The two choices are between automated or manual conversion, and which method to use is not always apparent.

Automated conversions usually require more than one program. Typically an extraction program from a legacy system is coupled with a load program based on custom ABAP, the Legacy System Migration Workbench (LSMW), a Computer Aided Test Tool (CATT), or standard SAP load programs and transactions. Intermediate stages after extraction and before loading when the extracted data file is modified or cleaned up further may also be needed. General wisdom holds that automated conversions are used for high volumes of data, and manual labor is used for smaller loads.

Automated conversions were covered in the plan that I was given, but not manual conversions. As a process team lead as well as cutover lead, I knew of numerous cases where the project's functional teams had decided to load data manually. This most often was because the data volumes were too low to justify the effort of developing a functional specification for a conversion program and the development and testing efforts that would follow.

Timing plays a major role in data conversion if the volume is low but the task is still time consuming. This is particularly true if the conversion in question is on the cutover-critical path. Resources are the final factor to consider. Again, if you are running multiple conversion test cycles, consider whether your limited business resources will allow you to rerun the same manual conversions repeatedly. The lightly shaded teal area in Figure 2 highlights the data conversion management strategy of my project's cutover plan.

Figure 2

Data conversion management table of cutover (click on image to enlarge)

Validation

Data validation is critical to a successful cutover plan — data must be validated after every conversion or at least every automated conversion. Unfortunately, steps to verify data accuracy were absent from my project's original cutover plan. As with the decision process for conversions, your approach to validation needs careful consideration because you have several options.

One validation option is for project team members or business users to review converted data for reasonableness. Another is to review all data records against one or two key values that users are familiar with. For example, planners might be very familiar with the material requirements planning (MRP) type used for the materials they plan. A third option is to automate your validation. Rather than require your beleaguered cutover team to validate data manually, it may be worth writing a program to perform checks on complex conversions.

Note that you can use these validation methods in combination with each other. In addition, you can apply them to both data extracts (to verify the quality of the source data) and data loads (to verify the logic of the load program).

In Figure 2, notice that various areas provide information relevant to a team's validation efforts, including the columns labeled Conversion Strategy/Description and Data Cleansing Requirements. You may add more specific columns as required.

Contingency Plans

For each automated data conversion, a fallback plan should be established in case teams discover the need for a substantial data correction. Detailed contingency plans depend on the approach taken for the initial data load.

Manual data usually can be re-keyed if necessary. Large automated loads, however, may need to be reloaded, which can lead to other issues. You should consider the following questions before developing your contingency plan:

• Do you need to delete/archive the initial data load first?
  
  
• Can you run a change program to overwrite the incorrect data loaded via a create program?
  
  
• Do any "mass change" transactions already exist?
  
  
• Will you simply be able to reprocess batch data communication (BDC) sessions?
  
  
• Is manual correction an alternative?

The Conversion Strategy/Description and Data Cleansing Requirements columns in Figure 2 offer information related to contingencies. Additional information resides in the Conversion Object and Legacy Freeze Requirements columns, which I cover more fully later. You can customize your grid to better suit your particular plan.

Special Requirements

Make sure to inform all operations groups as early as possible of any special requirements for the cutover such as blackouts, freezes, and downtime so they can plan around them. Figure 3 offers a summary of my project's blackout, freeze, and downtime timeline. It was an invaluable communication tool for those on the project as well as for business groups that were affected by the cutover.

Figure 3

Production cutover timeline with blackouts, freezes, and downtime along with conversion activities

Determining this schedule may be the most critical aspect of the cutover, and it requires meticulous planning and communication. Let's take a look at blackouts, freezes, and downtime and differentiate each.

Blackouts

Blackouts are periods when the business must not undertake certain activities, like opening new warehouses or introducing new products. This is to prevent events that could disrupt the cutover. Blackout periods vary significantly depending on the type of data being converted. For example, new transactional data such as sales or purchase orders will be generated in a company's soon-to-be legacy system up to the last possible moment — usually right up to the final cutover weekend. In such a case, on the Friday night prior to cutover, a blackout goes into effect and no new sales or purchase orders, etc. are processed.

Evolutions such as bringing a new warehouse operation online have more far-reaching implications because they can require loading master data into a new location, or may require changing the location-specific logic in programs such as one that assigns orders to shipping centers. In these cases, a new location blackout period can be mandated earlier in the cutover timeline. At my consumer products client, the location blackout began one month before the final go-live.

Freezes

Freezes are similar to blackouts but usually are longer in duration. A blackout typically freezes data so that it does not change from the point of extraction to the time of loading into a new system. However, a freeze may extend the no-change period days or even weeks before and after the conversion. Freezes are usually associated with master data. Many consider master data static when compared with transactional data, but this is a false distinction. Master data undergoes constant change as customer addresses change, products are assigned new bin locations, vendors alter pricing, etc. Freezes cannot be allowed to shut down operations, but are necessary to create a window of stability.

Teams need to review every data conversion to determine if a freeze is necessary. The freeze portion of Figure 2 is shaded light gray. I used the graphic in Figure 4 to summarize and communicate freeze periods to the client.

In my project, the product master freeze began three weeks before the final go-live. This was negotiated with the business and communicated to all groups involved in the creation and maintenance of product data. These groups then were able to either accelerate planned changes to beat the deadline or delay changes until after the freeze was lifted a few days after go-live.

Downtime

While blackouts and freezes focus on data, downtime occurs for the entire system. Downtime essentially is a system shutdown and it has the most dramatic effect on a business. To minimize the impact on operations, downtime usually is focused on weekends. In particular, it is requested for the last big transactional data cutover that occurs on the final weekend before a go-live when time is short and teams are executing many conversions with interdependencies.

In my project, we needed to complete the open purchase order conversion (extract/load/validation), the open production order conversion (extract/load/ validation), and the month-end inventory conversion (extract/load/validation) before running MRP in the new system. Those results were fed to the DRP system. This stream of activity took most of the two-day weekend and any changes to the data elements during that weekend period put the success of the whole conversion at risk.

Beyond the critical final weekend, project teams may request additional downtime earlier in the cutover to accommodate similar complexities and dependencies. In my project, such downtime occurred during the several weekends prior to the final go-live.

Dual Data Maintenance

When freezes prove unacceptable and changes must be entered into the legacy system following a data conversion, it may be necessary to re-enter identical changes into the new system to keep the two in sync. This dual data maintenance is, of course, painful and may even require expertise that users don't yet have because they are not trained on the new system. You run the risk that dual entries will introduce errors, but it may be unavoidable, for example, to maintain customer master data.

Consider the following: customer data is copied into the new system long before the final customer order book is converted. In the interim, customer data changes and new customers are added, which affects the final order book conversion. You must accommodate these types of changes or stop your client from entering new orders and landing new customers. This would be the tail wagging the dog.

It is vital, then, to devise plans for dual maintenance. In low volumes, the work is likely to be manual and may even be considered an advantage because it provides a training opportunity for data management staff. When volumes become larger, however, the team needs to consider whether a change program is needed to replicate in new systems whatever changes are made on the legacy side.

As with freezes, every conversion should be reviewed to assess the need for dual data maintenance. The darker teal column in Figure 2 provided my team with information related to dual data maintenance.

By paying attention to these five critical elements of a cutover, my team managed to move from a list of conversion programs to a robust, detailed, technically sound, and business-supported cutover plan in only six months. Rather than a nightmare, the final stage of my project — cutover — was a happy ending.