I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #10 of 10 part blog series.
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed one complete cycle of system conversion on Sandbox/Development system (with CVI, SUM DMO, Custom Code Remediation, Finance Conversion, Mandatory S/4HANA features and follow-on activities) and subsequently used the transports created in that phase to complete the subsequent quality system conversions and now ready for production cutover.
First version of the cutover plan is ready after the sandbox system conversion and you continue to baseline and optimize the same throughout the project lifecycle. In the TOPIC 03, I spoke about guidance on minimum number of conversions required before project go-live and purpose of Mocks. In TOPIC 05, I spoke about options we can consider to optimize the execution time of SUM DMO. In TOPIC 07, I spoke about the options to optimize the finance conversion. These are the core activities and will consume 65%-80% of the cutover time. Remainder of the time is for TR imports (which can be optimized using Customer Transport Integration; read more about this in the SUM Guide, section 3.22), Other Migration Activities, Other Add-on upgrade and system validation / business validations before system release.
While the project phases will be run using the procedure explained in the earlier topics, if the most optimized downtime is still longer than the business approved system downtime, there are other technical options available to minimize the downtime for production cutover; 1) Advanced features of SUM Tool and 2) Services from SAP (OSS Note 693168 shares more details). If you are already on HANA you can even consider splitting the go-live over 2 maintenance windows by first doing a technical OSDB upgrade (SAP enables you to run the lower versions of application on higher version of OS DB and it may be possible to upgrade the OS/DB on the ECC application compliant with minimum requirement of target S/4HANA release) followed by the S/4HANA conversion on homogeneous landscape.
Refer to the below diagram to understand the key sub-phases of the production cut-over and also the key milestones within them. It is important to have full work breakdown structure (WBS) of all the below milestones for individual tasks, approvals required and primary & secondary ownership of the tasks (one set executes the tasks and other set validates; 4 eye principle). Do not forget to build the buffer for any unplanned failures and recovery !!!
It is recommended to automate the cut-over tasks to the extent possible to avoid people dependencies but do not over-engineer them. Equally important is to understand the possible failures (Infra Failure; Product Issues; 3rd Party Product Issues; FI Migration Execution; SPAU / SPDD unresolved Issues; Re-connection to Integrated Apps; Data Validation Issues, Security Issues; System Performance etc) and have a plan for quick troubleshooting (e.g. if a step creates application log and generates thousands of messages across different nodes, it is important to have a program that pulls all the messages from different nodes and summarizes and if possible does some troubleshooting too). This will ensure that you are spending the critical cutover time in taking remediation steps and not for data collection and analysis !!!
1) During rampdown, it is important to ensure graceful shutdown of the business users and active processes. OSS note 2050677 shares the best practices for the same. Below are a few of the program that helps you with ramp down activities:
2) De-linking and Re-linking the integrated applications too is equally critical thus must be practiced during the full dress rehearsals to ensure that you are not missing any activities on those applications.
3) You must prepare a system validation check list to ensure that all core validation steps have been completed including TR Import Logs, System Messages and Dumps, Queues, launching the most used business transactions, data validations and any other customer specific checks.
Lastly, it is important to use a digital collaboration platform (not MS Outlook and MS Excel) to manage the cutover. In my project, we used MS Teams to collaborate (RUUM from SAP is other option) and, if rightly setup, it helps you to 1) store files generated during cutover, 2) collect meeting notes, 3) share task start/completion notifications and 4) get into a meeting bridge accessible to all the project team members and 5) track milestones with MS Planner. Thus helps in managing the cutover in a much more transparent way and ensures that the Cutover Manager is on top of everything happening !!!
This concludes the S/4HANA conversion project that helps you modernize your ECC Platform aligned with today's enterprise architecture.
Based on the knowledge you gained on the project you should be able to:
This concludes the blog series. Thanks for being with me while I shared my journey !!!
Wish you a Happy S/4HANA Move 🙂
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed one complete cycle of system conversion on Sandbox/Development system (with CVI, SUM DMO, Custom Code Remediation, Finance Conversion, Mandatory S/4HANA features and follow-on activities) and subsequently used the transports created in that phase to complete the subsequent quality system conversions and now ready for production cutover.
First version of the cutover plan is ready after the sandbox system conversion and you continue to baseline and optimize the same throughout the project lifecycle. In the TOPIC 03, I spoke about guidance on minimum number of conversions required before project go-live and purpose of Mocks. In TOPIC 05, I spoke about options we can consider to optimize the execution time of SUM DMO. In TOPIC 07, I spoke about the options to optimize the finance conversion. These are the core activities and will consume 65%-80% of the cutover time. Remainder of the time is for TR imports (which can be optimized using Customer Transport Integration; read more about this in the SUM Guide, section 3.22), Other Migration Activities, Other Add-on upgrade and system validation / business validations before system release.
While the project phases will be run using the procedure explained in the earlier topics, if the most optimized downtime is still longer than the business approved system downtime, there are other technical options available to minimize the downtime for production cutover; 1) Advanced features of SUM Tool and 2) Services from SAP (OSS Note 693168 shares more details). If you are already on HANA you can even consider splitting the go-live over 2 maintenance windows by first doing a technical OSDB upgrade (SAP enables you to run the lower versions of application on higher version of OS DB and it may be possible to upgrade the OS/DB on the ECC application compliant with minimum requirement of target S/4HANA release) followed by the S/4HANA conversion on homogeneous landscape.
Refer to the below diagram to understand the key sub-phases of the production cut-over and also the key milestones within them. It is important to have full work breakdown structure (WBS) of all the below milestones for individual tasks, approvals required and primary & secondary ownership of the tasks (one set executes the tasks and other set validates; 4 eye principle). Do not forget to build the buffer for any unplanned failures and recovery !!!
It is recommended to automate the cut-over tasks to the extent possible to avoid people dependencies but do not over-engineer them. Equally important is to understand the possible failures (Infra Failure; Product Issues; 3rd Party Product Issues; FI Migration Execution; SPAU / SPDD unresolved Issues; Re-connection to Integrated Apps; Data Validation Issues, Security Issues; System Performance etc) and have a plan for quick troubleshooting (e.g. if a step creates application log and generates thousands of messages across different nodes, it is important to have a program that pulls all the messages from different nodes and summarizes and if possible does some troubleshooting too). This will ensure that you are spending the critical cutover time in taking remediation steps and not for data collection and analysis !!!
Figure 1 : Key sub-phases of cut-over and key milestones
1) During rampdown, it is important to ensure graceful shutdown of the business users and active processes. OSS note 2050677 shares the best practices for the same. Below are a few of the program that helps you with ramp down activities:
- RLFW_SD_PROCESS_QUEUES Empty queues
- RLFW_SD_SUSPEND_BATCH_JOBS Suspend batch jobs (BTCTRNS2 to release)
- RLFW_SD_NOTIFY_USERS Notify end users to log off
- RLFW_SD_DISABLE_LOGON Restrict logon to selected users
- RLFW_SD_LOGOFF_USERS Log off all users
- RLFW_SD_FINALIZE_QUEUES Finalize queues
- SM01 Lock TCodes
2) De-linking and Re-linking the integrated applications too is equally critical thus must be practiced during the full dress rehearsals to ensure that you are not missing any activities on those applications.
3) You must prepare a system validation check list to ensure that all core validation steps have been completed including TR Import Logs, System Messages and Dumps, Queues, launching the most used business transactions, data validations and any other customer specific checks.
Lastly, it is important to use a digital collaboration platform (not MS Outlook and MS Excel) to manage the cutover. In my project, we used MS Teams to collaborate (RUUM from SAP is other option) and, if rightly setup, it helps you to 1) store files generated during cutover, 2) collect meeting notes, 3) share task start/completion notifications and 4) get into a meeting bridge accessible to all the project team members and 5) track milestones with MS Planner. Thus helps in managing the cutover in a much more transparent way and ensures that the Cutover Manager is on top of everything happening !!!
This concludes the S/4HANA conversion project that helps you modernize your ECC Platform aligned with today's enterprise architecture.
The S/4HANA journey does not stop here but it starts here.
Based on the knowledge you gained on the project you should be able to:
- Identify the innovations that you can consume with little effort and no change management.
- Identify the innovations that can be taken up as projects (green spots !!!). You can use the SAP Business Scenario Recommendation Report or Pathfinder Report or What's New Viewer to get started on this.
- Prepare the FIORI adoption plan to adopt apps in phased manner by Processes, Regions and Users. Do plan on enabling the IT team on FIORI troubleshooting to ensure that their inability to support FIORI or wrong sizing of FIORI server is not the reason for business to not adopt FIORI.
- Have your development team transition to use Eclipse IDE including new development paradigms of S/4HANA. Eclipse has a very different look n feel compared to SE80 so you will feel it is slowing you down in the beginning but after 2 weeks of continued usage you will see it actually increases your productivity. Trust me, its worth the effort !!!
- During Migration, majority of the ECC transactional data is retained as backup tables so it consumes database space. After you have sufficiently validated the system for maybe 6 months, you must plan to move that data from Hot Store to Cold Store (Read more in OSS Note 2661837).
- Plan for table partitions where a table will have more than 2 billion records to avoid HANA DB bottlenecks.
This concludes the blog series. Thanks for being with me while I shared my journey !!!
Wish you a Happy S/4HANA Move 🙂
- SAP Managed Tags:
4 Comments
