Conversion to S/4: sort out terms, explore scenarios

In most companies, the development of IT systems looks similar. Here’s a typical cycle: a few years ago, a company implemented an SAP ERP system along with the development of dedicated reports, interfaces, workflow processes. Among the dozens of additional programs, there is a specific sales report. After some time, a new version of this report was created with a different column layout. Later, a modified version, including a quarterly summary, was prepared for management. After a year, the company’s regional structure changed, and the report needed to be adjusted again. As a result of standard business operations, two years after the original report was launched, six versions of the report are already in operation.

The team responsible for SAP maintenance in the organization should review programs, transactions, and interfaces. It should remove unused objects and then update the documentation. The system should be transparent and easy to maintain. This is what happens in… an ideal world. In practice, the situation is usually different: the complexity of the systems is constantly increasing, and this in turn makes it difficult to support users on an ongoing basis.

The problems outlined above using a single customer system as an example also apply – on a much larger scale – to the development and maintenance of the entire standard ERP system by SAP. Over the years, new features, transactions, database tables, and even completely new technologies (e.g., different approaches to creating web browser UIs, SOAP/web services, and, more recently, AI) have been emerging. At the same time, the system manufacturer has maintained a very high degree of compatibility with earlier versions. This can be confirmed by companies that have been using the system since the 1990s, successively developing it and upgrading versions, and their SAP continues to process all operations smoothly.

Since its inception, SAP has recorded several important milestones in the development of functionality, which involved the release of new versions and upgrade projects for customers. In 2005, the approach to new releases of the ECC 6.0 system changed to a more evolutionary model – publishing enhancement packages (EhP). The latest enhancement package, EhP 8, released in 2016, ensures system support until 2027, with an option for extension until 2030 for an additional fee.  This represents an exceptionally long lifecycle for an IT system.

Simultaneously, in 2015, SAP began offering a new generation of its flagship system – S/4HANA.  It maintains a high degree of compatibility with SAP ECC while also introducing innovations and eliminating the baggage of legacy technologies.  The current version of S/4 was released in 2023, and the next major release is announced for 2025. Additionally, feature packs with minor functional extensions and legal changes are published every six months.

To emphasize the complexity of migrating from SAP ERP to S/4HANA, the manufacturer calls the process a conversion (instead of: upgrade). And the term “update” is reserved for the installation of new feature packs.

In addition to introducing new features in S/4, the manufacturer has also made significant cleanups by removing functions that were duplicated or rarely used by customers. To emphasize the intention of “simplifying the system," SAP named the catalog of differences between ECC and S/4: simplification items (SI). Each SI entry is described in detail, depending on the version of the system, along with references to SAP notes and instructions for each case.

We can distinguish several main types of simplification items:

• Changes to existing functions. For example, lengthening material identifiers from 18 characters in ECC to 40 in S/4 due to the needs of certain industries (such as automotive). After the conversion, standard programs and data structures in the system will be adapted to the new field length. However, in-house ABAP development or interfaces can be an obstacle to automatic conversion. The corresponding item simplification provides customers and consultants with precise instructions for handling this change.
• Consolidations of functions in S/4. Here an example is the simplification of the financial data model in Universal Journal. The addition of the central ACDOCA table, which contains all financial document line items, has rendered many other tables that stored redundant data – solely for the purpose of increasing the performance of older databases – no longer necessary. In this case as well, standard SAP programs and data structures will be adjusted during the conversion. However, complications may arise in the development that read data from these tables and manual adjustments may be required.
• Removal of functions in the new version. In SAP ECC, it was possible, for example, to configure MRP controlling parameters at three levels: plant, MRP area, and storage location. In S/4, this redundant solution has been simplified. We can configure MRP area covering only one storage location, therefore the ability to set MRP parameters also at the storage location level is not needed. If we have used this option before, the master data and custom development, if any, need to be adjusted. Another functionality absent in S/4 was Sales Activities / Sales Support. This was a simple “mini-CRM” solution built into ECC 6.0 for customer relationship management. Companies that used these functions must now find alternatives, such as SAP Cloud for Customer.

For certain functions being phased out, the manufacturer has allowed time for migration to new equivalents in the S/4HANA version. For instance, the recommended alternative for the Logistics Execution Transportation (LE-TRA) is Transportation Management. For this type of migration to newer features, SAP provides transitional solutions known as compatibility packs. They allow for continued use of older key features of the system after the conversion, but only for a limited time. Most of them will be deactivated by the end of 2025. The exceptions are three major compatibility packs that will remain available in S/4 until 2030. These are:

• LE-TRA,
• Customer Service,
• Production Planning for Process Industry (PP-PI).

This approach allows, and even necessitates, planning the technical conversion for the near future, while the business changes related to these three areas can be deferred to a more convenient time.

In the classic SAP system upgrade, we sequentially migrated the development, test and finally production systems. Due to the importance and complexity of the conversion to S/4, the manufacturer now recommends a slightly more extensive sequence of activities.

In addition to the standard landscape and transport path, we should establish an additional test system, the so-called Sandbox (1 in the diagram below). It will allow for practicing the conversion without impacting the ongoing system landscape operation, current transports, and development. The next step in the project can involve creating a copy of the development system and converting it (2 in the diagram). Then, the second test system is established as a copy of the production system and is also converted (3 in the diagram).

This approach requires more resources. The original landscape, which consisted of three systems, gave rise to six, with three of them being copies of the production system. The advantage of this slightly more costly approach is that it preserves the original transport path and the entire landscape of development, test, and production systems intact. This ensures that our system – and business – remains resilient to surprises or changes in plans during the project of transition to the new version.

In the next step, the production system is converted (4 in the diagram), and the “new" development and test systems, previously created as copies, are also retained (5). The remaining instances can then be archived (6).

