The support period for the SAP ERP system is ending.  The following arguments may help in answering the question of when to make a decision to migrate:

  • SAP S/4HANA is a very efficient, modern and flexible business management system;
  • no migration to the new version means the use of older technologies that will eventually cease to function; faster migration means faster effects of using new technologies, which is often a real competitive advantage;
  • there is already a shortage of SAP specialists on the market; estimates and studies show that as the year 2027 approaches, these shortages will be bigger, thus it will be more difficult and expensive for those who wait until the last minute;
  • failure to complete the process of migration to SAP S/4HANA before the end of the official maintenance of older versions by SAP entails a risk of working with a system not supported by the manufacturer or even higher maintenance costs (e.g. additional more expensive SAP maintenance);
  • some may hope that SAP will extend support for older versions (sometimes it did it before), but now the “critical mass" has been exceeded and there is no turning back from S/4; extending support now is no longer profitable for SAP.

S/4 options for migrating companies

What about the location of the system? Should you develop your own hardware platform or consider migrating to the cloud?

New S/4HANA installations are most often already implemented in the RISE with SAP model (SAP-provided private cloud based on global cloud providers such as Azure, Google, AWS and Alibaba, for example). Undoubtedly, the advantage of such a model is the provision of a wide-ranging solution by SAP. However, even in this case, especially for customers without an experienced SAP Technology team, the support provided by an experienced partner with such expertise (e.g. SAP Managed Services at All for One) is essential.

For the migration of existing installations, we have different maintenance models to choose from:

So much information has already been published on the selection of the target maintenance model that customers usually have specific preferences. In other cases, it is best to take advantage of the knowledge of an experienced partner and work out the best model together with them, taking into account the profile of the business, development plans for the next few years, location options, telecommunications links, etc.

Migrations to S/4 and to the cloud – together or separately?

If the decision has been made to ultimately maintain the system in a cloud model, all that remains is to plan the migration. Now let’s consider whether it is a good idea to run the migration to SAP S/4HANA and the migration to the cloud in parallel. Or is it better to separate these two projects?

There is no one-size-fits-all prescription here. There are several factors to consider. The most important are:

  • customer expectations (including solution delivery time);
  • the size of the system;
  • whether system configuration changes are planned;
  • whether we will use the standard Greenfield option in the migration (migration through a new installation and implementation) or Brownfield (migration with all data, without major changes); it is also possible to use the Bluefield method (migration of selected data along with functional changes);
  • the state of the current hardware platform: are its resources sufficient to carry out certain preparatory steps? If not, it seems reasonable to first migrate to the cloud and then update the system as a second step.

Partners, including All for One Poland, point out to customers the advantages of cloud solutions. We can extend resources periodically and pay for them only for the time necessary to run the migration or upgrade itself. Once the migration process is complete, we optimize the system so that it is reasonably efficient, but uses as few resources as possible, which will help reduce maintenance costs. It is difficult to achieve such flexibility by relying on on-premise installations without oversizing them, which in the long run comes down to buying a platform that is not used optimally most of the time.