About Me

My photo
I am Suresh Chinta, working on SAP HANA Cloud & SAP BTP Cloud/ AWS/Azure cloud consultant.I have experience in SAP Basis/Netweaver , S4HANA Cloud implementations / Support. I'm certified Microsoft Azure cloud & AWS professional. I have started this blog to share my knowledge with all those who are interested to learn & enhance their career.

Thursday, May 30, 2024

Setup SAP Cloud ALM for Operation

This blog will be mainly focused on steps to setup your SAP Cloud ALM for Operation for SAP S/4 HANA and SAP Business Suite.


Operation in SAP Cloud ALM has 7 use cases which includes Health Monitoring, Business Process Monitoring, Real User Monitoring, Interface & Exception Monitoring, Synthetic User Monitoring, Job and Automation Monitoring and Business Service Management.


 So to setup and configure SAP Cloud ALM, you need to follow the below steps:

1. Go to SAP Cloud ALM Portal and click on "Request" with your S-User ID


2. Once you click on Request, then in "Systems and Provisioning" click on "Start Provisioning".


3. After this step, you need to select the "Region" and "Subdomain". Subdomain is generally in the name of <organization name or abbreviation>-cloudalm. For example if the organization name is abc limited, then the cloud alm subdomain name can be abc-cloudalm , abcltd-cloudalm , abc-ltd-cloudalm , etc.


4. In this step, you need to select "SAP Cloud Identity Service" and click on submit.


5. After this, you can see the status of provision as "Request Submitted".


6. Wait for around 15 mins, the provision status will be approved and a cloud sub-domain will be provisioned to your id.


7. After the SAP Cloud ALM is provisioned, you will get an email with subject "Activate Your Account for User Profile" , in which you need to activate your account and set your password for your account.


8. Once the account is activated, your will get an email with subject "Access information for SAP Cloud ALM". In the same email you will get URL for navigating to your SAP Cloud ALM launchpad.


9. After this is done, then you need to follow Procedure for Enabling SAP Cloud ALM API to configure your BTP service.


10. Once the SAP Cloud API is configured, you need to configure and perform the pre-requisites as mentioned in Setup for SAP S/4HANA and SAP Business Suite


11. Once the above things are in place, you are ready to use and explore SAP Cloud ALM.

Wednesday, May 29, 2024

SAP SUM (Software Update Manager) Upgrade Phases

 SUM Having mainly 6 steps,

  • Extraction
  • Configuration
  • Checks
  • Preprocessing
  • Execution
  • Postprocessing

        Below the very detailed briefing of each step involved in SUM process for ABAP system.

Step 1.Extraction

  • DDIC username and password
  • Identify database & SAP version
  • Checks the stack xml file
  • Scanning of download directory where all the patches are placed
  • Extract files to move to EPS/in
  • Check SPAM version. Skip this if SPAM is already in latest version
  • <SID>ADM credentials
  • Pre-upgrade S-note list implementation
  • Checks if the source and target system is valid for update
  • Checks SAP system release
  • Checks the system profiles

Step 2. Configuration

  • Input parameters for type of upgrade (downtime optimizes, higher complexity, high resource assignment)
  • Keep database archiving on
  • Execution strategy for transaction SGEN
  • Maximum number of processes to be used for load generation. SGEN Processes
  • Batch Process(Uptime) & Batch Process(Downtime)
  • Maximum number of DDL processes (Uptime and Downtime)
  • Number of parallel import processes (R3trans -Uptime and Downtime)
  • Parallel Phases (Uptime and downtime)
  • Update Instances
  • Enhancement package inclusion
  • Add-On selection
  • Modification Adjustment (SPDD transport request and SPAU transport request)

Step 3. Checks

  • Space check in database, if space is Insufficient then extend tablespaces with script
  • BW checks and phases
  • Activation and conversion checks
  • Modification support
  • Preliminary upgrade processing
  • List Locked SAP objects

