Conversion Guide: SAP ECC to SAP S/4HANA

SAP S/4HANA (stands for SAP Suite for SAP HANA DB) transformation includes a migration from an old?SAP ERP system (ERP is simply a general term that stands for Enterprise Resource Planning), such as SAP ECC (ECC is the name given to SAP's ERP software bundle and stands for SAP ERP Central Component) to SAP's simplified 4th-generation?SAP S/4HANA business suite (SAP S/4HANA is the latest ERP system from SAP's ERP software product line and was launched as the fourth product generation in 2015).

Exploring Deployment Options:

1. S/4HANA on-premise

In this common model, the customer acquires a license and installs the software in their own data center. SAP S/4HANA on-premise represents the traditional ERP implementation approach, empowering customers with complete control over system customization and maintenance. SAP announced a maintenance availability commitment for SAP S/4HANA until 2040, guaranteeing a long-term support strategy for the next generation of SAP software. However, SAP also announced they will be focusing innovation on S/4HANA Cloud only. So, while S/4HANA on-premise will still have support until 2040, it won’t have significant new functionality.

2. S/4HANA Cloud, public or private edition

In this model, the customer rents the software for a certain period of time. SAP deploys the software in the SAP owned data center. Public cloud software typically runs in a multi-tenant server, where multiple tenants, or customers share the resources of the server. This is similar to an apartment building where multiple tenants live within the same physical infrastructure and share certain resources, but each tenant has their own key to a secure unit within the building.

Maintenance of the building and apartment units is factored into the rent paid by tenants and taken care of when tenants need it. In public cloud, each customer's data and applications are hidden from the other customers, but because they are sharing certain resources and maintenance of the solution is taken care of by the cloud provider, public cloud is often the most affordable and efficient solution. Private cloud software typically runs in a single tenant server, where only a single tenant (customer) uses the resources of the server. Software runs in a private network protected by a firewall, similar to an on premise system. The main differences between private cloud and on premise is who has responsibility for maintaining the server, and the license for the software installed on the server.

For on-premise, a customer purchases the server and is responsible for maintenance. For private cloud, a third party provider owns the server and is responsible for maintenance. A customer pays a subscription fee to access the server over the internet and install software. In some cases, one cloud provider maintains the server, and another provider maintains the software installed on the server.

For example, with SAP S/4HANA Cloud, private edition, SAP is responsible for maintaining the business software, but the customer can choose to have their software on a server in an SAP data center, or a server in a data center from one of our hyperscaler partners. In this case, the hyperscaler partner is responsible for maintaining the server.

?3. Hybrid

In this model, required applications are operated partially by the customer and partially by SAP in the Cloud. Both parts can be linked and integrated with each other

Let’s talk a bit about SAP RISE

What exactly is RISE with SAP?

Think of SAP RISE as a fully managed SAP hosting service on the large public Cloud hyperscalers – AWS, Azure, GCP etc. RISE with SAP program is not a single software, but a whole kit of applications, tools, and managed services that help SAP customers transit successfully to Cloud. At the core of the RISE with SAP offering is an AI-based Cloud ERP (SAP S/4 HANA Cloud) that is managed and maintained by SAP. It includes tools and services based on SAP’s clean core approach, making it simple to innovate, and migrate on-premise systems to the Cloud.

The unique thing about RISE with SAP is that it provides customers Business Transformation as a Service (BTaaS) under a single contract. Elements include software applications, Infrastructure as a Service (IaaS), and Cloud Managed Services (CMS). SAP RISE is subscription-based, centered around SAP S/4HANA and integrates SAP tools, technologies, and business intelligence into a single, unified package, designed to accelerate and streamline your organization’s transformation into a Cloud-driven enterprise. You can select from Certified SAP partners to help customize an SAP RISE solution for your business (https://partnerfinder.sap.com/ , IBM, Accenture, Capgemini, Cognizant, Deloitte, EY, HCL Technologies, Infosys, NTT, Tata Consultancy Services, and Wipro Limited).

RISE with SAP also offers credits for the SAP Business Technology Platform (SAP BTP) with which you can build business applications, integrate and extend them, aggregating technologies like data and database management, application development and integration, analytics, and intelligent technologies like IoT (Internet of Things), RPA (Robotic Process Automation), conversational AI (Artificial Intelligence) and AI business services. SAP BTP consumption credits are included in the RISE with SAP package and are based on the Cloud Platform Enterprise Agreement (CPEA).

Included in the single “RISE with SAP” contract are software and support, Infrastructure, administration, and managed technical services. But consulting and implementation services along with application management services are not included.

?*From SAP Basis perspective: SAP will control the OS, DB, and even client 000 on your system. You will only get access to HANA or client 000 if you put in a ticket and request access, but the accounts they give you are not 'sap_all'. SAP will handle any patches or upgrades for you. If they run into issues, they may (will) revert the ticket to you for a solution. You will have to plan and schedule everything using SAP's portal. They also handle the backups, and system refreshes (after you've prepped the system for them). SAP will NOT perform: TMS transports, RFCs, SAP cloud config, user security, client settings (outside of 000), application monitoring, etc. are still on the internal team. Also, SAP does not work independently. You can't just put in a ticket that says 'update my system to the latest kernel and application levels'. There are multiple tickets, and you will be responsible for telling them EXACTLY what you want.

Cloud software is delivered "as-a-Service", where a consumer of the service is billed on a subscription basis for what they use. The subscription-based digital model is highly flexible and agile because you can easily scale up or down as needed.

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)

The following graphic explains and differentiates On-Premise, IaaS, PaaS and SaaS:

Two-Tier ERP Deployment

A two-tier ERP strategy is when a company implements different ERP systems for separate parts of the business. By combining two different deployments of SAP S/4HANA, a business can take advantage of the fast innovation in public cloud, while still allowing for a high degree of customization for strategic processes in the private cloud or on premise.

Scenario 1: Headquarter & Subsidiary model

Headquarters runs a highly customizable on premise or private cloud ERP and subsidiary runs a standardized public cloud ERP with a specific scope.

Scenario 2: Central Services model

Organization has a line of business spin-off running a standardized public cloud ERP- For example, Finance would be a separate legal entity and run in the public cloud as "Shared Services", with the rest of the business running on a highly customizable on premise or private cloud ERP

Scenario 3: Ecosystem model

Headquarters runs a highly customizable on premise or private cloud ERP and brings their subcontractor(s) or dealer(s) on a standardized public cloud ERP.

You cannot install SAP S/4HANA - it is only the product name. You can install one of the SAP systems inside, for example SAP BW, SAP Front End Server or SAP S/4HANA Server.

SAP S/4HANA Server is the name of the SAP system and SAP S/4HANA is the name of the suite.

Key drivers enabling the transformation are:

1. SAP is ending support for ECC in 2027 for customers buying standard support, or until 2030 for customers that purchase extended support contracts. So, it’s not a matter of “if” customers have to migrate, but “when.”
2. Not meeting SAP’s deadlines will limit your ability to execute digital transformation and put your company—no matter your industry—at a competitive disadvantage.
3. The need to harmonize IT and your legacy ERP system into future-proof solutions.
4. Foundation of SAP S/4HANA and its new technical architecture that embeds automation and system intelligence to help with business practices across the entire platform.
5. It offers end users active, real-time decision support that’s data-driven, taking into consideration internal and external data sources. That means businesses processes that took minutes to complete will now take seconds.
6. ERP migration brings a lot of positive changes, including a better user experience, improved performance, and reduced total cost of ownership.

The migration to a new ERP system is not a typical IT project, but rather a fundamental system change, the implementation is associated with some challenges.

Biggest transformation hurdles:

• Existing complex IT landscapes
• Unclean master data
• Company-specific ABAP code that is not compatible with S4Hana
• Creating inconsistent business processes that need to be harmonized before migration.
• Change management lacks the necessary expertise to develop the right strategy
• Slow or blocked migration process due to individual stakeholders

Let’s talk a bit about the costs to perform the conversion of ECC to S/4HANA

S/4HANA On-Premise (Contract Conversion)

Customers can undergo an S/4HANA Contract Conversion by terminating their entire existing contract and replacing it with new S/4HANA licenses and terms & conditions. A contract conversion allows customers to continue using Business Suite/ECC Software until the completion of their S/4HANA transition, along with their new S/4HANA licenses. This can be beneficial to customers as it allows the opportunity to repurpose unused software. When terminating the current agreement, SAP customers are also eligible for a credit of the value of their existing software.

Example 2023 Credit Conversion Calculation

A customer has a maintenance base of $1,000,000 on Business Suite/ECC Software.

The new S/4HANA contract has a value of $1,200,000.

They will receive a credit of up to 80% of the $1,200,000 = $960,000.

The credit of $960,000 is applied towards the purchase of the SAP S/4HANA on-premise software, which means the customer only pays the remaining $240,000.

As a general rule, S/4HANA software tends to be 10% more expensive and SAP does not allow for the reduction of the maintenance base. This means customers should be prepared to see a minimum increase of 10% to their maintenance base with no provision to reduce it and also be prepared to pay at least 20% of the new contract up-front.

After the 2027 deadline, SAP will switch off its support for ECC. SAP extended support (from 2028 to the end of 2030) will come at a premium of 2% of the existing maintenance. While the 2% premium is not huge, it will begin to add up and detract from investments in other areas. Customers not wishing to extend their maintenance support will be moved to a customer-specific maintenance model.

Overall, S/4HANA on-premise provides control and customization for customer’s ERP systems, backed by a commitment to support until 2040. SAP customers should be aware of diminishing credit opportunities and lack of new functionality over the coming years if they choose to migrate to S/4HANA on-premise. Note that customers who migrate to S/4HANA on-premise still have the option to later migrate to S/4HANA Cloud.

Three approaches to S/4HANA transformation

?

1. Greenfield approach - new implementation

If a company decides to adopt the Greenfield approach, it abandons its existing ERP system. This has the advantage that a new, uniform system can be implemented that only contains the processes and data that are actually necessary.

If a company completely redefines its enterprise architecture, innovations can also be integrated more easily and a high level of functionality can be achieved. In the study mentioned above, only 14 percent of all respondents chose this approach because it involves more effort.

However, when switching to the SAP S/4HANA cloud version, the Greenfield approach is unavoidable as the systems are completely replaced.

2. Brownfield approach - system conversion

With the Brownfield approach, a system conversion takes place. This means that existing business processes are taken over and optimized if necessary.

Since most companies do not want to completely abandon their custom ERP system, the Brownfield approach is the most popular migration path. According to the study, 44% of respondents choose this strategy, while 42% opt for a combined Greenfield and Brownfield variant.

To ensure a smooth transition, EA tools are used to divide the conversion into clear phases. The tools also ensure that old processes are rethought so that redundancies and complexity are not adopted. The advantage over the Greenfield approach is that the project time for system conversion is reduced.

3. Hybrid approach - selective data transition

Strictly speaking, the hybrid approach and its landscape transformation is not an independent transformation strategy. It is simply a method that large companies with complex system landscapes can use to prepare for transformation. In practice, this means that databases are cleaned up and consolidated to reduce the Footprint before the change.

Companies can also use this approach to combine several ERP systems from different vendors. Such a simplification is also possible during the actual transformation. Whether this makes sense depends on the system landscape and the target system. In many cases, an enterprise architect works with all three approaches to achieve the best possible approach.

We will focus on point 2 - Brownfield approach - system conversion

Prepare Phase:

There are various conditions that must be met before beginning a?SAP?ECC to S/4HANA conversion. You need to gain an idea of the project steps and necessary preparations.

Use the following tools to do your project planning:

1. Roadmap Viewer to familiarize yourself with the project steps required for the transition to SAP S/4HANA.

For more information, see https://me.sap.com/roadmapviewer

1.1 ASU Toolbox Application Conversion Assistant The ASU Toolbox focuses on the application view, and is therefore a complement to the more technically oriented conversion tool. It's content is regularly updated and is intended to help you achieve the conversion as efficiently as possible. For information about the tool, see SAP Note 3008338 .

2. SAP Readiness Check for SAP S/4HANA

SAP Readiness Check is mainly a planning tool which you run early in a system conversion project to get an overview about the required activities – including tasks related to simplification items. It is also useful for tracking these activities during the project

It is highly recommend to run the SAP Readiness Check for SAP S/4HANA in advance of your conversion project to identify any issues you need to consider and activities you need to do in preparation for your project.

For more information about how to use the SAP Readiness Check for SAP S/4HANA, see https://help.sap.com/viewer/p/SAP_READINESS_CHECK

3) System Requirements

