Downtime is one of key factor in S/4HANA brownfield conversion and for large scale customers using classical conversion method downtime may not fit in desired downtime window e.g. over the weekend . Now working with many customer , I’ve seen common problem to achieve desirable downtime in planning from ECC to S/4HANA journey .
SAP has Downtime-Optimized Conversion approach which is available to customer to reduce the technical downtime requirement and i believe this approach solves downtime problem for most of the customers.
Downtime Optimized Conversion approach requires an educated experts that has taken the respective training ADM329 and successfully passed the Knowledge Assessment ADM329k
In this article, I am trying to cover important aspect for this approach Downtime-Optimized Conversion approach
- Downtime Optimized Conversion approach can be used for a system conversion from SAP ERP 6.0 to SAP S/4HANA
- It reduces the technical downtime by executing data conversion and migration (if required) in uptime
- Downtime Optimized Conversion approach is possible for source systems on SAP HANA or on non – SAP HANA database
Now lets understand quickly how does downtime-optimized conversion approach helps to reduce downtime technically:
The downtime-optimized conversion procedure partly move the data conversion to uptime, especially:
- Table conversion for FIN, MM-ML, MM-IM is moved to uptime
- Field conversion for KONV and VBFA table is moved to uptime
To understand technical details for downtime-optimized conversion, I recommend to refer :Article
General Prerequisites to use Downtime Optimized Conversion:
Kindly refer SAP note 3110934 – Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 13 for updated general prerequisites like supported target product versions , required SAP HANA database versions and different restrictions for the downtime-optimized conversion to SAP S/4HANA (always refer latest SAP Note as per used SUM tool version)
- Target product: SAP S/4HANA 1909 FPS00 (and higher stacks or releases)
- Target SAP HANA database version: SAP HANA 2.0 SP 04 rev 46 (or higher)
- If the source system is already on SAP HANA, it must be SAP HANA 2.0 SP 05 rev 52 (or higher)
- if the source system is already on SAP HANA and uses scale-out, the approach is currently not supported
- Source system: Unicode only (like for standard system conversion)
- Source system must fulfill the SAP Kernel requirements for TCR as listed in the following SAP Notes
How to use downtime-optimized conversion in SUM:
- Start the SUM procedure as usual, providing the location of the stack.xml file on the first SUM dialog
- On the second SUM dialog Scenario Strategy, select downtime-optimized, then downtime-optimized Conversion
- On the following dialog Authentication of Scenario, you have to enter a password then.
The password will be provided via incident request which specifies the assessment badge.
Now i am going to explain – Project Aspects of Downtime Optimized Conversion
- Considering the use of downtime optimized conversion for Production; it is important to ensure that DoCs are practiced multiple times in non productive landscape
- A Standard System Conversion run is required prior to production cutover; this is mainly required to gather necessary FI customizing transport(s).
- A system restart (Mini downtime) is required for consistent data set. (Ex. Over the weekend before business downtime).
- Hard freeze is required in productive environment when respective runs are scheduled (Example; Load Verification, Dress Rehearsal and Production Cutover)
- Downtime Optimized Conversion approach will require additional effort for project planning, impact analysis, and additional test runs
I’ve created high level project activity map ( example) for downtime optimized conversion project execution , Kindly modify as per project requirement and consider DEV and QAS conversion as well.
Downtime optimized conversion-DOC#1:
Standard Conversion followed by downtime optimized conversion using Finance customization ( Version 1) on latest production copy
Downtime optimized conversion-DOC#2:
Standard Conversion followed by downtime optimized conversion using Finance customization ( Version 2) on latest production copy
Downtime optimized conversion-DOC#3: Soft Freeze/Customization Freeze in place
Standard Conversion followed by downtime optimized conversion using Finance customization ( Version 3) on latest production copy
Downtime optimized conversion-DOC#4: Soft Freeze/Customization Freeze in place
Downtime optimized conversion using Finance customization ( Version 3) on latest production copy to test end to end process with previously created finance customization ( version 3)
Downtime optimized conversion-DOC#5
Production Cutover using Finance customization ( Version 3) which is already tested earlier.
After final copy of production is taken for test run on production: “Customizing-Freeze” Phase Begins: Key points to understand :
- The Customizing Freeze starts once the production system is copied to the sandbox to prepare the final Finance Customizing transport. From this point in time, the Finance Customizing must not be changed in the production landscape.
- Final FIN customizing transport needs to be available before the Dress Rehearsal , In our case it is available after completion of DOC#3 ( Finance Customization Version 3 )
- During the Preprocessing roadmap step, a short term lock of Asset Accounting is required.
- The Hard Freeze starts with additional restrictions that are listed in section Downtime and Business Restrictions and in SAP Note 3110934 Kindly .Refer Downtime Optimized Conversion guide : Section “Customizing Freeze” & “Downtime and Business Restrictions” to understand in details about these restriction so that it can be considered in planning phase itself.
Important Reference :
Kindly refer following notes and guide for Downtime Optimized conversion planning:
Kindly share feedback or thoughts in a comment or ask questions if any