Step 4. Preprocessing

  • Check for locked objects
  • ABAP Workbench locking
  • Run shadow system for preparation of new release (ACT_UPG, PARDIST, SGEN)
  • SPDD Adjustments
  • Downtime Starts

Step 5. Execution

  • Merging of shadow and Real Instance
  • system upgrade
  • Table conversion
  • Downtime Complete

Step 6. Post-processing

  • SPAU change
  • Backup
  • Create folder in trans directory (EHPi)

To know the exact downtime taken for this upgrade, Please find UPGANA.XML file for detailed information from the below mentioned path:

Location of the file as below
./SUM/abap/htdoc/UPGANA.XML for SUM 1.0
../SUM/abap/doc/analysis/UPGANA.XML for SUM 2.0






























































































Phase name



Brief details



CHECK4NOTES_TOOL phase:



SUM asks to implement some necessary SAP Notes



CHECKPROF_INI phase:



SUM checks the system profiles for problems



CHECKSYSSTATUS phase:



SUM reads the profiles and checks the state of the running instances



CONFCHK_IMP phase:



In this phase SUM checks the Operating System and Database Version



DBCHK_PRE phase:



SUM Determines database version and SAP release



DBCONNCHK_INI phase:



SUM tests if new tools can connect to the database



DBQUERY_PRE phase:



SUM checks the database state and asks database dependent questions



DETMAINMODE phase:



SUM checks the stack xml file and decides about the main program mode



EXTRACTKRN_PRE phase:



SUM tests a kernel DVD to install SUM in /usr/sap/<dir>/SUM/abap/exe



INITPUT_PRE phase:



SUM reads profiles and initializes knowledge about the system



INSTANCELIST_PRE phase:



SUM will gather information about the instances of the system



JOB_RSUPDTEC phase:



In this phase a batch job RSUPDTEC will be started. This job resolves inconsistencies in TABART-TABSPACE mapping. Log files: PSUPDTEC.LOG PSUPDTEC.ELG



KX_CPYORG phase:



SUM Copies the original kernel to $(PUTPATH)/exe



PROFREAD phase:



SUM reads the profiles and prompts for required passwords



READCVERS_DUMP phase:



SUM reads the CVERS table content



READDATA_EXP phase:



SUM tests a kernel DVD to install SUM in /usr/sap/<dir>/SUM/abap/exe



SCAN_DOWNLOADDIR phase:



SUM scans the download directory and extracts the packages



TOOLCHECKXML_INI phase:



SUM determines and checks the tool versions in SYS (the active SAP kernel directory)



TOOLIMPD phase:



SUM prepares the ABAP dictionary for importing upgrade tools on the standard instance



TOOLVERSXML_UNI phase:



SUM checks the tool versions if the system is UNICODE



VALCHK_INI phase:



SUM checks if the source and target system is valid for update



VERSCHK_INI phase:



SUM checks if the SAP system release



Tuesday, May 21, 2024

SAP SLT Replication Step-By-Step

 Installation Option For An ABAP And A Non-ABAP Source

When it comes to performing the SLT replication procedure, you can do it through more than one source. Here’s what you need to know about them.

For ABAP Source System

In this case, you can perform the installation procedure through two different options. Please keep reading to learn more about this aspect –

Option – A: The Replication Server Is An Entirely Separate System.

To begin with, you can establish the connection between the SAP Source and the SAP SLT as an RFC connection. If you are not comfortable with that, you may also do the same by using the DB connecting procedure. Once you are done with the table replication procedure, you might try creating a logging table within the source system. Conversely, the read module is going to be created automatically within the SAP Source System.

Option – B: The Replication Server Has Been Installed Within The Source.

In this case, the SAP LT replication server has to be installed at the beginning of the process. Once it’s done, you’ll need to integrate the required SAP NetWeaver and SAP kernel with the same too. The system architecture, then, must be simplified into a two-tier system.

