I’ve noticed that even experienced team members are confused between cutover and integration testing. Cutover is not meant to test the system’s functionality or validate data. Instead, cutover captures the realistic downtime for the production system. During the cutover period, all systems (SAP and legacy) are down and unavailable for business use.  This downtime should be as short as possible and should be during the weekend so as not to affect the business.

As a cutover manager for release, you are responsible for defining, planning, communicating, simulating, executing, identifying, addressing, resolving, and escalating issues and risks. I’ll walk you through the steps you should take to ensure a smooth cutover. First I’ll go through the three phases of a cutover and then I’ll help you develop an ideal cutover plan. 

The Three Cutover Phases and the Project Plan

As Figure 1 shows, a good cutover plan reflects three different phases. A toolbox checklist download for each of these phases is available: Checklist for Cutover Deployment Project Activities.

Figure 1

Sample cutover plan in Microsoft Project

Phase 1. Pre-cutover. You capture all actives that can be performed before the system is brought down for cutover. These activities — such as preparing data files for data conversions, creating security profiles and roles, and clearing system logs and buffers — help reduce the overall system down time.

Phase 2. Cutover. In this phase, the system is locked down to all users except for team members with a cutover task. The main activities during this period are transport imports, data conversions, data reconciliation, system checkout, and business sign-off and the go or no-go decision.

Phase 3. Post-cutover. These activities are carried out after the system is turned over to the users. You schedule all the batch jobs and set up hotlines during this phase. Lessons- learned documents are created for future deployments. In addition, you recognize team members who went above and beyond and maybe even have a go-live celebration party to celebrate success.

In addition to the three phases, dependencies between different tasks and the duration of these dependencies are important to include in the project plan. The project plan should also capture the right resources (primary and backup) to execute the tasks. Only team members on the plan should have access to the SAP system, based on the task they perform.

If this is your first time going live with an SAP system, I recommend three cutover simulations before the final go-live. For experienced implementation teams, two simulations are often sufficient. I discourage more than three simulations because this may be counter-productive and a drag on team members already buried under data conversion and integration test cycles.

During the first simulation cycle, your aim is to capture all the cutover steps with the right resources assigned. During execution, capture the actual time lines, missing tasks, and lessons learned. Cutover is executed 24/7 and resources should be available for the tasks assigned to them on the project plan. Use the second and third cycles to build on what you learn after the first cycle.

You should reserve a meeting room to use as a cutover room. All tasks should be performed on site in the cutover room (with very few exceptions) to avoid any delays, such as VPN issues or slow network connections. By the third cutover simulation, the project plan should reflect all tasks with exact timelines and dependencies, contain the correct resources with the correct access to the SAP system, and identify all subject matter experts (SMEs).

The Cutover Team

The cutover team includes the cutover manager and cutover leads from the various implementation teams, such as development, SAP NetWeaver Process Integration (SAP NetWeaver PI), Basis, Security, business communications, and compliance. The cutover team:

• Captures all tasks accurately
• Assigns the appropriate resources to the tasks
• Provides team members with the proper access to perform the tasks
• Ensures resources are on site when they execute their tasks
• Updates the project plan after each task is executed
• Escalates issues and risks as necessary to the cutover manager

In addition to the actual SAP tasks, as the cutover manager you should ensure that facilities such as teleconferencing, phone services, access to buildings, and electricity are not interrupted. In one of my past cutovers, facilities shut down water for planned maintenance for six hours on a Saturday, which created some challenges.

Critical Success Factors

I developed this list of critical factors from the lessons learned after an implementation project I worked on with a company to help it move from a legacy system to an SAP system. You can adapt this list to better align with your business needs.

• Estimate timelines
• Control versioning
• Ensure SAP security cutover ID access to cutover users
• Develop a conversion strategy
• Address transport issues
• Ensure facilities are available
• Identify standard templates and forms
• Communicate with stakeholders
• Manage batch jobs
• Create a theme and recognize outstanding team members
• Develop the sunset strategy
• Address post-go-live support
• Create a lessons learned document

Estimate Timelines

A cutover is not intended to test the functionality of an implementation. Testing is done during conversion mocks, integration test cycles, and performance and regression testing. Rather, the purpose of cutover is to capture realistic timelines for bringing the new functionality (i.e., the business processes) into your SAP system.

The estimation of the timelines is one of the most critical factors in a successful cutover. The timelines forecast provides the timelines for the cutover period for the production system, sets expectations with all the stakeholders, and identifies the availability of resources to execute tasks captured in the project plan.