You need to be aware of system requirements, start releases, conversion paths, and data volume

SAP Version:

At least SAP ERP ECC 6.0 and not something older

The DMO(Database Migration Option) of SUM (Software Update Manager) requires ERP 6.0 EHP6 and MS SQL Server to be MS SQL 2008 R2 (that in Widows Server 2008 R2) or higher if we aim for HANA database with SAP_BASIS 751 or higher.

In PAM (Product Availability Matrix) we will see that for SAP S/4HANA conversion we will need at least Windows 2016 as a minimum requirement and for SAP HANA 2.0 we will need Linux SLES|RHEL

Single/Dual stack:

Your system has to be an AS ABAP-only system. Dual-stack systems (AS ABAP and AS Java combined in one system) are not supported for the conversion. If your system is as dual stack system, you have to split it before doing the conversion

Guide at https://support.sap.com/sltoolset -> System Provisioning -> System Provisioning Scenarios -> Split a System using Software Provisioning Manager 1.0 -> ?Dual Stack Split Guides

Unicode System:

As a prerequisite for the conversion, your system needs to be a Unicode system. If your system is still non-Unicode, you can follow a two-step conversion approach: First, perform a combined upgrade and Unicode conversion with one of the supported start releases as target, then perform the conversion to SAP S/4HANA

