A cutover to a new or upgraded HR system focuses squarely on the go-live date, and missing this date negatively affects all areas of a business. If the project’s scope includes payroll, then tax and pay implications potentially impact every employee of the company.

I think of implementing a smooth and painless cutover as an art form. You should design your cutover plan to meet the challenges of the real world, including high volumes and intricate relationships among many types of systems. An effective cutover plan must address this complexity head-on. A good way to start your project is to gather the appropriate skill set, which depends on project characteristics such as size.

The magnitude and complexity of a cutover process depends heavily on several variables:

• Multi-site versus single site
  
  
• International versus local
  
  
• Inbound and outbound interfaces with the new system
  
  
• Timing, especially for payroll and tax implications

Certain principles and considerations are valid no matter what the project size. I’ll provide the most important ones so that you can use them as a checklist for your next cutover. This list is not complete and is in no particular order, but it has always helped me to steer toward successful go-lives.

1. Make a Separate Cutover Plan

The central project plan may not contain the details of the specific tasks you must perform for cutover. Cutover planning requires a different mentality in which you zero in on the go-live process. The immediate impact of switching over to a new system often reveals a long list of one-time tasks that the project plan may exclude. For instance, say your company replaces a standalone recruitment system with SAP’s Recruitment module and decides not to transfer any records more than a year old. That means you need to print all prospective employee records from the existing system. The general project plan could easily overlook such a specific requirement and no one would discover the problem until an end user needs to look up a record from two years ago. Two years later, it may be too late if you didn’t scope this requirement during the project cutover planning.

A separate, detailed cutover plan is also required for operational reasons. Many tasks in a cutover may last less than an hour. It’s critical to update the status of these jobs so you can start any task dependent upon another task’s completion on time. You should update the cutover plan after completing jobs, sometimes two to three times a day, so that you can schedule multiple jobs per day.

Consider how to monitor your cutover. While project-planning tools such as Microsoft Office Project (MS Project) display task dependencies, such programs may not act effectively in a dynamic environment in which multiple people are trying to update progress statuses at the same time. A spreadsheet can collect the progress information and run a Microsoft Excel macro to update the status in the main cutover plan. Otherwise, you could create the progress spreadsheet by copying and pasting the spreadsheet view of MS Project. When you have the progress information, you could again copy and paste it back to MS Project as long as you have not changed the sequence of tasks between the two activities. The latest version of MS Project possesses better sharing capabilities that you could use if all your resources can access it.

2. Run a Mock Data Conversion

After the functional teams have determined the scope of your data conversion and you know all the data that you must convert, develop these conversions. You can use ABAP code or utilities that are available for such conversions, such as the SAP-delivered Legacy System Migration Workbench (LSMW) tool. The most common conversion is the employee master, with all the Personnel Administration (PA) infotypes that the implementation requires. I suggest running these programs and utilities before go-live. This allows you to review and correct in advance any character combinations that the conversion program cannot handle.

You should also know the available time window to complete your conversions so the go-live can take place as scheduled. You can estimate this by measuring the timing in test mode by passing through a production-comparable volume of data through your data conversion utility. Remember that the speed in the production environment differs because of the variations in instance size and network speed. Your production environment should be faster than your development or quality assurance environments.

3. Remember Outbound Interfaces

Inbound interfaces affect the system that is going live more than outbound interfaces, but you cannot ignore outbound interfaces. Some of the new system’s processes may depend on inbound interfaces, such as global effort analysis and payroll. The major pieces of inbound interfaces probably belong to the main project plan.

The outbound interfaces need similar attention to ensure continuity. You may expect to run an interface at a certain time to make records available by a certain time. The only way to meet these expectations is to include them in the cutover plan and execute the plan in test mode before go-live. The amount of monitoring required depends on the relative importance of the outbound interface.

4. Prepare a Back-Up Plan

You don’t want to miss your cutover date, but it’s best to prepare for the worst. A recovery plan allows you to minimize a missed cutover date’s impact to the business. The contingency plan can vary in complexity and importance depending on what modules are going live. For instance, when implementing SAP Payroll, you could plan to keep the earlier payroll system active until the new system works. Keeping it active does not necessarily mean processing transactions. In many cases, it may stand by in case it is required.

Timing plays a major role in your recovery plan, especially for payroll. You must carefully set up all components of the new system to ensure business continuity. Some parts require significant time to prepare. If payroll fails to go live, you may not have enough time to enter all timesheets in the old system to process payroll. In that situation, you may need to develop a conversion program that converts SAP timesheets into legacy timesheets, then test and execute this program. In the meantime, resort to your contingency plan.

5. Rethink Your Data Conversion Sequence

You should not blindly follow the sequencing of conversions required by SAP data structures. The sequence of conversion activities is important to the real conversion. Dependencies exist between data types that dictate the sequence of loads. For instance, you must load the job object before loading its planned compensation record.

However, you should investigate alternative sequencing. For example, if you activate Organizational Management (OM)-PA integration, you need to load the organizations and positions before loading the employees. It is possible, however, to load employees, load organizations and positions, and then load the position assignment of the employee. You can handle the integration by running program RHINTE00 directly after to update the PA infotype 0001 from the position information in OM. This might provide better flexibility while testing the applications, as well as decrease the time required for conversion by introducing more parallelism.