As a cutover manager, ensure that resources do not perform a task that is not on the plan. This allows you to capture all the tasks, the proper resources, and accurate dependencies. If you plan to have three simulation cutover cycles, your go-live cutover should look exactly like your third simulation.

Figures 2 and 3 show what a high-level cutover deployment plan looks like. We are able to squeeze the actual time line from ~92 hours to ~42 hours during go-live.

Figure 2

The timeline for overall cutover (simulations and go-live)

Figure 3

Go-live deployment timelines

Control Versioning

The cutover manager should be the only one who controls the versioning of the project plan. Changes during the last simulation should be discouraged and should be approved on an exception basis after getting approval from the Project Management Office (PMO). Too many versions of the plan creates confusion. They affect the plan timelines and may result in a resource executing a task incorrectly. Any changes to the plan should be immediately communicated to resources who will execute the tasks within the next few hours after the update. No task on the plan should be allowed to start unless there is a two-way communication between the resource executing the tasks and the cutover deployment personnel.

Ensure SAP Security Cutover ID Access to Cutover Users

Only team members listed on the project plan with tasks should be granted access to the SAP system to perform cutover tasks. All other users should be locked out of the system. It is the responsibility of the cutover leads from each team to capture resources executing the tasks and capture the SAP transaction code access needed on the project plan.

The most common issue that significantly delays the critical path duration is insufficient or incorrect access to the SAP system when users try to perform their tasks. Any delays on the critical path extend the duration of the cutover. You can resolve delays due to access issues with the following:

• Provide all cutover team members access to the systems during simulations and maintain accurate access requirements in the project plan against their tasks

• Create a staff cutover room with security team members to address access-related issues

• Team members on the plan should verify their access as soon as the system is open for cutover tasks rather than wait until their tasks. Any discrepancy in access should be communicated, fixed, and updated in the project plan.

• During the cutover process, security should turn off audit logs to reduce the effect on conversion load performance. For example, HR structural authorizations heavily affect the data loads.

Develop a Conversion Strategy

Almost half of the cutover time is consumed by the data conversion loads. To optimize the time, you need to have an effective conversion strategy.

• Work with the data conversion lead and SME to optimize data conversion sequence and dependencies

• Involve your Basis team in monitoring the batch jobs and table buffers. As needed, your Basis team can index the tables, monitor processor usage, and load balance the application servers to improve system performance.

• Large files (e.g., customer master, vendor master, and general ledger loads) should be split into smaller files and loaded concurrently in background jobs

• Data conversions should be designed with restart capabilities. There is a high probability that the program will short dump due to either batch job termination or memory issues.

• Before you begin any migration of data, be sure that the data has been consolidated and harmonized in the legacy system or on an external system to reduce the overall duration of the load in the SAP system

• Validation sampling should be a random sample with a good amount of data. Business teams should validate this data by comparing legacy screens to SAP screens to make sure the expected outcome is achieved. For conversions of systems with large volumes of data, you should automate the reconciliation process using an application such as Microsoft Access.

• Your development team and Basis team should monitor large tables and logs and reorganize the tables periodically during the conversion to make sure there is enough buffer memory. This improves the system performance, and the data conversion will load more efficiently as a result.

• Maintain the conversion form after each load on a standardized template. This helps you and your team have an accurate idea of the record count, load duration, load rate, and error rate.

Address Transport Issues

Transport sequencing issues may delay and pose a major risk to the overall cutover process. To avoid these issues, do the following:

• Each team should finalize the sequence of the transports and confirm the sequence during the last simulation

• Avoid creating new transports during the cutover go-live. Any new transports created during this period may adversely affect the go-live process because you do not have an opportunity to test the functionality multiple times.

• Logically group the transports into three or four batches. Also, back up the transports from the production client at logical intervals. This eliminates issues related to the failure of transports for standard SAP table extensions. For example, I faced an issue with the VBAP table extension, but by grouping all the sales and distribution (SD) transports from HR, accounts payable (AP), and Financial Accounting (FI), I was able to eliminate the failure in the second simulation.

• After the transports are imported — and before any manual configuration — all teams should check the system checkout to ensure that all the transports made it to the client. Make sure all the configuration items and custom programs are validated.

Ensure Facilities are Available

The cutover team should have a dedicated room for about a two-month period (based on the size of the implementation). This room should have 10 to 15 work stations along with phones and LAN access for everyone. A projector should be available as well. All instructions, FAQs, important phone numbers, and the project plan must be available,  posted on the walls or whiteboards for example. During the go-live cutover simulations, this room should be staffed round the clock by a cutover manager or representative, as well as Basis, security, and development team members. If you have international remote resources, be sure there is a cutover room set up in the remote area and a working communication channel between these two cutover rooms.