Pre-Checks and Pre-Requisites:

Before moving to S/4HANA, you need to take care of pre-checks and pre-requisites. This includes locating obsolete and new Tcodes, as well as MM-related tables and other necessary inspections.

a) Remove Client 066:

Client 066 is the Early Watch client which was set up during the installation of your system. This client is not used in SAP S/4HANA. To prevent issues, for example, with job scheduling, you have to remove it before starting the conversion.

To remove client 066, proceed as described in SAP Note 1749142

?

b) Uninstall SAP Fiori Apps

If you have SAP Fiori apps installed locally on your source system, you need to uninstall them if they are not released for USER INTERFACE TECHNOLOGY 7.50 (SAP_UI 7.50). If you do not uninstall these apps, the Maintenance Planer will not allow a conversion for your system.

Check SAP Note 2034588 for a list of apps that you need to uninstall and the steps required to do so. Uninstall the apps using SAINT. For more information, see SAP Note 2011192 .

CVI Implementation (I had written a detailed article about it, click here to display):

Converting a legacy SAP ERP system to a SAP S/4HANA system requires CVI installation. Customer/vendor data must be archived, business operations must be activated, custom enhancements must be integrated, and check reports and CVI adjustments must be implemented.

Data Transition Validation:

The data transition validation is a tool that allows you to compare business data before and after a system conversion from SAP ERP to SAP S/4HANA, or before and after an SAP S/4HANA upgrade. The tool supports validation of upgrade or conversion scenarios with predelivered content for business validation. The tool uses business reports or transactions as instruments of comparison. It is available as part of the standard license. You can access this tool by using transaction DVF in your SAP system. It utilizes pre-delivered content in the form of business reports or transactions to serve as a basis for comparison. These pre-delivered business reports or transactions help to streamline the process and ensure accurate results.