Work on converting data before the data conversion programs are ready. Performing a conversion with an unfinished yet coded conversion program tests key aspects of the conversion and validates assumptions you’ve made about data.

6. Plan for Business During Conversion

Cutover and conversion are not instantaneous. When converting and preparing production data for go-live, the business has to continue its normal activities. It’s important to develop a strategy to handle transactions that originate after the production conversion starts but before go-live. Evaluate processing options and plan to incorporate them into the system to save your organization from nasty surprises.

In most cases, manual capture of data and entry into the system through normal SAP transactions works just fine. However, ensure that people responsible for these transactions know to manually record them as completely as possible so that the project team can effectively enter them after go-live.

Choose the timing of the conversion to reduce or eliminate manual entry. For instance, in many companies, recruitment follows a standard pattern. If your company makes no recruitment decisions between the December holidays and New Year’s Day, for example, consider late December for HR personnel data conversions.

7. Communicate with the Project Team

Communication should not just focus on the new system. Aspects of communication deal with the legacy system. A strategy for disabling legacy functions is important for several reasons, such as support contract termination and historical data retrieval strategy for data warehouse applications. These are not directly connected with the new functionality, so the overall project team may not discover them without a specific investigation of cutover requirements.

This investigation often reveals indirectly impacted systems that use data extracted from other systems that in turn depend on extraction from the main application the project is replacing (e.g., retirement, stock options, and occupational health management systems). You need to inform the custodians of these impacted systems in advance about the impending changes. Benefits certainly exist for centralized project communications (format standardization, comprehensive distribution, single point accountability), but the communication team must consult with the cutover team to ensure complete coverage.

8. Hold Lessons-Learned Meetings Early On

Often, teams postpone lessons-learned sessions until the system has gone live. Lessons presented at the end of the project are only useful for the next project. To make these lessons useful for the current project, record and exchange them after critical testing phases. The first mock (test) conversion is a great time for capturing lessons for subsequent conversions and the final go-live.

Let me describe a helpful lessons-learned game. Cover the meeting room wall with charts, each with one of the following headings:

• Conversion design
  
  
• Communication
  
  
• Planning and resources
  
  
• Execution, sequencing, and timing
  
  
• Audit and tracking
  
  
• Landscape (client management)
  
  
• Validation
  
  
• Other

Divide each chart into two blank columns, one for what worked and one for what you could improve.

Invite all key project members to the meeting. Hold separate meetings if the number is more than 10. Group everyone into teams of two. Give each team differently colored sticky notes.

The teams take 15 minutes to discuss and write down the lessons that they learned. Spend five minutes for what went well (a minimum of two items) and 10 minutes for what could improve (a minimum of four items). After 15 minutes, the facilitator collects the notes and sticks them on the wall in the correct category. Then, the facilitator leads a discussion that attempts to:

• Consolidate similar items
  
  
• Record the items in detail so that they are clearly understood
  
  
• Identify actions to take for go-live
  
  
• Assign the actions to the appropriate people

Schedule a follow-up meeting at which the facilitator distributes a lessons-learned report and updates the cutover plan.

9. Cleanse Your Data

It is worthwhile to cleanse and validate data before loading it into the new system. Switching to a new system gives users greater flexibility in viewing and using data in the system. Therefore, data that most users ignored in the old system suddenly receives prominence, as users want to accomplish more with the new system (such as access emergency contact information). Cutover is a golden opportunity to scrutinize any of the old system’s questionable data and cleanse it using the project budget.

10. Control the Scope

Consider cutover when evaluating the project’s scope. Question how much time and how many resources are available for cutover before agreeing to take on additional items, even if they seem simple and require no development or configuration.

Project teams try to include as much functionality as possible in the available project time and budget. Remain vigilant that this attitude does not de-emphasize the cutover requirements, which can add not only significant time and money to the project budget, but also significant risk. Controlling cutover scope certainly helps avoid the risk of missing the project deadline.

In some cases, you can mitigate risk by implementing basic functionality first and saving complex functionality for a follow-up project. For instance, say you want to link records of employees with two personnel numbers because you have employees on temporary loan to a branch office in another country with a separate SAP HR instance. It’s difficult to include this complex requirement for the main HR go-live. It’s more practical to establish a separate deadline for such activities, after the main project has gone live.

Here are a few additional tips to effectively manage expanding or unanticipated scope:

• Make a list of all unresolved issues and projects before cutover. Evaluate their impact and consider postponing them until after go-live.
  
  
• Include Support Packages in the cutover time frame in the planning stage. It’s quite time-consuming to apply them to all systems.
  
  
• Include time for authorization tests with real user IDs for both positive and negative situations. For example, can your time administrators enter time for themselves? Can they view sensitive data to which they should have no access?

Deepankar Maitra

Deepankar Maitra has more than 25 years of consulting experience specializing in SAP-based solutions for human resources, supply chain, and reporting in multi-national companies around the world. He has successfully directed large implementation projects as solution architect, delivery manager, global lead, and country lead. His expertise lies in pragmatic harmonization of data and synthesis of processes using tools that improve process execution through quantum leaps in productivity.

You may contact the author at deepankar.maitra@accenture.com.

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