For A Non-ABAP Source System

In this aspect, your job will be a little more intricate and complicated if you haven’t done this task before. Here’s what you have to do here.

  • In the beginning, you will need to install the SAP LT server into a separate structure. And, once you’re done, you’ll have to only create the read modules in this case. And the connection between the non-ABAP source to the SAP LT server will be prompted or established through a database connection.
  • In the second case, you should begin by checking if your non-ABAP source system is fulfilling all the usage-related prerequisites or not. After all, database connectivity from the non-ABAP system to the SAP LT server will be required in this aspect. Thus if the connection hasn’t been secured, the replication procedure might get crashed.

The Steps Of SLT Replication

Usually, the SLT replication procedure is completed in five minor yet important steps. It may include the following ones for you –

Step – 1: Installing The Replication Server.

The SAP LT replication server will be shipped in a DMIS-based add-on call. So, if you want to begin the replication procedure, you’ll need to install the server in your system first. The installation should be done within your ABAP source system and in the server too.

Note: If the source system is based on an on-premise SAP S/4HANA structure, then there’s no need to install the add-on DMIS. Just check if your system’s release configuration is 1610 or higher or not. In that case, you are good to go.

Step – 2: Configure The Source Data System.

Now, you’ll need to create an RFC ABAP connection to the Source data system from the SLT system. In this case, you will need to fill up the following slots in a drop-down display menu known as RFC destination –

  • The RFC destination.
  • The connection type.
  • The Description 1 section.
  • The Target Host.

… and the IP address. 

The final option will probably be collected by the system automatically. But, if it doesn’t work for some reason, you will need to provide the same manually.

Step – 3: Begin Your SLT Configuration From The LTR Transaction.

Now, you will need to launch the LTR code you received from the system and start with your guided configuration. It, in turn, will help create the database connection to target the HANA database. Here is some additional information that you need to know in this regard –

  • Initial Load Mode: It’s possible to define an Initial Load Mode in case you want to opt for a specifically-different reading type. The “resource optimised” note will define the “default” mode of the system. It will utilise reading type 3 for all the tables. In any case, the “performance optimised” will use a reading type 4 or 5.
  • The Number Of Initial Load Jobs: This term defines a job that’s used in the initial load process within the SAP LT replication server.
  • The Number Of Calculation Jobs: This value will specify the number of access plan-related calculation jobs. All of these will be allocated by the provided config.
  • The Number Of Data Transfer Jobs: Unlike the former, this value will define the overall number of DTJs in your system. 

Step – 4: Start From The Source System.

At first, you will need to create a database view or a table. And once you are done, you have to start the replication procedure with the same DB. 

Please keep in mind that the process of initial load will begin in this aspect. And it may take quite a bit of time to load the data at the initial phase.

Anyway, once the replication process is active, you will need to perform the following steps to complete the procedure –

Set Up SAP HANA System Replication with the SAP HANA

HANA System Replication is one of the important topic in SAP HANA.
Being used in the context of high availability and disaster recovery scenario, It is really important to learn how to setup HANA System Replication in multi-tier replication scenario.

 In this scenario we are enabling HANA System Replication – In Multi-tier scenario.

 There are 3 HANA nodes: A, B and C, named SiteA, SiteB and SiteC
Site A : Primary Database Node
Site B: Secondary Database Node / HA Node
Site C: DR node

  • Replication Mode:
    From Site A –> Site B : SYNC
    From Site B –> Site C : ASYNC
  • Operation Mode:
    From Site A –> Site B : logreplay
    From Site B –> Site C : logreplay

     HSR Scenario: HANA System Replication