Data Volume Reduction:

SAP Data Volume Management is designed to reduce the data footprint so that you can achieve a shorter conversion duration due to reduced load size. Data Volume Management (DVM) offers various capabilities supporting the pre- and post-conversion phases. One central tool is the SAP DVM Work Center (DVM WoC) in SAP Solution Manager, including tools with a special focus on SAP HANA.

?? Guided Self Service: You can generate a best practice document to determine data that can be reduced most efficiently in an SAP system before the conversion. You can use the same tool after the conversion to develop a blueprint for a DVM strategy.

? Reorganization and Compression: You can use this tool without a SAP HANA context in order to simulate the savings gained by reorganizing tables or databases or compressing the database.

? In addition, you can simulate the future system size of your system. This is useful for a forecast of the impact any planned measures may cause.

Beside the DVM Work Center, Data Volume Management offers services to give you an overview of your data distribution and quality as well as services to help you to develop a DVM road map for your system landscape. All services allow you to make flexible decision about your content and data volume management.

?S/4Hana Size

Start with: Principles of Sizing SAP S/4HANA with the Quick Sizer Tool

To determine the appropriate sizing for S/4HANA, you can utilize the SAP-specific tool called the S/4HANA Quick Sizer (link here: https://www.sap.com/about/benchmark/sizing.quick-sizer.html)

This tool is applicable to both greenfield (new) installations and existing ECC systems.

While the term "quick sizing" might imply a simple process, it's important to note that the tool is quite advanced and requires a substantial amount of input to generate accurate sizing recommendations

How to fill the quick sizer is explained in OSS note 2467172 - How to size Fiori applications based on number of users - SAP for Me

a) Memory Sizing:

