Your organization has just bought a new company and you need to plan an SAP rollout for it to integrate it into the corporate system? But is it worth doing it now when a migration to S/4 is on the horizon? Which comes first? A rollout or a migration? Or perhaps something else? We present three scenarios of how to proceed in this case. We discuss the benefits and limitations associated with them.

The landscape of IT systems in an enterprise changes at least once every few years. On the technical side, this is due to the emergence of new versions of systems; for example, we plan an upgrade of SAP ERP to the next Enhancement Package (EhP) or conversion to S/4HANA. On the organizational side – enterprises are getting bigger as a result of acquiring other companies or carve out parts of the business for a new owner (the so-called carve-out project). At the same time, amid these changes, organizations are striving to standardize their IT solutions.

The use of the ERP system in the same version and with a similar configuration in all companies in the corporate group reduces maintenance costs. It is then easier to consolidate and analyze business data, and it is easier to operate and monitor a unified technology platform. This is especially important for the operation of shared service centers – financial, HR and IT.

Even if a group of companies already uses a uniform SAP system, when a new entity joins (acquisition of another company or establishment of a new company), we face the need to carry out a rollout project. This means transferring the SAP model solution of the group to the new company. In other words: we add another part of the organization to a common IT environment.

Companies currently using an SAP ECC 6.0 system are also faced with the need to plan a conversion to the new version of the system – S/4HANA. This new generation of ERP solutions from SAP is already the default version recommended for new implementations and provides numerous improvements compared to ECC 6.0. However, in the context of planning a rollout project, the decision is no longer so obvious: should we first integrate the new company into the existing ECC 6.0 system of the group, or convert the current installation to S/4 beforehand?

Below, we will consider three scenarios, along with the benefits and rationale for choosing each of them:

  1. Conversion to S/4 followed by rollout to a new company;
  2. Rollout to a new company followed by conversion of the entire installation to S/4;
  3. Use of a new company as a pilot implementation of S/4 in the group.

For all scenarios, we assume the same starting conditions:

  • Let’s assume that the group consists of three companies (A, B, C) already running a uniform SAP ECC 6.0 system;
  • Our task is to add the fourth company (D) to this SAP environment.

Scenario 1. Conversion to S/4 followed by rollout

The transition from SAP ECC 6.0 to S/4HANA is a bigger undertaking than the SAP ERP upgrades we’ve seen so far (e.g., from version 4.x to 6.0 or the higher level of EhP in 6.0). Customizations of the ABAP code (custom development), interfaces, user manuals are necessary to a greater extent and take more time compared to previous system version changes.

The duration of most tasks in a conversion project will be proportionate to the complexity of the system. It depends on the size of the database (technical activities in the project), the number of organizational units (how many variants of the test scenarios we have to perform), the number of system users and the functions they use (how many instructions need to be updated).

Based on a purely mathematical calculation, the answer is clear: we will minimize the total workload in the project if we first make the conversion of the existing ECC 6.0 system to S/4 (for companies A, B, C) and only then carry out the rollout to the fourth company.

Migration to S/4 vs rollout 1

Scenario 1. Conversion to S/4 followed by rollout

This is due to the following dependencies:

  • the project of converting a “smaller" system (including 3 companies) to S/4 will always be slightly shorter and easier than the conversion of a “larger" system (4 companies),
  • the rollout of the S/4 system to the new company will take the same amount of time or less (if it turns out that the functionality available only in the new version, e.g. embedded analytics, will help meet the needs of the new company in S/4 easier than in ECC 6.0) than the rollout of the ECC 6.0 system,
  • in this scenario, there will be only one system change for company D (i.e., the legacy system to S/4), instead of two changes (first to ECC 6.0 and shortly thereafter to S/4).

In fact, the only weakness of this approach is the duration of the conversion project (which precedes the rollout project). If the priority for our group’s management is to integrate the new company into a uniform SAP environment within the next 12 months, we should consider scenario 2.

Scenario 2. Rollout followed by conversion to S/4

The duration of the ECC 6.0 to S/4 conversion project is in practice difficult to reduce to less than 5-6 months. For large, complex installations using multiple processes, with numerous customizations (custom development) and interfaces, we should expect a longer project lasting up to 12 months.

So if, for business reasons, we urgently need to integrate a new company into a common SAP solution (e.g. so that in the next financial year the whole group already reports data from one system), we should plan a rollout project first. This is undoubtedly the shortest way to cover the entire group with a uniform SAP system.

Migration to S/4 vs rollout

Scenario 2. Rollout followed by conversion to S/4

We should remember that by proceeding in this way, we incur a certain “technical debt": we create a larger, more complex landscape of ECC 6.0 systems awaiting conversion to S/4HANA. So, we should not stop the implementation of scenario 2 halfway (after the rollout) and postpone its second part, i.e. the conversion to S/4HANA! This undertaking will be inevitable in the next few years anyway. So it is better to perform it as soon as the upcoming rollout project is completed and stabilized. Otherwise, before we plan the conversion… our organization may face the need to implement another business reorganization project that will interfere with other IT projects.

If the organization is changing dynamically and we can’t find a convenient time for a technical project of conversion to S/4HANA in a stable environment, we should consider another possible approach described below.

Scenario 3. A new company as a conversion pilot and a rollout “in the other direction”

In large organizations that have been using the ECC 6.0 system for several years, the project of converting to S/4 is sometimes postponed many times. This is due to concerns about the impact of the system change on current business processes – e.g. whether all development customizations and interfaces that we have added to the system during its long history will be seamlessly migrated to the new version.

In such a situation, the rollout project can become a good opportunity to introduce S/4HANA to our system landscape. The implementation of the new version of the system at first only in a new company has several advantages:

  • we introduce S/4HANA to the IT landscape of the group of companies gradually, alleviating concerns about a large-scale conversion carried out in one step,
  • the SAP system will be implemented in the new company in a relatively short period of time,
  • although we do not obtain a single central SAP environment in the group at this point, we can standardize business processes, a chart of accounts, master data numbering, etc. in company D during this project – so as to facilitate common reporting and consolidation of data across the group.
Migration to S/4 vs rollout

Scenario 3. A new company as a conversion pilot and a rollout “in the other direction”

The next stage of the project planned in this way is a rollout, but done… in the other direction, i.e. we move the solution to companies A, B, C. Such a rollout can be carried out in a single step or gradually. Depending on the experience gained by the organization (especially by the IT department) during the project in company D, we can decide on the pace at which the rest of the organization migrates to S/4HANA.


We presented three variants of planning rollout projects in the context of the upcoming SAP ECC 6.0 conversion to S/4HANA.

The first scenario allows us to minimize the workload (thus also costs) required by the entire sequence of projects. It is the most rational choice if we can afford some flexibility in planning the work schedule.

The second option will enable us to achieve a uniform SAP solution (the ECC 6.0 version) in the entire group of companies in the shortest time. We should apply it if the absolute priority is to standardize the landscape of SAP systems in the entire group within no more than 12 months.

The third scenario will allow us to try out a version of S/4HANA in a new company without affecting the functioning of the rest of the organization. This may be the optimal approach in the case of very extensive SAP installations developed for several years, with a large number of customizations and interfaces. It will help overcome the organization’s resistance to change and start modernizing the system landscape.