Downtime Minimization in SAP S/4HANA Conversion Projects!
Every one of us knows “the cost and impact of system downtime.” Large organizations looking for a ZERO downtime approach for moving to SAP S/4HANA or for upgrading their existing SAP S/4HANA systems can’t do this. Downtime reduction plan or Downtime strategy is most important for upgrades and Conversion projects, and minimum downtime will lead to maximum benefits for the organizations. Downtime optimized conversion aims to drastically reduce the downtime of Conversion projects. The new Zero downtime approach allows users to minimize downtime for S/4HANA Conversions. The SAP Readiness check for SAP S/4HANA will show planned downtime calculator (in versions). This helps in calculating downtime for a conversion project.
This approach is a service offering by SAP. It is not a tool that can be used by partners or customers directly. It is a very new concept and needs expertise from SAP – and certainly helps to reduce downtime. The conversion activities are performed on a clone system, while existing productions system will continue to work. Users can post their transactions in the existing PRD system. Database triggers record the user changes, which will be replayed to the clone system. Finally, a system switch from existing PRODUCTION system to CLONE requires a very short downtime, and CLONE becomes your new PRD system
We have Three different options and approaches:
1. Standard approach
2. Near ZERO Downtime Technology (Refer SAP Note 693168)
3. Downtime Optimized Conversion
SAP offers tools to evaluate the approach appropriate for you. At the end of the SUM run, you are asked to provide feedback to SAP. The feedback includes the statistical data run on the SUM run. We can also create manually by report FINS_MIG_APPLANA_XML or in Transaction FINS_MIG_STATUS via Goto >> Statistics
There are several definitions on Downtime. Business Downtime is the duration in which users cannot post any business Transactions in the Production system.
It is needed when customers are adapting, extending or modifying software. During this process there is a potential risk of data inconsistency so it may need a downtime.
What are the influencing factors of downtime?
Runtime: Runtime is total duration of SUM including preparation and Uptime activities.
Runtime and downtimes are dependent on several factors and I would like to provide some examples here:
1. Hardware and OS
2. Hard disk Configuration
3. Database size of tables and database configuration, parameters tuning
4. Number of modifications
5. Number of data structures to be converted
6. Number of clients
Can I perform S/4HANA Conversion in one step?
Yes, but it takes longer downtime than the two step approach. If the start release is SAP_BASIS740 or more, we can split SAP S/4HANA Conversion in to two Projects:
1. Database migration to SAP HDB
2. Perform S/4HANA Conversion without DMO
When you want to minimize the technical downtime while converting your SAP ERP system to SAP S/4HANA, or while upgrading within SAP S/4HANA, you may refer to SAP note 2351294
Near ZERO Downtime Technology (Refer SAP Note 693168)
Refer to SAP Note 2309893 – Near Zero Downtime method for migration to S/4HANA and S/4HANA Finance. For general information, refer to SAP note 693168 – Minimized Downtime Service (MDS).
The Near Zero Downtime (NZDT) approach allows us to minimize downtime for an S/4 conversion. It is a project-based solution using DMIS add-on from SAP. It requires consulting support.
An overview of the steps allows us to minimize the downtime for migration:
1. Create a clone of the productive system.
2. Perform migration on the clone system.
3. Re-sync migrated the clone with the productive system. The clone system becomes the new productive system.
The sequence of steps for migration to SAP S/4HANA include the following:
• Recording over DB-Triggers.
• System Cloning and Isolation.
• Upgrade and Installation of SAP S/4HANA.
• Initial SAP S/4HANA Migration and Validation.
• Online delta replay (across releases).
• Offline Delta Replay
• SAP S/4HANA Migration of Delta
• Last Transports
• Infrastructure Change / System Switch
• Final Validation
Considerations for the Project Set-Up
1. NZDT basis activities such as triggering the activation and the delta replay, have to be performed by NZDT-certified experts from SAP Consulting as part of the Minimized Downtime Service.
2. NZDT functional activities such as Finance-specific Customizing, initial and delta migration can be performed by SAP or by partners.
How to Prepare Source System
To prepare source system for the conversion and subsequent data migration, perform the following steps:
1. Carry out the necessary period-end closing activities. The following are some of the relevant activities:
Carry out the depreciation run: Program : RAPOST2000, transaction AFAB closed without errors.
2. Run the periodic asset postings: ASKB or RAPERB2000 without errors.
If you were using classic Asset Accounting under ERP 6.0, reconcile the general ledger with classic Asset Accounting (report RAABST01, transaction ABST) and correct any reconciliation differences that occur.
If you were using new Asset Accounting under ERP 6.0, then you need to reconcile the general ledger with new Asset Accounting (report FAA_GL_RECON, transaction ABST/ABSTL) and correct any reconciliation differences that occur.
1. Execute the asset history sheet.
2. Create the logging tables (for example, one day before you create the clone system).
3. Lock Asset Accounting for postings on the day you want to create the clone system, and as such start the delta period.
4. Calculate the plan values for depreciation (transaction AFAR) (this means you can avoid RC errors during the migration).
5. Check that there are no update terminations.
6. Only if you are migrating to a release lower than SAP S/4HANA 1809, run the latest version of report RASFIN_MIGR_PRECHECK (SAP Note 1939592) without errors.
7. Activate the trigger and start recording the data.
8. Create the clone system.
Please note that the dataset of the clone system must be earlier than the time stamp of the latest activated trigger in the live system. Switch on Asset Accounting for postings.
Convert Clone System
Carry out the following activities in the clone system – in parallel to the running productive system
1. Isolate the clone system.
2. Perform the upgrade and installation.
Then continue with the initial migration.
Migrate Customizing Settings & Transactional Data
Perform activities of Customizing settings and data into the clone.
First execute preparation step.
Second data migration activity. Start and Monitor for Data Migration. Before you start to monitor, make sure all the above steps are finished correctly and without errors.
• Users can continue to post their productive transactions in PRD system while Customizing and data migration is running on this clone in the uptime.
• After you have completed and checked this initial data migration, the clone is ready to receive the delta recorded in your productive system.
• To perform the subsequent delta migration, a downtime is necessary in the productive system.
• Perform the online delta replay of the recorded data.
• Carry out the ramp down in the productive system and lock all users to start the downtime.
After completing delta migration, we need to migrate Trade Finance and Credit Management data
1. Install SAP notes 2538162 & 2556223
2. Program: FINS_NZD_MIG_DELTA2_PREPARE with the Setup option. Perform an initial migration and the first delta migration.
3. Transaction Code: FINS_MIG_STATUS will show the X value for Finished for the delta migration run.
4. Execute report FINS_NZD_MIG_DELTA2_PREPARE with the Backup and delete SLT logs option.
5. Provide the delta data of the second run in the SLT logging tables.
6. Start a second delta migration run using transaction FINS_MIG_STATUS, choosing the Prepare migration and Start migration options.
Below are the some of the constraints:
Do you have Actual Costing in your source system?
If yes, complete all material ledger costing runs of actual costing runs in the source system This means that the “Post Closing” step is to have been executed successfully for all materials and activity types in all material ledger costing runs
• Do not post in closed periods
• Do not perform Balance C/F
• Do not perform any customizing changes
Downtime Optimized Conversion Run
To enable the downtime-optimized conversion approach, in the SUM UI, the main dialog is selection of the scenario strategy.
Authentication of Downtime-Optimized Approach
This approach requires some additional qualifications, for example the consultant must have qualified in ADM329 and should have a Knowledge Badge. This Badge needs to be accepted and made Public.
The downtime for a software upgrade to SAP S/4HANA and migration can be minimized by the Near Zero Downtime approach. The process takes some additional time for the conversion project. We can continue to post in the productive system while an upgrade and the initial data migration is running on a clone. Once the initial data migration has been completed and checked, a short downtime is necessary in the productive system in order to migrate the rest of the data and complete the upgrade. This approach helps S/4HANA conversions for customers with exceptionally time critical conversion projects.
About the Author:
Dr. Ravi Surya Subrahmanyam is a technical and Financials writer with a background in SAP Financial Accounting, Funds Management, Group Reporting, Financial Supply Chain Management, Cash Management & in-house cash, SAP S/4 HANA Finance. He has been working as a Senior Director for the SAP Practice for The Hackett group India Ltd, (Answerthink Company). He completed Master’s degree in Finance from Central University, Master of Commerce from Osmania University, Master of Commerce from Andhra University, and Ph.D.in Finance from one of the best universities in India. His research Papers have been published in National and International magazines. He has been a Visiting Instructor for SAP India Education and SAP Indonesia – Education. He has been working on Conversion and Upgradation projects. He is a Certified Solution Architect for SAP S/4 HANA and an SAP S/4 HANA Certified Professional. He can be reached at firstname.lastname@example.org or email@example.com