To begin, apply the OSS note 1872170 - ABAP on HANA sizing report (S/4HANA, Suite on HANA...) in your current ECC system.

This note will make report /SDF/HDB_SIZING available in your system. (Before running the /SDF/HDB_SIZING program it is best to update it with the most recently available updates: 3104284 - HANA memory Sizing report - Advanced correction 15 and 3149498 - HANA memory Sizing report - Advanced correction 16)

The sizing report includes the sizing projections, based on the actual table sizes in the legacy system as well as an estimation of how much the memory footprint can be reduced using functionalities that SAP HANA will enable.

It's recommended to initially test this report in a development system and subsequently transport it to the production environment for actual sizing calculations.

b) CPU sizing:

More details on CPU sizing can be found in 1793345 - Sizing for SAP Suite on HANA

If you want to estimate the HANA CPU requirements, then you should identify the CPU consumption of the database. You can for example look at the CPU consumption of the database process(es) using SAP's monitoring tools. To fully support the parallel processing capabilities of HANA for optimal response times for analytical applications SAP prefers a factor of 3 more CPU power for HANA than for disk based databases without parallelization of single statements. This also considers the load for running OLTP and Reporting simultaneously and includes a moderate use of SAP HANA Enterprise Search. Extensive usage of SAP HANA Enterprise Search capabilities might require additional CPU resources.

c) Disk space

To give a prediction regarding the required HANA disk space (or: total net disk space), you have to take into consideration the net data size on disk (anyDB) and the disk space required for Delta Merges. During a Delta Merge, the affected tables are temporarily duplicated on disk for a short period of time. The disk space for merges is calculated by taking the sum of the two biggest tables and include this value into the calculation.

On top, you should add 25GB for the space required by the statistics server, HANA metadata, etc. The final calculation looks as follows: HANA disk space (Total Net Disk Space) = (Net Data Size anyDB + Disk Space for Merges) / 4 (compression) * 1,2 (20% safety buffer) + 25GB.

If you are using SAP HANA Enterprise Search, you should add 20% disk resources on top.

More information regarding SAP HANA Storage Requirements can be found in this document (https://scn.sap.com/docs/DOC-62595)

2869647 - Guidance for use of Data Aging in SAP S/4HANA

2416490 - FAQ: SAP HANA Data Aging in SAP S/4HANA

2818267 - Data Volume Management during migration to SAP S/4HANA

4) Maintenance Planner