Prerequisites:

  • Install HANA on primary and secondary node
                  With different host names
                  With same HANA system ID
                  With same instance number
                   Start up each HANA independently
  • Ensure, The primary and secondary system are both installed and configured properly. Do verify that both are independently up and running fine without any issue
  • Ensure, that the host-names in the primary system are different from the host-names used in the secondary systems.
  • Ensure, The secondary system must have the same SAP system ID,<SID> and instance number as the primary system.
  • Ensure, The software version of the secondary has to be equal or newer to the version on the primary system
  • Ensure that the following configuration parameters are set
    ini
    [persistence] log_mode = normal
  • Do prepare the secondary system by copying the system SSFS keys from the primary system to the secondary system.
    Manually copy SSFS_<SID>.DAT and SSFS_<SID>.KEY from primary host to secondary host.
    These files are in path /<SID>/global/security/rsecssfs/data and /<SID>/global/security/rsecssfs/key respectively

 HANA System Replication : Primary Node: Site A Configuration

 [Node A] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start
[Node A] create data backup
[Node A] enable system replication: hdbnsutil -sr_enable –name=SiteA
[Node A] verify the HSR state : hdbnsutil -sr_state

 HANA System Replication : Secondary Node- HA Node: Site B Configuration

 [Node B] Stop Database : HDB stop or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Stop

[Node B]Register site:
hdbnsutil -sr_register –mode=sync –name=SiteB –remoteInstance=<instId> –remoteHost=<hostname_of_A> –operationMode=logreplay
[Node B] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start
[Node B] enable this site as replication source system: hdbnsutil -sr_enable
[Node B] verify the HSR state : hdbnsutil -sr_state

HANA System Replication : DR Node- : Site C Configuration

 [Node C] Stop database: HDB stop or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Stop

[Node C] Register tier 3 secondary:
hdbnsutil -sr_register –mode=async –name=SiteC –remoteInstance=<instId> –remoteHost=<hostname_of_B> –operationMode=logreplay
[Node C] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start

[Node C] verify the HSR state : hdbnsutil -sr_state

 Reference command in case of change in replication mode and operation mode :

hdbnsutil -sr_register –name=<secondary_alias> –remoteHost=<primary_host> –remoteInstance=<primary_systemnr>
–replicationMode=[sync|syncmem|async] –operationMode=[delta_datashipping|logreplay|logreplay_readaccess]

 Check if everything went fine by issuing SELECT * FROM M_SERVICE_REPLICATION on the primary site:

 

HANA High Availability

SAP HANA database runs mission critical applications and it is important that these systems remain available to users always. This requires that these systems can make faster recovery after system component failure (High Availability) or after a disaster (Disaster Recovery). This should happen without any data loss (zero RPO) and in very short recovery time (low RTO).

To provide fault recovery SAP HANA software includes a watchdog function, that automatically restarts configured services (index server, name server, and so on) in case of their failure. In addition to these features, SAP and its partners offer the following high availability mechanism for SAP HANA. These solutions are based on completely redundant servers and/or storage.

  • Host Auto-Failover: One (or more) standby nodes are added to a SAP HANA system and configured to work in standby mode. In case of failure, data and log volumes of a failed worker node is taken over by a standby node. The standby node becomes a worker node and takes over user load. This solution does not need additional storage, only servers.
  • SAP HANA System Replication: SAP HANA replicates all data to a secondary SAP HANA system constantly. Data can be constantly pre-loaded in the memory of the secondary system to minimize the recovery time objective (RTO). This solution needs additional servers and storage. The focus of this reference architecture guide is SAP HANA System Replication.
  • Storage Replication: Data replication is achieved by means of storage mirroring independent from the database software. Disks are mirrored without a control process from the SAP HANA system. SAP HANA hardware partners offer this solution. This solution needs additional servers and storage.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

  • Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
  • Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
  • Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

  • Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
  • Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
  • Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.
  • Full Sync: Full synchronization is supported by SAP but cannot be configured with SUSE HAE. Full Sync mode stops the surviving node if either node is down, so failover with SUSE HAE is not possible.

