Performing Manual Follow-On Activities for an SAP S/4HANA Conversion

Objective

After completing this lesson, you will be able to explain the SAP S/4HANA conversion follow-on activities.

SAP S/4HANA Conversion – Follow-On Activities

The Major Technical Steps
Realize Phase

After the Software Update Manager run has completed, several follow-on activities from the conversion guide must be considered.

Follow-On Activties

After the Software Update Manager has done the technical conversion, you can start adapting your custom code.

When you convert your system from SAP ECC running on SAP HDB to SAP S/4HANA Server, modifications to the SAP HANA database remain unchanged. However, to make your modifications visible on the UI, manual steps may need to be taken in different content layers.

SAP S/4HANA introduces a new style of output management. Note that other existing frameworks can be used as well, depending on the application.

Review your existing back-end PFCG role menus for obsolete transactions and for transaction code replacements. You can do this with the transaction SU25 report Exchange of obsolete transactions in the role menu. For more information, see SAP Note 2465353.

There are also many application-specific activities to be considered.

The Obsolete Data Handling tool allows you to delete obsolete data that may remain after the conversion of SAP ECC system to SAP S/4HANA Server.

Obsolete Data Handling Framework

Obsolete data originates from SAP S/4HANA data model simplifications in many application areas where the related application data is migrated to new data structures. These areas include Material Management, Financials, Sales and Distribution, Environment and Health Science and others. The source data isn't deleted automatically during the conversion because this would increase the business downtime and the obsolete data store may sometimes be required during or after the conversion. Therefore, after you have successfully tested and validated the conversion results, you can clean up the obsolete data with the Obsolete Data Handling tool.

Note

With SAP S/4HANA 2023, a new obsolete data handling tool is delivered. The old tool (program/transaction code ODH_Data_processing) can only be used with SAP S/4HANA 2023 to view the logs of already finished cleaning runs. It won't be available at all for future SAP S/4HANA releases. For the old tool, see SAP Note 2661837. All new obsolete data cleaning activity must be done with the new, class-based tool (transaction code SODH). For information on how to enable and use this tool in the productive SAP S/4HANA 2023 system, see SAP Note 3335020.

The deletion of data is cross-client, and the data is deleted across all clients. In SODH, you have the choice to create a Z-table as a backup option or not. In addition, you can choose whether the deletion is done in dialog or as a background job. Application logging is accessible from SODH as well: simply select button Application Log from the menu. The log object name is SODH.

The Major Technical Steps

Post-Activities for Moving to SAP S/4HANA Cloud Private Edition

Note

While this SAP Certification provides foundational knowledge, please note that a private cloud migration can be a complex process, with many teams involved, timelines, systems, processes.

We expect our PartnerEdge Sell and Service partners providing migration services to have comprehensive experience using SAP tools and to be aware of the processes involved and that is why we also highly encourage you to consume the following resources:

https://learning.sap.com/learning-journeys/administering-sap-s-4hana-cloud-private-edition-Interaction-with-sap

https://learning.sap.com/learning-journeys/getting-started-with-support-from-sap-support-accreditation

https://support.sap.com/en/product/onboarding-resource-center/rise.html

Migration partners must plan handover points to collaborate effectively with SAP, as the end-to-end migration process to SAP S/4HANA Private Cloud Edition has shared responsibilities between the migration partner and SAP. Limited access to the ECS-hosted systems necessitates raising service requests (SRs) for routine tasks, emphasizing the significance of precise planning and communication throughout the project. The technical handover relevant activities are included in the guidance of the RISE with SAP system transition workbench in the dedicated guided procedure.

Effective communication is a linchpin for success, with SAP Enterprise Cloud Services acting on received instructions, including SRs and incidents. Clear, accurate, and timely communication ensures that the migration journey follows the desired plan.

The migration process, as shown in the diagram, follows a systematic approach involving both partners and ECS.

Image depicting the migration process in ECS.

The migration partner begins the process by preparing the system. After that, the source system is ramped down. Next, the migration partner performs the transition. Once complete a handover to SAP ECS takes place where the responsibility moves from the partner to SAP. Before SAP accepts the system, they run system health checks. SAP will then change the system passwords to suit the new RISE environment and restart the system as needed. After that, SAP will continue with FRUN integration setup. Essential updates are applied to the database, operating system, and virtual network to meet quality standards. SAP ECS will then perform quality compliance checks and before finally, the system is officially handed back to the customer.

Following the handover, the customer validates the system and a go no decision is made by the project team. Once confirmed, the target system undergoes a ramp-up in RISE support.

The dry run and cutover for SAP S/4HANA Cloud Private Edition is secured by SAP as follows:

Picture illustrating the support model as described in the text below.

Within the standard SAP S/4HANA Private Cloud basic contract scope, additional test runs are provided for, and more can be added as a billable service if necessary. For migration scenarios, an extra test run for the production (PRD) system is offered. In SAP S/4HANA conversion scenarios, two dry runs are available—one for non-production (QAS, DEV, and so on) systems and another for the PRD system. If Production hardware is used for dry runs, there's no need to rebuild the target system for the final run. Partners can efficiently drop the database and continue with the migration.

While customers can perform multiple dry runs if they wish, ECS post-migration/build activities are limited according to roles and responsibilities. In the case of an SBX run, quality- or production-tier resources can be reused if no standalone SBX is included in the contract.

ECS post-processing are performed after partners completed the migration and post-system copy tasks. These tasks involve internal ECS component tasks which aren't possible for partner or customer resources to complete. It's crucial to incorporate time frames and lead times for requesting these actions via Service Requests (SR) into the migration and cutover plan.

This comprehensive support framework ensures a systematic and efficient process during dry runs and cutover in the SAP S/4HANA Cloud Private Edition environment.