Make sure that there are no power outages or air conditioning or water maintenance scheduled during the project time. Also make sure the teams have access to the building and floor during off hours. Remember that people are working all the time in the cutover room — keep the room well-ventilated and be sure it is kept clean.

Identify Standard Templates and Forms

Before the start of the cutover deployment process, you need to identify standard templates and forms used in your company. For example, you can use the conversion form to report the progress and completion of conversion with details such as the number of records received, loaded, or failed, issues, time taken, and responsible team members.

You use a status message form to provide the status of the cutover for your stakeholders. This Web or HTML form should be displayed on the cutover Web site for your stakeholders. Furthermore, the cutover manager (or the manager’s representative) should use a standard form to communicate the start and end of each task with the cutover resources.

Communicate with Stakeholders

To set clear expectations about the cutover, you need to maintain communication with all stakeholders. Their support and commitment is the key to a smooth cutover process. You can assign the task of communicating specific project-related information to various members of the cutover team members.

All the stakeholders and the PMO should make every effort to join the meeting. Team members should honestly bring up any risk they see. The SME should be included in the meeting to tackle any unresolved issues and to mitigate any potential risks or issues. Some sample types of communication include:

• Cutover kick-off meetings held by the cutover manager

• Business readiness (BR) communication by your BR team. This can be done via the company Web site, emails, or brochures.

• Status emails from cutover and Web link updates on the cutover at regular intervals from the cutover manager or a representative

The cutover manager should escalate any major issues immediately to the PMO. In addition, all important phone numbers, FAQs, project plans, and issue lists should be placed in the cutover room. The cutover manager or representative should update all the plans frequently with the current status. Furthermore, the cutover status hotline should be updated every two to three hours. The hotline update should include the tasks completed, tasks in progress, and tasks to be done in the next four hours. The update should also include any expected delays. Figure 4 shows sample messages for the cutover room message board.

Figure 4

Sample message board update

Manage Batch Jobs

Identify a batch job coordinator and test all the interfaces during the integration testing phase. All existing jobs should be kept on hold during the cutover period. Any critical jobs should be run before cutover starts. After the cutover, the variant for the jobs should be adjusted to pick up data during the cutover period. Connections to external applications and third-party applications should be set up and tested before the cutover. The cutover schedule should be communicated to team members on external and third-party applications, and they should be available to verify the receipt of files and note whether their formats and data are accurate.

Create a Theme and Recognize Outstanding Team Members

Have some fun. Come up with a theme that fits your implementation. For example, you could call your project “The Great Migration.” Encourage team members to come up with fun ideas. Provide activities such as a magnetic dart board, cubicle basketball hoop, and board games.

Be sure to recognize team members who went above and beyond. During the weekly meeting hosted by the PMO, describe the individuals or teams whose contributions help make the project successful. The cutover manager should personally congratulate them and, if possible, present them company goodies and gift cards per your company policy.

Gestures like these create ownership, boost morale, and motivate others to come forward and go above and beyond.

Develop the Sunset Strategy

Identify systems that will be sunset after SAP goes live. Make a detailed project plan and communicate the processes of locking the existing systems to the users. Here is an example: At my company we moved from our existing legacy travel and expenses (T&E) system to an SAP T&E system. We communicated with all of our employees on the T&E page and via global communication emails the last day of expense entry in the legacy system and the first data expense entry in the SAP system. We also included help links.

Address Post-Go-Live Support 

Even a successful go-live will encounter issues related to data, user access, functionality, or training. It is a good idea to create a “super care” team with SMEs to support issues for the first four weeks. This super care team should comprise functional, business, security, and Basis team members. This team helps the business user become comfortable with the system. You can periodically send surveys to the users to obtain feedback and improve the super care process.

Create a Lessons-Learned Document

A lessons-learned document is a critical component for successful future releases. The cutover manager should meet with team leads and members who executed tasks during the cutover to brainstorm about: 

• Things that went well
• Things that did not go as well and can be improved
• Things that did not go well at all, why, and what should be done
• Things to avoid

Hold these meetings in two to three different sessions and consolidate the feedback into one list. This list should be presented to the PMO and the leads and saved in a knowledgebase.

Table 1 provides some of the common issues my team and I have encountered and what we did to resolve them in a timely and efficient way.

Srini Munagavalasa

Srinivasa (Srini) Munagavalasa has 14 years of experience in various SAP modules. Srini has worked on multiple SAP global implementations at major clients. He has experience as a project manager, deployment lead, build manager, and technical development manager.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.