If the primary SAP HANA system fails, the system administrator must perform a manual takeover. Takeover can be performed using SAP HANA Studio or the command line. Manual failover requires continuous monitoring and could lead to higher recovery times. To automate the failover process, SUSE Linux Enterprise High Availability Extension (SUSE HAE) can be used or you can any third party vendor. The use of SUSE HAE for the takeover process helps customers achieve service level agreements for SAP HANA downtime by enabling faster recovery without any manual intervention.


Monday, May 20, 2024

DB Refresh of HANA Based systems using HANA Studio Backup/Recovery without SWPM

 HANA Studios DB restore option and hdbuserstore there after makes the whole process of a  System copy a lot simpler . The only limitation would be that the target schema would still remain as source.

The idea of this blog is to explain the process of performing  a simple homogeneous system copy of a HANA based system using the recovery of the source backup on the target HANA DB using HANA Studio.

In this case ,we will be  considering a situation of copying a Prod backup and refreshing it in a already running quality system

These are the salient steps involved in achieving this

Step 1 ) Take a complete DB backup of the source Database

Step 2) Move the database backup to the Target system

Step 3) Using HANA Studio recover the source db in the target HANA box

Step 4) Supply the license text so that the HANA Studio can automatically apply the license after install

Step 5) Modification of Schema access at the target DB

Step 6) Modify the default key  using the hdbuserstore on the application servers  and DB instance.

Step 7 ) Start sap

Step 8 ) Post activities.

Activities in the Source System :

Step 1 - Backup of the source DB .

Use the HANA studio backup studio to take a complete DB backup either at the disk level or using Backint.

Usually this should be sufficient to perform a DB Refresh but if you are looking for a  point in time recovery you may want the backups from the log area as well to include them post the recovery.

Step 2 ) : Move the database backup to the Target system

Once the backup is completed you will have to move the backup to a location in the target system , you should have 4 separate files with the your backup prefix . In this case the prefix is “COMPLETE_DATA_BACKUP_20122015”

 

Activities in the Target system

Step 3 ) Using HANA Studio recover the source db in the target HANA box

→ Shutdown SAP Application alone

→ Open HANA Studio and right click on the SID ( target) where you want to perform the recovery.

You will have to specify the destination location and the Backup Prefix for the HANA studio to recognize the backups 

If you just have a Complete data backup and not planning to recover log segments you can select the option “ Initialize Log area”... This is something like reset logs in oracle.


Step 4) Supply the license text so that the HANA Studio can automatically apply the license after install

  Post recovery your existing HANA License will be invalid , so here is a opportunity to mention the license text so that that can be installed automatically. If not this can be performed manually later.

 Step 5 ) Proceed with the recovery . Please note that the Target and source version must have the same configuration. Is there are specific configuration thats required in the target system that can be done manually as part of the Post steps.

Post recovery you should be able to see the Overview tab in HANA Studio with the Memory and Host Details.

Step 6) Modify the default key hdbuserstore on the application servers and the DB instance.

  • Go to /usr/sap/<SID>/hdbclient   and execute the below

hdbuserstore set default <dbhost>:<dbport> <dbuser> <dbpassword>

Let say for example our target host is : host01 and Source SID is  PRD and System No : 00  and lets assume that the source schema is SAPPRD and its password is sapprd#!

hdbuserstore set default host01:30015 SAPPRD sapprd#!


The above example is for the Unix system for Windows its a bit different (Refer SAP Note 1709838)



Execute a hdbuserstore list you should find the new Key set as below

KEY DEFAULT

   ENV:host01:30015

User: SAPPRD

This confirms that the key is set .

This has to be done on the appservers , else R3trans -d would fail.



Go back to HANA Studio and you should be able to see the contents under Catalog and Contents. You should also find the source Schema under Catalog.

At this point there is one more thing that needs to be done before we start the apps on the target system.

go to the DEFAULT profiles and modify the /dbs/hdb/schema to SAPPRD ( or whatever your source schema is ) .

