How does SAP NZDT work?
Introduction
If you are planning a system conversion for your SAP ERP 6.0 system to SAP S/4HANA 1809 or higher, either on-premise or move to a hyperscaler, there are several options available regarding downtime optimization. The demand for business continuity in today’s business has challenge IT professionals to perform system upgrades with the least amount of downtime as possible. SAP NZDT (Near Zero Downtime Technology) is a service in which can help you achieve your next conversion downtime requirements.
I was fortunate to work with the NZDT team on a project recently of which a global customer went live using SAP NZDT service for a conversion of SAP S/4HANA 1809 to AWS. Due to the size of their database (~25 TB) and strict requirements for downtime, the standard SUM approach was not possible. SAP NZDT service team provided expertise with the setup of infrastructure and delta replay technology and each cycle conversion while the customer and SAP partner completed the SUM and Finance conversion. The project went live successfully, and I want to share with you the final results.
Please note, at the time of the Blog Post, there are three possible downtime approaches for a conversion to SAP S/4HANA using SUM. Currently, only SUM Standard approach and NZDT are available while Downtime-Optimized Conversion is in the Pilot phase. Please see the following Notes which are available for each methodology and further requirements.
Quick Review:
From the slide, the downtime duration decreases as you move to the right however, there will be more complexities.
Here are some key high-level steps from the diagram below: After the prep and data recording started, a system clone is created in step (3). SUM/DMO is executed on the clone system (5) while data is recorded continuously on the on the original system. Business is a usual for the end users. As we get closer to business downtime, the target system is already on S/4HANA. Delta Replay (10,11,12) are required on the target S/4HANA system (converted system) in order to catch up on all of the changes as the clone copy of the database was created at an earlier date and time. During downtime, (14) the final Delta Migration occurs, which is significantly less time compared to step (7). During steps (17 and 18) any post work that needs to be done are now independent of NZDT.
Hardware & Technical Requirements Example:
How much downtime was actually achieved by using NZDT for a conversion?
A word of caution, these results will vary between each customer environment due to the size of the database, complexity of their environment and network bandwidth between data centers. This is only for the purpose of reference.
Key Uptime Activities on Clone ~ 23 Days prior to cutover
Key Downtime Activities Timing Results:
Key Tables
Total DB size: SAP HANA DB = 6TB
Analysis:
The technical downtime using NZDT was about 8.5 hours while the Business Downtime was roughly 39 hours. As mentioned earlier, NZDT will help lower the Business downtime by reducing the technical timing. Post activities which also influence Business Downtime are based on system validation, testing and Basis related technical work. It should be noted that the involvement of both the technical and functional team are critical as you perform multiple cycles leading up to cutover weekend. Since the clone did most of the heavy lifting during uptime, only the delta processing occurred during the cutover weekend. This cutover was completed over the weekend with the business online on Monday morning.
Summary
This blog post describes the high-level overview and results of a conversion project using SAP NZDT as a methodology to reduce downtime of an SAP S/4HANA 1809 conversion. The challenges of performing such a huge upgrade/conversion along with a data center move to AWS requires both SAP expertise and strong project planning leadership on the customer and everyone involved. The go live was a success based on everyone’s hard work and dedication to achieve downtime.
I would like to thank Rajendran (Raj) Srinivasan for sharing the NZDT results. Raj and the NZDT team did an awesome job in this conversion project. They are rockstars!
SAP RIG
Some helpful links:
DISCLAIMER: This blog post reflects the current state of planning which may be changed by SAP at any time.
If you are planning a system conversion for your SAP ERP 6.0 system to SAP S/4HANA 1809 or higher, either on-premise or move to a hyperscaler, there are several options available regarding downtime optimization. The demand for business continuity in today’s business has challenge IT professionals to perform system upgrades with the least amount of downtime as possible. SAP NZDT (Near Zero Downtime Technology) is a service in which can help you achieve your next conversion downtime requirements.
I was fortunate to work with the NZDT team on a project recently of which a global customer went live using SAP NZDT service for a conversion of SAP S/4HANA 1809 to AWS. Due to the size of their database (~25 TB) and strict requirements for downtime, the standard SUM approach was not possible. SAP NZDT service team provided expertise with the setup of infrastructure and delta replay technology and each cycle conversion while the customer and SAP partner completed the SUM and Finance conversion. The project went live successfully, and I want to share with you the final results.
Please note, at the time of the Blog Post, there are three possible downtime approaches for a conversion to SAP S/4HANA using SUM. Currently, only SUM Standard approach and NZDT are available while Downtime-Optimized Conversion is in the Pilot phase. Please see the following Notes which are available for each methodology and further requirements.
Quick Review:
From the slide, the downtime duration decreases as you move to the right however, there will be more complexities.
- Standard approach – This is generally available from the SUM tool. SUM long steps such as data migration, software update, XPRAS_AIMMRG / FI Conversion are running in the technical downtime phase
- Downtime-Optimized (Pilot Inplace Only) Compared to the standard approach, reduce the technical downtime is achieved by partially moving Data Conversion and migration during the uptime of SUM, thus reducing the overall downtime Delta replay occurs for any uptime changes. Please see Note 2293733 and Note 2547309 for further information.
- SAP NZDT – Service by SAP MDS (Minimize Downtime Service) team. SUM steps are handled in uptime on a cloned NZDT reduce the overall business downtime by reducing the technical downtime by using a dedicated HW for the clone system, triggers installation of the source, DMIS add-on installations, and delta replay of data processing. Please note that all post processing steps such as reconciliation and validation cannot be optimized by downtime optimization approaches.
Here are some key high-level steps from the diagram below: After the prep and data recording started, a system clone is created in step (3). SUM/DMO is executed on the clone system (5) while data is recorded continuously on the on the original system. Business is a usual for the end users. As we get closer to business downtime, the target system is already on S/4HANA. Delta Replay (10,11,12) are required on the target S/4HANA system (converted system) in order to catch up on all of the changes as the clone copy of the database was created at an earlier date and time. During downtime, (14) the final Delta Migration occurs, which is significantly less time compared to step (7). During steps (17 and 18) any post work that needs to be done are now independent of NZDT.
Hardware & Technical Requirements Example:
- ~200GB Additional DB Space for Logging Tables, DMIS SP15, NZDT Notes, Users and Authorizations
- Clone Server with 50-60% compute and 100% DB Size of PRD
- MWB (migration workbench) Server, APP, and DB (64GB RAM, 16 core CPU, 500GB DB Storage) DBCO Connections to Source, Clone and Target
- App Server for DMO run at source (128GB RAM, 32 Core CPU, 2.5 TB Storage)
- Network Bandwidth between Data Center and AWS (5Gbps to 10Gbps)
- MCOD Deployment. After data replay, Proxy schema would be deleted
- App Server for DMO run at target (128GB RAM, 32 Core CPU, 2.5 TB Storage)
How much downtime was actually achieved by using NZDT for a conversion?
A word of caution, these results will vary between each customer environment due to the size of the database, complexity of their environment and network bandwidth between data centers. This is only for the purpose of reference.
Key Uptime Activities on Clone ~ 23 Days prior to cutover
| Steps | Time Total (Days) | Tasks |
| SUM | 7 Days | Upgrade, migration to SAP S/4HANA 1809 AWS |
| Initial Finance Conversion | 1 Day | Finance Conversion on SAP S/4HANA 1809 on AWS of |
| Delta Replays | 8 Days | 3 - Online Delta Replays as we get close to cutover |
Key Downtime Activities Timing Results:
| Steps | Time Total (Hours) | Tasks |
| NZDT Downtime Final Delta Replay | 6.0 | Final Delta Replay Offline |
| Finance Delta Conversion | 2.5 | Finance Conversion of delta data |
| Technical and Post processing Activities | ~30 (completed in parallel during downtime) | Basis tasks, Backup, Transports, Network changes, Ramp up, unlock users, Finance posting, etc |
Key Tables
- ACDOCA = ~ 1.3 Billion records
- MATDOC = 120 Million records
Total DB size: SAP HANA DB = 6TB
Analysis:
The technical downtime using NZDT was about 8.5 hours while the Business Downtime was roughly 39 hours. As mentioned earlier, NZDT will help lower the Business downtime by reducing the technical timing. Post activities which also influence Business Downtime are based on system validation, testing and Basis related technical work. It should be noted that the involvement of both the technical and functional team are critical as you perform multiple cycles leading up to cutover weekend. Since the clone did most of the heavy lifting during uptime, only the delta processing occurred during the cutover weekend. This cutover was completed over the weekend with the business online on Monday morning.
Summary
This blog post describes the high-level overview and results of a conversion project using SAP NZDT as a methodology to reduce downtime of an SAP S/4HANA 1809 conversion. The challenges of performing such a huge upgrade/conversion along with a data center move to AWS requires both SAP expertise and strong project planning leadership on the customer and everyone involved. The go live was a success based on everyone’s hard work and dedication to achieve downtime.
I would like to thank Rajendran (Raj) Srinivasan for sharing the NZDT results. Raj and the NZDT team did an awesome job in this conversion project. They are rockstars!
SAP RIG
Some helpful links:
- Note 693168 as starting point for your NZDT journey
- Note 2620180 - NZDT - Composite SAP Note - DMIS 2011
- DMO optimization: see blog in SAP Community: https://blogs.sap.com/?p=135725
- SAP Note 2351294 – SAP S/4HANA System Conversion / Upgrade: Measures to reduce technical downtime
- SAP Note 2553722 – Performance optimization of XPRA RMXPRAS4SIMIGRATION
- SAP Note 1616401 – Parallelism in the Upgrades, EhPs and Support Packages implementations
- SAP Note 2353814 – SAP S/4HANA conversion reports in SD: optimize parallel execution of conversion reports
- SAP Note 2355049 – Parameters for conversion report MFLE_XPRA_PARALLEL_CALL
DISCLAIMER: This blog post reflects the current state of planning which may be changed by SAP at any time.
- SAP Managed Tags:
5 Comments
