SAP S/4HANA Conversion experts agree that SAP ECC system conversions pose the greatest risk, while there is a common misconception it is simply Data Migration and moving data from non-HANA databases to HANA databases. In some cases, companies take the view that it is an unnecessary investment and activity. In a few cases, it could, in fact, be the opposite; Companies may spend more, assuming more risk than is necessary to perform SAP ECC system conversions. Complication factors and risk factors vary from system to System. Conversion Consultants, who have the required experience, greatly reduce conversion cost and risk as well as being able to help migrate data from ECC systems to SAP S/4 HANA in a non-disruptive manner.
In S4, these status and index tables are entirely removed, and many master and transaction tables are combined to few. They use in-memory columnar architecture, where the fetching of data is very fast and the calculations are done on the fly, making the need for status and index tables to nil.
So, migration of data happens only for the master and the transaction data, thus 100% quality in data migration quality is a sure possibility.
Now coming to the removal of the status and the index tables. These will affect a lot of custom programs present. Adjusting all custom programs with a new set of tables will take years to migrate. SAP approached this by providing a lot of CDS views as a replacement to the old ECC tables reducing the migration period drastically.
In S4, these status and index tables are entirely removed, and many master and transaction tables are combined to few. They use in-memory columnar architecture, where the fetching of data is very fast and the calculations are done on the fly, making the need for status and index tables to nil.
So, migration of data happens only for the master and the transaction data, thus 100% quality in data migration quality is a sure possibility.
Now coming to the removal of the status and the index tables. These will affect a lot of custom programs present. Adjusting all custom programs with a new set of tables will take years to migrate. SAP approached this by providing a lot of CDS views as a replacement to the old ECC tables reducing the migration period drastically.
Explaining in-memory columnar architecture:
In-memory means RAM storage. In ECC, files are stored on the hard drive of the server. In S4, RAM is used instead. Therefore improving the performance.
Columnar means column-based data storage.
Let us go by the below example to understand.
We have a table with 4 records.
ECC uses row-based storage, meaning each row is stored as a file. If we have 10 records, we’ll have 10 files.
S4 uses column-based data storage. Meaning
All table field data (columns) are stored in a file, so there are 3 fields and 3 files. Data are retrieved using indexes, an array concept.
System Conversions may be hard but planning and preparing for it doesn’t have to be. The preparation phase is the most important area for success. Planning for Conversion tasks in each phase of Conversion projects is essential. It involves technical preparation, functional preparation as well as analyzing the data in the source system.
Technical consultants will verify system requirements for conversion, supported start releases, Unicode or non-Unicode, SAP ERP Java components, Data Volume, Custom code etc…
Basis Consultants will do the necessary preparation to execute a Maintenance Planner to do the conversion to SAP S/4 HANA, to verify Add-ons to your system, to verify Active business functions in your system and Industry solutions etc… The Basis Team will install the necessary Simplification item check relevant notes. The SI-Check is delivered with SAP Notes 2399707 and 2502552. SAP Note 2399707 delivers the new check report; SAP Note 2502552 delivers the check classes via transport-based correction instructions (TCI) and prerequisite notes.
But we are getting ahead of ourselves – before talking about how the migration can be done, it is prudent to discuss how data should be prepared for the migration. Broadly, the data in your current environment can be classified into the following buckets:
- Good quality data which must be migrated to the new transactional system,
- Good quality data should be retained for analytical and/or auditing requirements.
- Poor quality data must be migrated to the new transactional system,
- Poor quality data should be retained for analytical and/or auditing requirements.
- Data which is no longer required.
In this article, we are focusing on data that must be migrated to the new SAP S/4HANA transactional system – represented by buckets 1 and 3 above. So, before we move on (and after discarding bucket 5), what options do we have for buckets 2 & 4? Following could be considered:
- Use of corporate memory concept with analytical capabilities of SAP HANA and/or SAP BW (on HANA or BW/4HANA) combined with data management and tiering capabilities like Data Tiering Optimization, Native Storage Extension, Near-Line Storage, Dynamic Tiering and integration with Hadoop or other repositories.
- Use of SAP Information Lifecycle Management (ILM) and the retention warehouse – refer to n essence, what you should have in place prior to undertaking major migration project should be a strategy or at least a vision for all kinds of information your organization manages. If you aren’t sure where to start, check the blog on Information Governance Model.
What are we going to achieve with this?
A scenario for the above example; to calculate total in sales, ECC would need to read 4 files whereas S4 would just need a single file. Consider such a case with a huge data set, we can imagine the amount of time both the systems would take. The difference would be huge.
Another scenario, reading a whole table with a huge data set, here again, the time that both the system takes will be entirely different. S4 will be requiring to read ‘column-count’ number of files whereas ECC will need to read the ‘record count’ number of files. In reality, a table will not have more than 500 fields of data but will have lakhs and lakhs of data records.
So, starting from the architectural perspective both ECC and S4 HANA are very different. In ECC, a record is stored as a file in the hard drive whereas, in S4, an entire field data is stored as a file in the RAM.