At this point you are good to start SAP.

Follow the standard Post Refresh activities from there..

Few points to remember

- > You may want to disable the btc processes before starting SAP

→ Perform standard post steps like SE06/STMS/BDLS etc and activities specific to your case.

 

 

 

 

SAP ECC to SAP S/4HANA Conversion – A high-level guide for the beginners

 

 System Conversion in short is typically the fastest option, an approach that converts any SAP ECC 6.x system running on any database to SAP S/4HANA, preserving your existing configuration, customizations, and historical data. This approach allows a rapid technical conversion, adding innovations gradually for users.

The major teams involved in a conversion project are the Technology Team (responsible for executing the Software Update Manager(SUM) tool in all the platforms(Sandbox, Development, Quality, Dry and Production)) ; Functional Team (responsible for pre-check for Software Update Manager compatibility, Functional factory, Migration to new Finance Tables, Credit Management and Material Ledger activation, involving different Lines of Business) ; Security Team (adjustment of roles for new Fiori applications) ; the Advanced Business Application Programming (ABAP) Team (responsible for the custom code adaption, SAP S/4HANA code remediation etc.) and a Fiori Team (responsible for setting up the Fiori Launchpad and Launchpad designer).

To begin with a conversion project, we first need to discuss and decide on the data cleansing. This includes master data as well as transactional data cleansing (Cleansing historical data) based upon the customers’ statutory requirements. The data cleansing helps in reducing the database size to be converted proving beneficial to the technology team for a smooth conversion.

 

Starting with the Prepare phase, the base document to start with the conversion is the Readiness Check Report: (Transaction SE38 - execute /SDF/RC_START_CHECK)

Readiness Check is a high level analysis to get a Results  Dashboard and also download to a Results Document with details of Active Business Functions, Add-On Compatibility,  Custom Code Analysis, Recommended Fiori Apps, SAP S/4HANA Sizing, Simplification Items, Business Process Analytics and Data Volume Management.

The main elements that need to be analyzed from a functional point of view are - Active Business Functions, Add-On Compatibility and Simplification Items.

Active Business Functions – The active business functions, enable us to use specific new features and enhancements for our various business processes.

In SAP S/4HANA business functions can have the following status: 'always_on' , 'customer_switchable' , and 'always_off' . This results in the following behavior during the system conversion:


  • If a business function was switched on in the start release system, but defined as 'always_off' in SAP S/4HANA, on-premise edition, then a system conversion is not yet possible with this release at the current point in time.

  • If a business function was switched off in the start release system, but defined as 'always_on' in the target release, then the business function will be automatically activated during the conversion.


(Data Source – SAP Note 2240360 and 2240359 )

Add-On Compatibility – The check analyzes how many add-ons are installed in the system, with the help of a Maintenance Planner whether they are compatible with SAP HANA.

The Add-Ons existing on a customer’s SAP ECC system that shall be part of the target SAP S/4HANA release must be supported in order to permit the system conversion/upgrade process to go through.

The Maintenance Planner is a solution hosted by SAP that helps you plan and maintain systems in your landscape. The Maintenance Planner also helps the customer get a view on the compatibility status of the Add-Ons on his/her SAP ECC system before system conversion/upgrade to SAP S/4HANA.

Please refer https://blogs.sap.com/2021/03/15/handling-add-ons-during-a-system-conversion-to-sap-s-4hana/ for detailed description on handling Add-ons during system conversion.

Simplification Items – By executing the above mentioned report you can get a list of Simplification Items that are relevant to the specific customer database and must be looked into before converting the SAP ECC system to SAP S/4HANA.

Below is how the Simplification Items List, post execution of the Readiness Check Report in SE38 looks like:


(Image Source: SAP)

The column 'Relevance' describes the relevance of the item (relevant/ not relevant/ relevance cannot be determined(execute the check manually)).

