I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #9 of 10 part blog series.
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks, completed CVI activation, SUM DMO Downtime, custom code remediation, Finance Conversion and mandatory innovations design and are ready to complete to application specific follow-on activities.
Other than mandatory innovations, there are activities that are executed Post SUM (DMO) either during downtime or post go-live. This is done to improve the execution time of the SUM tool as these activities enrich the data but are not critical to technical functioning of the application (similar to Activities After Migration in Finance Migration that can be executed anytime after downtime even post go-live). Few examples are Emp to BP Sync (technically not recommended with CVI), Pricing Table Enrichment (via report PRC_MIG_POST_PROCESSING) and activation of available but blocked FI Transactions (OSS Note 2393666). Please read the conversion guide in detail and also the simplification OSS Notes for all the relevant items identified for your scenario to make sure that you do not miss some follow-up steps. In addition to this, any additional data migration requirements to populate the custom fields (from old data model table to new data model tables) will also be accomplished in this phase of the project.
Other than this, there are a few technical tasks you need to execute like in any upgrade project (remember that S/4HANA is still based on Netweaver (now renamed as ABAP Platform) thus all your upgrade knowledge will come handy here too). Few examples are Mass Query Generation, Report Painter Generation, Rescue Variants, VOFM Routines Generation, Post Migration HANA DB Checks, SAP Initial Consistency Check, Missing / Inconsistent DB Objects and enabling custom fields for use in the in-app extensibility etc.
In addition, all conversion documentations also talk about activating BRF+ (including ADS) at this stage and my recommendation is to make sure that the technical setup for both is complete irrespective of whether you decide to use BRF+ for output management or not. Same is true for FIORI too, whether you adopt FIORI upon go-live or not, it is important to make sure that you setup the FIORI launchpad at least (task list SAP_FIORI_FOUNDATION_S4), so later on activation of Apps will be easy (use task list SAP_FIORI_CONTENT_ACTIVATION for the same but do not activate all the business roles but choose only the ones you need; as this task list is all inclusive and will even include apps for functionalities that require additional business function activation hence will fail for your scenario if the dependent features are not activated).
If FIORI Apps are not activated and you decide to use S/4HANA post conversion using SAP GUI only (yes it is possible depending on your transaction usage !!!), you can retain the ECC SAP GUI look and feel for S/4HANA too.
SAP GUI -> More -> SAP GUI Settings and actions -> Visual Design -> Theme Settings (=> Select Theme = "SAP Signature Theme"; Uncheck "Activate FIORI Features").
If you do decide to activate the FIORI Apps, remember there are different technical categories of FIORI Apps (refer to image above) and depending on your usage scenario you will have to decide on the kind of apps that are suited for you. Complete details of FIORI activation can be found in the UI Technology Guide for S/4HANA.
This bring us to the last technical topic of S/4HANA conversion that is Security. Like in any upgrade, you will have 3 kinds of security impact 1) Auth Object Adjustments (new/deprecated) in existing transactions 2) Obsolete/Replaced Transactions (in some cases old auth. objects are still relevant) and 3) New applications implemented. Usual perception is that #3 will contribute to significant number of security role changes but in reality it is #1 that will make you spend maximum efforts as #1 has impact to existing roles whereas #3 has brand new roles. To ease the adoption of new security changes, SAP provides SU25 transaction which helps you with 1) take over standard SAP roles to SU24 table and 2) adapt customer definitions in SU24 tables. You can also delete the records that are not aligned with new application design (though because of extensive testing requirements this is usually ignored). Post adjusting the authorization objects for existing roles, effort required for adjusting obsolete transactions and new transactions will be very limited and time boxed.
Having taken care of all the core requirements of system build in case of system conversion, it is equally important that testing is planned sufficiently well. When it comes to testing, system conversion will have all the usual testing phases of a project (as marked in the diagram above). In addition, we also do:
In TOPIC 10 we will discuss "Planning the Cutover".
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks, completed CVI activation, SUM DMO Downtime, custom code remediation, Finance Conversion and mandatory innovations design and are ready to complete to application specific follow-on activities.
Other than mandatory innovations, there are activities that are executed Post SUM (DMO) either during downtime or post go-live. This is done to improve the execution time of the SUM tool as these activities enrich the data but are not critical to technical functioning of the application (similar to Activities After Migration in Finance Migration that can be executed anytime after downtime even post go-live). Few examples are Emp to BP Sync (technically not recommended with CVI), Pricing Table Enrichment (via report PRC_MIG_POST_PROCESSING) and activation of available but blocked FI Transactions (OSS Note 2393666). Please read the conversion guide in detail and also the simplification OSS Notes for all the relevant items identified for your scenario to make sure that you do not miss some follow-up steps. In addition to this, any additional data migration requirements to populate the custom fields (from old data model table to new data model tables) will also be accomplished in this phase of the project.
Other than this, there are a few technical tasks you need to execute like in any upgrade project (remember that S/4HANA is still based on Netweaver (now renamed as ABAP Platform) thus all your upgrade knowledge will come handy here too). Few examples are Mass Query Generation, Report Painter Generation, Rescue Variants, VOFM Routines Generation, Post Migration HANA DB Checks, SAP Initial Consistency Check, Missing / Inconsistent DB Objects and enabling custom fields for use in the in-app extensibility etc.
In addition, all conversion documentations also talk about activating BRF+ (including ADS) at this stage and my recommendation is to make sure that the technical setup for both is complete irrespective of whether you decide to use BRF+ for output management or not. Same is true for FIORI too, whether you adopt FIORI upon go-live or not, it is important to make sure that you setup the FIORI launchpad at least (task list SAP_FIORI_FOUNDATION_S4), so later on activation of Apps will be easy (use task list SAP_FIORI_CONTENT_ACTIVATION for the same but do not activate all the business roles but choose only the ones you need; as this task list is all inclusive and will even include apps for functionalities that require additional business function activation hence will fail for your scenario if the dependent features are not activated).
If FIORI Apps are not activated and you decide to use S/4HANA post conversion using SAP GUI only (yes it is possible depending on your transaction usage !!!), you can retain the ECC SAP GUI look and feel for S/4HANA too.
SAP GUI -> More -> SAP GUI Settings and actions -> Visual Design -> Theme Settings (=> Select Theme = "SAP Signature Theme"; Uncheck "Activate FIORI Features").
Figure 1 : FIORI Apps available and considerations based on your usage scenario (Source OpenSAP)
If you do decide to activate the FIORI Apps, remember there are different technical categories of FIORI Apps (refer to image above) and depending on your usage scenario you will have to decide on the kind of apps that are suited for you. Complete details of FIORI activation can be found in the UI Technology Guide for S/4HANA.
This bring us to the last technical topic of S/4HANA conversion that is Security. Like in any upgrade, you will have 3 kinds of security impact 1) Auth Object Adjustments (new/deprecated) in existing transactions 2) Obsolete/Replaced Transactions (in some cases old auth. objects are still relevant) and 3) New applications implemented. Usual perception is that #3 will contribute to significant number of security role changes but in reality it is #1 that will make you spend maximum efforts as #1 has impact to existing roles whereas #3 has brand new roles. To ease the adoption of new security changes, SAP provides SU25 transaction which helps you with 1) take over standard SAP roles to SU24 table and 2) adapt customer definitions in SU24 tables. You can also delete the records that are not aligned with new application design (though because of extensive testing requirements this is usually ignored). Post adjusting the authorization objects for existing roles, effort required for adjusting obsolete transactions and new transactions will be very limited and time boxed.
Figure 2 : Conversion Program Testing Phases (Source Open SAP)
Having taken care of all the core requirements of system build in case of system conversion, it is equally important that testing is planned sufficiently well. When it comes to testing, system conversion will have all the usual testing phases of a project (as marked in the diagram above). In addition, we also do:
- Smoke Testing : During Sandbox Conversion to validate the impact to critical business processes and any showstoppers
- HA/DR Testing : Because of new hardware and OSDB requirements of S/4HANA system and any changes required to the network layer (for better performance of nodes and to avoid single point of failure).
In TOPIC 10 we will discuss "Planning the Cutover".
- SAP Managed Tags:
