As organisations no longer face time pressure to migrate to S/4HANA, they should take the opportunity to plan their migration strategies around business benefits and return on investment (ROI), part of which should be moving their data archiving and historisation plans up the priority list.

This comes as SAP recently announced it will provide maintenance support for core applications of SAP Business Suite 7 software until the end of 2027 – with optional extended maintenance until the end of 2030, which pushes the original deadline back from 2025.

Enterprises that do not have a smart archiving or historisation plan, especially if they have a large footprint and many years’ worth of data, can find that this creates a stumbling block during migration. Part of the challenge is that the S/4HANA table structure is significantly different from the SAP ECC6 table structure and, if an enterprise has many years of data that it wants to move, things can get a little tricky.

It therefore requires a fair amount of work and lot of planning upfront to ensure the preparation for data migration and achieving is done correctly, especially for organisations with massive amounts of data. While SAP understands this and has made provision for certain tools that aid with this process, it is still not that simple. If an organisation has bespoke tables, which they built themselves, or tables with data that is typically not housed within SAP, or across multiple applications, the migration to S/4HANA becomes more complex.

One of the biggest considerations is that in SAP ECC6, there are multiple ledgers, whereas in S/4HANA there is a universal ledger that replaces the multiple ledgers. All financial data is now kept in the universal ledger, meaning a significant reduction in subtotal and aggregate tables, this requiring careful consideration when mapping and consolidation data in preparation for migration.

The problem with data archiving and historisation is that storing data has become reasonably affordable, so enterprises tend to keep quite a lot of history. On the other hand, it is hugely expensive to migrate all this data. From a legal perspective, enterprises are required to keep certain portions of their data operational, while everything outside of this should/could be archived or historised.

There are two things to keep in mind – the migration of data as opposed to the historisation of data. When you migrate and achieve your data into S/4HANA, it becomes part of the functional operation and can be reviewed. When you historise it, you have applications that enable you to put that data aside so that you can review it, but not perform any transactional functions on it (it is merely an image of the transaction/data).

Part of the challenge is to know what to migrate and what to historise. This requires a lot of effort, yet typically this is not one of the first things that enterprises consider when planning their migration to S/4HANA, and often does not get enough attention. In the event of migrating to S/4HANA, the migration of data really needs to be way up front in the project plan.

The good news is that enterprises do not have to do this alone. Implementation partners, in conjunction with SAP, have developed tools that enables the smooth clean-up of history and the migration of data to S/4HANA.

This means we do not have to reinvent the wheel every time we tackle data migration and historisation, but can apply tried and tested tools that have been used globally in various migrations. If organisations work with a partner that has done this globally, data migration is not merely an afterthought, but an integral part of the S/4HANA planning strategy.