The second column talks about the consistency of the item (warning/error/resolved/inconsistent). The Items with errors and warnings are the ones that need to be looked into and resolved before moving for conversion. There is also an option for exemption of the simplification items. This can be applied to the items that can be covered post conversion and would not impact the Software Update Manager run in any ways.

Each Simplification Item has a reference SAP Note that explains how to proceed in resolving the specific item. Referring to the corresponding notes, a consultant can easily proceed with the resolution of the open simplification items.

The Conversion works in three phases at a high level:

Pre-Conversion --- Software Update Manager (executed by technology team) --- Post-Conversion 

Pre-Conversion and Detailed Assessments:

The resolution of the Simplification Items is a pre-conversion activity. From Logistics side, most of the activities are Pre-Conversion, whereas for Finance, we have a lot of involvement during Post-Conversion as well. During this phase we conduct Detailed Assessment Sessions with the customers, introducing them to the possible changes that might directly or indirectly impact the business process once the system is converted.

Fit-Gap Analysis:

This is an important milestone, where the changes and their business impact is discussed in detail with the customers.  There are certain optional changes as well that are a part of conversion and should be explained to the customer in the As-Is and To-Be format in order to provide an opportunity to the customer to decide whether they want to proceed with the To-Be process or if they are okay with the current process and want to perform it As-Is. Another important decision that need to be discussed and taken is on the Fiori apps. Post conversion there are certain FI transactions that would become completely obsolete and would be replaced by Fiori. Along with the mandatory applications, customers also have a choice to implement Fiori apps for transactions that are still supported in SAP S/4HANA as well. These discussions can be conducted during the Fit-Gap Analysis sessions.

Software Upgrade Manager (SUM):

Post Completion of the identification and resolution of the Simplification Items, Basis team executes the  SUM (Software Upgrade Manager) tool - a multi-purpose tool that supports various processes, such as performing a release upgrade, installing enhancement packages, applying Support Package Stacks, installing add-ons, or updating single components on SAP NetWeaver.

Post-Conversion:

Following the Software Update Manager Conversion, next comes the turn of the post-conversion activities. These include the manual data migration, custom Code adaptions, any Workflows, Reports, Interface, Conversion, Enhancements and Forms (WRICEF) implementations that are required as part of the customer requirements and the system landscape.

Along with the above, the consultants are also required to prepare configuration document/run book that can further be used as a guide to understand the major configuration changes that have been conducted as part of the conversion.

Once we are done with the Post-Conversion Activities we proceed with the testing. This process is applicable for all the landscapes (Sandbox, Development and Quality). In Sandbox, we perform a smoke test, in order to test the basic transactions and functionalities. Similarly, in Development, we perform a round of unit testing. Once the Quality system is converted, System Integration Testing(SIT) and User Acceptance Testing(UAT) is conducted from the customer’s end (with the support of SAP).

Cutover Plan:

Post the System Integration Testing(SIT) and User Acceptance Testing(UAT) Sign-off, we start with the cutover planning. This includes a planned timeline for all the relevant actions to be performed in the dry run and the Production system to implement the final SAP ECC to SAP S/4HANA Conversion. The cutover plan includes the responsible Lines of Business's points of contact and their activities timed and planned in order to have a smooth and successful conversion.

Thus, to conclude, a successful conversion to SAP S/4HANA can be conducted if the above mentioned key points are considered and well looked into.

For more information on topics relevant to SAP ECC to SAP S/4HANA Conversion please do refer the below:

https://blogs.sap.com/2020/05/27/sap-s-4hana-1909-system-conversion-steps-details-how-to-be-prepared...

https://blogs.sap.com/2020/02/12/sap-s-4hana-1909-post-conversion-tips-and-suggestions/

https://go.support.sap.com/roadmapviewer/#/group//roadmap/BWHANATRANSONPRE/node/901B0E6D3F501ED78596...

Thank you!