You need to run the maintenance planner tool as a first step in the conversion process. It checks your components, add-ons, and business functions to ensure compatibility with SAP S/4HANA and also creates the stack file used for the actual conversion process (done by the Software Update Manager tool).

In particular, the Maintenance Planner checks if the following items are supported for the conversion:

a) Active business functions in your system

b) Add-ons to your system

c) Industry solutions

If there is no valid conversion path for any of the items listed above (for example, an add-on is not released for the conversion yet), the Maintenance Planner prevents the conversion. After the check, the Maintenance Planner creates the stack configuration file (stack.xml)

In order to generate the stack.xml, you need to have an SAP S/4HANA license. You can do the above checks without a license, but you cannot create a stack.xml with the Maintenance Planner without a license.

For more information, see the Maintenance Planner User Guide at https://help.sap.com/maintenanceplanner

a) Business Functions:

Business functions can have the following status: always_on, customer_switchable, and always_off. This results in the following behavior during the conversion:

? If a business function was switched on in the start release system, but defined as always_off in the SAP S/4HANA target release, then a system conversion is not possible with this release.

? If a business function was switched off in the start release system, but defined as always_on in the SAP S/4HANA target release, then the business function will be activated during the conversion.

? If a business function is defined as customer_switchable in the SAP S/4HANA target release, it will keep the state defined in the target release during the conversion.

b) Add-Ons

During the conversion, add-ons are either merged into SAP S/4HANA or deleted if no successor is available. Some add-ons may be included without being fully functional.

For a list of supported add-ons, see SAP Note 2214409 .

For information about uninstalling add-ons, see SAP Note 2011192 .

c) Industry Solutions

For information about supported industry solutions, see SAP Note 3230844 .

5) Simplification Item Catalog

Recommendation

We recommend that you consume the simplification items also via the SAP Readiness Check for SAP S/4HANA. Based on an analysis of the configuration, data, and usage of your productive SAP Enterprise Resource Planning system, the SAP Readiness Check for SAP S/4HANA identifies the simplification items relevant for your conversion.

For more information about how to use the SAP Readiness Check for SAP S/4HANA, see https://help.sap.com/viewer/p/SAP_READINESS_CHECK

These checks identify important steps you need to take to make sure that your system can technically be converted and that your business processes can start running directly after the conversion process has been completed.

The Simplification Item-Check (SI-Check) will be called by the Software Update Manager (SUM) tool to ensure that the system is in a consistent state. The SI-Check is delivered with SAP Notes 2399707 and 2502552 . SAP Note 2399707 delivers the new check report; SAP Note 2502552 delivers the check classes via transport-based correction instructions (TCI) and prerequisite notes.

*To enable TCI implementation, follow the instructions provided in SAP Note 2187425 (see especially the PDF file attached to the SAP Note).

You run the SI-Check to identify the simplification items relevant for your conversion project. We recommend to do this early in the project, to get an overview of the conversion scope.

?1. Start the report /SDF/RC_START_CHECK in transaction SA38.

2. In the section Simplification Item Check Options, choose the target SAP S/4HANA version.

3. Choose the mode in which you want to run the checks:

? In online mode: The results are displayed immediately after the check is finished.

? As a background job: We recommend this option if the check will need a long running time.

4. Run the checks to get an overview over all simplification items and then check the system consistency with Check Consistency for All.

5. Check the results

The report returns a list of relevant and irrelevant simplification items. It is recommend that you check every relevant simplification item for the impact it will have on your conversion project.

Some simplification items have a consistency check. The consistency check identifies inconsistencies in the system that would be a problem during the SUM process. It also provides additional information on how to solve the problem. Some simplification items do not have a consistency check, but nevertheless are relevant. This means that from a technical perspective a conversion of your system is possible without any action from you, but there will be an impact and you should investigate it.

6) Custom Code Migration

The custom code migration checks are based on the simplification item concept. With SAP S/4HANA, business processes have been changed and simplified. Before converting to SAP S/4HANA 2022 (or any of its feature package or support package stacks), you need to check your custom code against the SAP S/4HANA simplifications in a SAP S/4HANA 2022 (or the relevant 2022 feature package or support package stack) system.

