This blog is relevant for conversions to S/4HANA On Premise 1610 and higher.
With SAP S/4HANA having exceeded more than 1000 global live customers since September 2017, more and more installed base SAP customers are convinced that it is time for them to move to SAP S/4HANA as well.
You might have heard that a system conversion is
not simply a technical upgrade. Correct!
On top of using our technical tooling there are a lot of aspects you need to plan for to be successful with your conversion.
In our S/4HANA Regional Implementation Group (RIG) we have helped many customers, partners and colleagues to be successful with their conversion projects during the last two years. Right
project setup and planning is key to your success.
I will therefore summarize a couple of recommendations based on our lessons learned.
1) Ensure the right skillset for the project
It is crucial to have experts for all required activities staffed onto the project. This includes at the very
minimum:
- A dedicated project manager to plan and track all activities, ideally one on customer side and one on implementation partner side
- A technical basis team knowing about the technical tooling for preparation and execution phases and also able to do HANA DB performance analysis and tuning
- FI/CO and asset accounting application experts with senior expertise who need to prepare the data before the migration
- Logistics application experts with senior expertise particularly in Customer-Vendor Integration and Business Partner configuration / migration as well as for other Logistics topics like MRP and Plant Maintenance
- Developers understanding the Simplification List (1709 version and web-based Simplification Item Catalog), HANA performance tuning and the new ABAP programming model in S/4HANA including OData and CDS
- A UX lead who will be able to understand SAP Fiori, its concept and underlying technology and can help introduce innovations
- An Analytics lead who understands the innovations in embedded analytics and able to introduce them and also help with CDS performance analysis and tuning
2) Prepare and execute the Readiness Check for SAP S/4HANA as early as possible
The
Readiness Check for SAP S/4HANA gives you a first high-level impression about the conversion impact for the customer. You just need to have an SAP Solution Manager 7.1 or 7.2 connected to the old SAP Business Suite System.
The check can be executed
free of charge and will present the results in a dashboard web view detailing:
- Impact regarding Add-ons, Business Functions and deployed Industry Solution
- Sizing estimation
- Deprecated transactions the customer frequently uses in the SAP Business Suite
- Recommended SAP Fiori transactions based on current transaction usage
- Details about Simplification Items relevant for the customer and required functional changes
- Impact on existing custom code extenstions
With the results from the Readiness Check you can do a first project planning iteration, which you will require for getting into a bid or starting the actual project.
Keep in mind that you will still have to run the detailed tooling such as the Simplification Item Checks during the project execution as well to be able to get more detailed results.
There are two possibilities to perform the Readiness Check:
First option: Follow
SAP Note 2290622 if you have a Solution Manager 7.1 SPS 12 or higher or SAP Solution Manager 7.2 SPS 03 or higher.
Second option: If your SAP Solution Manager does not fulfil the prerequisites or due to security reasons there is no open connection from it to the SAP Support Portal, follow the instructions of
SAP Note 2310438.
In addition to the Readiness Check you need to get transparency about possible obsolete legacy extension coding, which might have impact during the conversion, but is not used at all anymore in the customer system.
Therefore, switch on some monitoring as early as possible. The tool of choice is
SCMON, the ABAP Call Monitor, which can analyze your code execution. It is enhanced compared to the previous Usage Procedure Logging (UPL).
Any coding, which is obsolete, should be removed from the system before the Conversion and does not have to be adapted to fit for S/4HANA requirements. You can find more details about Custom Code Management in this
blog.
3) Prepare early for sizing and hardware procurement
The Readiness Check gives you an estimation about the required DB size for S/4HANA based on your current table volumes in your SAP Business Suite system. You might want to have a more detailed look with help of deployment of
SAP Note about Business Suite on HANA and S/4HANA sizing report.
Keep in mind that the sizing estimation caters for your transactional system usage. After conversion to S/4HANA you are going to make use of embedded analytics capabilities, for which you must size on top of it.
This is particularly true for complex features like Business Planning and Consolidation, which you could not run in SAP Business Suite, but can run on SAP S/4HANA.
Also, keep in mind that for many customers Fiori will be introduced as new UX technology. It is recommended to have a separate Frontend Server deployment, which you need to size accordingly.
The
SAP Quicksizer has been updated reflecting metrics for all those scenarios.
The reason we are recommending to procure the hardware early is that you will need to execute some test runs on comparable hardware for fixing inconsistencies, estimating the downtime, etc. Results out of those early tests will determine your next project activities and should happen in due time.
Procurement of hardware often requires a lead time of four to six weeks.
4) Get early transparency of deployed Add-ons / Business Functions and required actions
Make sure to review the Readiness Check results regarding Add-ons and the
SAP Note about Add-On Compatibility early in the project. You can also check the
Partner Certification Directory.
Add-ons deployed to your SAP Business Suite must be compatible with S/4HANA. While there are not many add-ons anymore not compatible, it can be a showstopper for your conversion. If you have a non-compatible add-on, you must either be able to un-deploy it before the conversion or reach out to SAP or SAP partner company for providing an S/4HANA compatible version.
As you can imagine, preparing a compatible version might take some time.
You also need to check for Business Functions and only in exceptional cases can always_off functions be allowed during a conversion. See
SAP Note 2240359 for more details.
5) Copy production to a sandbox, do an early test run and start preparations
It is crucial that you copy your production system early in the project to a sandbox. You can then run a test conversion to see what needs to be fixed on this system. You do so by leveraging the Maintenance Planner,
Simplification Item Check and Custom Code Tooling (
ATC,
SCMON, etc.).
These tools check the system against the Simplification List. This list describes the delta in technology and functionality between SAP Business Suite and SAP S/4HANA. It is essential that
everyone in your project team is aware of it.
While fixing configuration and data on the sandbox, make sure to document all of those changes in a “run book” as you will later have to repeat those steps on the actual development, QA and production systems.
On having done a conversion on the sandbox, you also want to analyze and fix performance issues, which the SQL Monitor can help you with, see the "Performance Tuning" section in
this blog.
Also, consider doing load testing against the sandbox on hardware comparable to production.
You want to find out about performance issues long before golive to be able to fix those and not right before or after golive. This is essential to
ensure user acceptance of the new S/4HANA system.
Also, plan for a second and even a third test run after fixing configuration and data to make sure that there are no further issues encountered on the system.
6) Archive Data before test and actual runs
Make sure that you archive as much data as possible before test and actual conversion run. Like this you are reducing the amount of data to be copied from old to new tables and you are also reducing the amount of data, which might cause issues during the Simplification Item Checks.
This will result in
fewer preparation activities and reduction of downtime.
7) Fixing of Finance inconsistencies
Fixing will typically include sorting out Finance inconsistencies, which is a major project activity, which require very Finance application experts. See
Chapter 3.9 in the Conversion Guide and particularly
SAP Note about Conversion of Accounting to S/4HANA and its
attachment for more details.
Our S/4HANA RIG is also trying to help you with blogs like this one:
Blog S/4Hana ACDOCA Conversion Line Items.
😎 Prepare for Customer/Vendor integration
The usage of the Customer/Vendor integration (CVI) is mandatory with S/4HANA. We have seen in many projects that performing this integration and fixing issues along the way can be very time-consuming.
As such, you need to make sure that you have a very expert on Business Partner and CVI as part of the project with sufficient time assigned for those activities. Issues can occur during synchronization, customizing and with respect to master data quality.
Make sure you always use the latest versions of
SAP Note 2216176 Pre-Conversion Check CVI, the report attached to it and the
Customer/Vendor Integration Cookbook, which is describing what you need to know and which actions have to be taken.
This
blog from our RIG is useful as well.
9) Plan sufficient time for testing of roles and changes in authorizations
With changing data models, deprecated transactions, etc., it is necessary to review your role assignments in transaction PFCG. Have a look at
SAP Note 2465353 about Exchange of Obsolete Transactions in Role Menu as well as chapter 4.3.4 in the
Conversion Guide (1709 version).
10) Re-run Simplification Item Checks in time before the production cutover
While this can vary with different customer situations, out of experience we typically recommend to re-run the Simplification Item Checks on production two weeks before the downtime and continue the business operations those two weeks with the checks completed.
The Software Update Manager uptime activities should typically start one week before the downtime.
This should be tested thoroughly in the quality assurance system or in a dry run on another sandbox copy to ensure a smooth transition on production.
Summary
Right resource staffing and intensive testing are keys for your conversion success. Make sure that you are assigning
sufficient time for all activities in your project planning.
Also, customers really get most out of their new S/4HANA system by leveraging new innovations through Fiori applications and embedded analytics. Make sure that you roll out at least some Fiori apps with the initial go-live on S/4HANA.
For innovation adoption one of my RIG colleagues also wrote a
blog for you. Additionally, have a look at our
Fiori lighthouse scenarios.
Brought to you by the S/4HANA RIG