Switch to SAP S/4HANA via a conversion pre-project

Many companies are currently grappling with the question of the best way to switch to S/4HANA by 2027. The best way is certainly different for each company. In this blog article, we look at the technical implementation of brownfield conversion.

With an S/4HANA conversion (also known as a brownfield approach), you can get to S/4HANA very quickly with the right framework conditions. In contrast, with greenfield projects, you start from scratch by redefining your processes on empty S/4HANA systems.

Project scope in the SAP S/4HANA Conversion preliminary project

We are currently supporting a brownfield customer project in which the SAP ERP Business Suite landscape is being updated to S/4HANA 2022 using S/4HANA Conversion. The customer’s systems are very close to the SAP standard and are easily manageable in terms of scope, which is why the conversion approach is preferred here. The tight timeframe is necessary to complete the conversion before a future SAP rollout in other countries. The aim is to convert the system “as-is” and only make the minimum necessary adjustments, such as the mandatory replacement of various FI transactions with Fiori apps.

In order to identify potential pitfalls at an early stage, sandboxes were created on which a test conversion was to be carried out. The two sandbox systems were set up in the cloud at AWS by SPIRIT/21 and are also operated there by us.

We then prepared, accompanied and carried out the conversion on the technical side at SPIRIT/21.

In addition, the customer must also update their existing HANA systems from SLES 12 SP5 to SLES 15 SP4 in advance, as only this version is approved as the OS for the HANA databases. This was different for ERP 6.0.

The conversion is then started via SUM and largely behaves very similarly to a “normal” upgrade of an SAP system. A lot of time had to be spent in the sandbox, especially with the add-ons, as the 3rd party manufacturers were unable to deliver a solution quickly enough. It took about three weeks until all add-ons were “ready”. A detailed analysis should be carried out in advance and the providers contacted.

The actual technical conversion then ran almost smoothly and the sandbox was converted in just a few hours.

Post-Processing / Downtime Optimization in the SAP S/4HANA Transformation

The so-called Silent Data Migrations (2907976 - Silent Data Migration (SDMI) - FAQ) then run afterwards. Here, application data is migrated automatically. You have the choice of doing this during the downtime or afterwards. This enabled us to save several hours of downtime.

In collaboration with the customer, the launchpad was then configured using Fiori Rapid Activation and the first apps were set up for the FI area.

To summarize, here are some important points that were taken away from this first conversion:

• Add-ons should be checked for compatibility at an early stage
• Forward-looking planning for APO / SCM is necessary if in use
• Skip default security profile parameters and adjust them later, as they are very restrictive
• Silent data migration can save many hours of downtime
• Check NSE (Native Storage Extension) on the HANA side afterwards, as this is automatically activated with the conversion.
• The customer is currently evaluating the converted sandbox system to decide whether we can continue directly in the productive landscape.