The simplifications are loaded into the Custom Code Migration tool. After you run the tool, you get a list of instances where your custom code does not comply with the scope and data structure of SAP S/4HANA.

The custom code checks do not yet identify all the instances where your custom code does not comply with SAP S/4HANA. For a full overview of changes that may affect your custom code, see the Simplification Item Catalog.

It is highly recommend that you perform these checks before starting the conversion process, because this step is the most important preparation for your ABAP custom code on the way to SAP S/4HANA. Even if you do not plan to take development actions before the conversion, these checks will give you a sound foundation for your project planning and organization. They also enable you to decide on helpful preparatory activities, such as the decommissioning of unused custom code. The application content of the simplification database is being increased and improved over time. In addition to the custom code analysis and adaptations based on the Custom Code Migration tool, you also need to test the custom code within SAP S/4HANA.

For additional information about the Custom Code Migration tool, see:

? SAP Note 2241080 (for information about how to download the simplification database).

? Custom Code Migration Guide for SAP S/4HANA at https://help.sap.com/s4hana_op_2022 Implement -> Conversion & Upgrade Assets.

Realize Phase

1. Conversion Using SUM

After the preparation phase, you start with the realization of the conversion to SAP S/4HANA using the Software Update Manager (SUM) tool.

When you have completed the steps above, and have implemented all the adaptations required to ensure your system and your custom code is suited to SAP S/4HANA, you then run the SUM. The SUM does the database migration (if required), the actual software update, and the data conversion.

Within the SUM-process the following steps are done in a one-step procedure (for dedicated start releases):

a) Database migration (optional).

If your source system is not yet running on the SAP HANA database, use the database migration option (DMO) of the Software Update Manager to migrate your database to SAP HANA during the conversion.

b) Installation of the SAP S/4HANA software.

c) Conversion of your data into the new data structure used by SAP S/4HANA (this is the automated part of the data migration)

2. Custom Code Adaptation

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

1. You need to adapt any modifications and enhancements using the standard transactions SPDD, SPAU and SPAU_ENH. This is the same process as in previous upgrades in the SAP Business Suite product portfolio except that the tools SPDD and SPAU have been renewed.

2. You need to fix any issues due to SAP S/4HANA simplifications. To find the issues, you use the ABAP Test Cockpit (ATC) and do a check run with the check variant S4HANA_READINESS locally in your converted system.

It is recommend to use the ABAP development tools for Eclipse to do the custom code adaptation as SE80 no longer supports all development object (such as CDS Views) needed in SAP S/4HANA

3. Adapting Database Extensions to SAP S/4HANA

When you convert your system from SAP Suite on HANA to SAP S/4HANA, modifications to the SAP HANA database remain unchanged. However, to make your modifications visible on the UI, manual steps can be required in different content layers.

If required for your modifications, adapt the relevant Core Data Service (CDS) views in the SAP Business Suite layer. You can extend CDS views by using ABAP development tools.

4. Output Management

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

Prerequisites for Output Control

? bgRFC configuration has been set up

? Storage system and category have been maintained

? BRFplus is active and usable

? Adobe Document Services is available (when using Adobe Forms)

5. Follow-On Activities for the Conversion of Authorizations

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

6. Adapting the User Interface

Key users can adapt the user interface (UI) of their apps at runtime in a modification-free way, for example, by adding, removing, or moving fields and groups. Runtime adaptation is supported for apps that use SmartForm controls with stable IDs. Note that you can only add fields which have been made available for this app. If you need additional fields, you have to create them as described at https://help.sap.com/s4hana_op_2022

7. Cleaning Up Obsolete Data After the Conversion

The Obsolete Data Handling tool allows you to delete obsolete data that may remain after the conversion of your SAP ERP system to SAP S/4HANA. 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 is not 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. For information on how to enable and use this tool in a productive SAP S/4HANA system, see SAP Note 2661837 .

*Feel free to connect and follow me to stay updated on the upcoming informative articles.

Cheers :)