This is the recommended sequence of activities in the system landscape. And what does it look like at the level of a single system? For each of its components, there are various tools available to support the conversion:

• Maintenance Planner – analyzes the current system version (EHP level, add-ons, active business functions) and determines the exact set of target components required to complete the conversion to the specified S/4 version;
• Readiness Check – performs an analysis of the configuration and data in the production system or possibly in a copy of it. Creates an XML file that, once downloaded, can be sent to the Readiness Check tool in SAP Cloud (the file does not contain confidential data). Based on this, the SAP tool can assess which functions are being used and which simplification items will be relevant;
• Custom Code Analysis – evaluates ABAP programs for compatibility with the S/4HANA version – both with changes to the syntax of ABAP and SQL languages, and also checks whether, for example, they contain references to objects removed in the new system version.

Utilizing these three tools should be regarded as a mini-project for analysis prior to the conversion. This will help better estimate the project workload and duration as well as select the approach to the actual project.

Following the analysis, a series of actions related to simplification items must be undertaken. One of the more significant customizations is the launch of the Business Partner functionality, which consolidates records of vendors and customers. This change should be made while still in the SAP ECC version (for more information, see the article titled “Clearing the ground before migrating to S/4,” p. …). We also recommend preliminary customizations to the development environment, such as removing unused programs.

Once the system has been organized, we begin the actual conversion. At the technical level, we use the Software Update Manager (SUM) to install the new version of the server software, new ABAP programs, and new data structures. If standard SAP objects were modified earlier, it is necessary to make customizations using the SPDD/SPAU tools. SUM will automatically transfer all transactional data, master data, and configuration to the new S/4 system database. A number of tasks related to simplification items will still need to be completed.

The next important task, known as custom code adaptation, involves customizations that could not be made prior to the conversion. Some changes will be executed automatically (thanks to the new quick fixes feature in the ABAP Development Tools), while other will require intervention by developers.

The result of these efforts is a converted, fully operational S/4 system.

Our experience shows that a typical conversion project using the Brownfield approach – from the initiation of system analysis to go-live and post-go live support – takes about 9 to 12 months.

Greenfield, i.e. reimplementation, system implementation from scratch, is a method for companies interested in doing, on this occasion, a major cleanup of business processes and data (archiving a significant portion of historical data) of previous ECC 6.0 installations.

This type of project begins with a standard installation of the S/4 system. The system can be tailored to the organization’s needs by selecting and activating the SAP Best Practices template processes, which include configuration and Fiori applications. Standard processes will speed up the implementation, but they will not fully cover 100% of the organization’s needs and operational specifics. It will be necessary to define additional requirements, next steps in processes, or entirely new processes, as well as to add specific configurations and development work.

The combination of standard processes and additional requirements will form the system implementation concept. The result of further configuration and development work will be a system ready to be populated with data. Migration Cockpit – a new standard tool in S/4, successor to LSMW – allows for the migration of several dozen typical master data objects from the source system. It is good practice to limit migrated transactional data to the essential minimum: inventory levels, opening balance, and open items so that the new system can smoothly commence production operations.

It is worth noting that in the Brownfield model, transitioning to either the on-premise version or S/4HANA Cloud Private edition is possible.  In the Greenfield model, reimplementation to the S/4HANA Cloud Public edition is also an option.

The third color of migration to S/4 is Bluefield, which is a proprietary approach developed by SNP, a partner of All for One. Bluefield projects (also known as Selective Data Transition) begin with creating a copy of the production system in a so-called empty shell version. This copy includes standard SAP programs, custom development, and the entire client configuration, but it excludes master and transactional data. Next, this “empty” system is converted to the S/4 version using tools employed in the Brownfield approach (SUM, Custom Code Adaptation). Adjustments resulting from simplification items and code changes are then made.

This part of the project is similar to the Brownfield model; however, since it is carried out on a copy, it does not disrupt the ongoing operations of the production system. All activities are performed with a virtually empty database, which means they do not take much time.

The transfer of master and transaction data is done using dedicated tools (CrystalBridge data transformation platform). It is worth noting that during the data transfer between the source and the target system, we have a range of additional options for filtering and modifying the data. For example, adding a rule to skip documents older than the indicated date will allow for obtaining a system that has a history of transaction data within a reasonable time frame. Older data will be excluded, which helps to drastically reduce the size of the database. Another example of filtering is the omission of some data by organizational structure (if, for example, the system stores data from companies or plants that no longer exist). These tools can also be used for cleaning and reorganizing data (e.g., removing duplicate contractors, renumbering cost centers, or chart of accounts).

The duration of a Bluefield project is comparable to that of a Brownfield project (or shorter if we transfer less data). It is associated with the need to purchase licenses for the CrystalBridge software. The advantage of this approach – similar to Greenfield – is the possibility of reorganizing data; however, this can be achieved in a significantly shorter time frame and with a relatively lower budget compared to a full reimplementation.

Instead of a summary, let’s gather the most important factors that influence the project plan:

• The functional scope of the currently used system directly affects the number of simplification items and compatibility packs that will be relevant for the migration;
• Custom development, specifically the number and scope of ABAP code customizations necessary for the proper functioning of the system;
• Infrastructure: the number of systems in the landscape and the decision of whether to migrate to the cloud simultaneously with the transition to S/4HANA;
• Business requirements: expected (or not) functionality changes;
• Business constraints, such as the availability of key users for testing, limitations regarding the timing and duration of the production system downtime;
• Other concurrently planned projects, such as transitioning from SAP HCM to SuccessFactors, implementing a data warehouse in the cloud, moving from Process Integration/Process Orchestration to SAP Integration Suite;
• Other conditions arising from the company’s strategic plans for IT/SAP infrastructure development.