Skip to Content

Introduction

First I would like to discuss/explain on these questions:

In which situation you need to “migrate” data to EHS classic?

Let us first define EHS classic: more or less this is modue SAP EHS-BD (EHS-SAF, EHS-DGM, Maybe you can add GLM as well).

  • What data is to be moved/migrated

  • What are the options to migrate?

  • What are the challenges in migration?

You should consider as well questions as: What approaches are used by “SAP” and other companies (project types; methodologies etc.)

Can I benefit from these approaches?

etc.

Answer: First question “In which situation you need to “migrate” data to EHS classic?”

Potential answers are:

1.) you are trying to consolidate your SAP landscape

2.) you have acquired a company and you need to migrate the data in your SAP system

3.) you would like to get rid of old legacy systems and move the existing data to SAP

4.) if we include the topic of so called “Carev Out” projects: Migration can have the meaning of “export” as well

Let us take a look now on “detail”:

Consolidation of SAP landscape

Here in most cases you use either at least two clients in the same SAP system or you use two SAP systems. In most cases: there is no data exchange done yet between the systems. So any of the “clients” or “Systems” contains some data, which is not the same as in comparison to a different client or system. On the top: may be you use “SERC” service in one SAP client but not in the other SAP system.

What can be different? What is the different between two SAP systems?

E.g. used phrases can be different (including the fact that the translations of phrase texts are different etc.), customizing set up (property tree, identifier set up etc.), UOMs can be different, etc.

The first step in consolidation is: you need to decide which SAP system will be used in future (new target system) and which SAP system will be stopped for use (source system of data). Luckily: you have two SAP systems to consider. Therefore: you have (HOPEFULLY !! This is an assumption you must check !!) the same basc EHS framwork.

The specific roadmap to use for data migration depends on the used modules. In most cases:

The “core”modules are used (e.g. to support MSDS/SDS generation, dangerous goods management, SVT, GLM).

Therefore. if you would like to migrate you need to check for:

  1. Customizing differences (different identifiers, property tree etc. etc.)

  2. Phrases (are they different)

  3. WWI landscape (what need to be adapted(

  4. etc

Now what is a “good” approach to start migration? There is no easy answer.

But if you start to migrate phrases, and if you take care regarding “customizing” differences, you have done a good job.

But what will come next? What you can do easily: you can “download” the data from source system (EHS Export). But in > 80% of the cases you can not upload the data in target system without “adaption” of the data (which is called “mapping”/”Transformation” of  data). This is now 80% of the work as we do not have any kind of SAP tool to support the mapping process. Therefore: this is quite customer specific. But if you succeed: you will create e.g:

REAL_SUB

PURE_SUB

LIST_SUB

DGL_CL_SUB etc.

stuff quite easily either using EHS import or the you can upload data using EHS OCC

BUT KEEP IN MIND: you need to consider “Material Topics” a well (e.g. Label View and other stuff which is maintained on Material number level). This is related to EHS; but it is on material level

You need to decide by your own if you would like to migrate released WWI reports. But if you have migrated the data: you can just regenerate the relevant reports once again.

Acquisition of a new company

If you acquire a company using SAP and using EHS: then you are in a good starting position. More or less you have the same options to migrate the data as listed before.

There is a good chance that there is no “SAP” system. If you are lucky then you can extract data using e.g. an “EXCEL” format. A big challenge is to understand the “source data structure” to plan the migration. To analyse and prepare the source data to migrate is the highest effort you can think of. But at least: you must as well define the target scenario in your SAP system. As we have to many source systems to discuss: this is a very specific project having many risks to consider.

For the IT part:

Phrases: you can use standard import or the SAP EHS OCC option

Specification:  you can use standard import or the SAP EHS OCC option

DG data: in most cases you just regenerate the DG or HS master after migrating the “spec” data.

Removal of old legacy systems

Here nearly the same challenges can be listed as before. The only difference (luckily) is: you know very well your old systems and the options to extract data.

But as well: you need to consider a huge amount of work for “mapping” (old data structure to new data structure). It is as well a good idea to do the migration (if possible) step by step (e.g. start with phrases etc.).

Conclusion

Most of the work to consider is done in relation of “mapping” (source system data structures <=> target system data structures ), defining the “target structures” (do you need nw customizing?), what need to be migrated (from source system), in which sequence should the migration be done? How to train the new users (in SAP)?

As EHS is directly linked to SAP MM: you can start the migration only of you have good competencies (link of MM to EHS) in SAP MM as well. The effort involved depends clearly on the “modules” of interest (e.g. EHS-BD, EHS-SAF, etc.)

What data is to be moved/migrated

TODO

What are the options to migrate?

TODO

What are the challenges in migration?

 TODO

Links

https://blogs.sap.com/2017/07/01/occ-load-options/

 

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Mark Pfister

    Hi Christoph,

    Great blog!

    One thing you could include:
    For a SAP System -> SAP System migration / carve-out one can use ALE as well.
    This works quite nice and – if needed – conversions could be build right into the inbound or outbound IDOC processing as well….

    Another important point in my experience is this:
    Data Migration in EHS is always a data cleaning exercise as well! The  source systems (especially the non SAP ones) – in my experience – aren’t that great in terms of data consistency / correctness. So in most cases you need to correct / clean the data before migrating it.

    Best

    Mark

    (0) 
    1. Christoph Bergemann Post author

      Dear Mark

      many thanks for your  valuable feedback

      1.) for ALE part: we never used this option; But it is an option. May be you can share some “high level idea” what your “Best Practise” has been

      2.) the “data cleansing/enrichment” etc. part is the “biggest part” of such project. I can fully support here your feedback. Bute we have to differentiate this topica little bit

      a.) the “mapping” process

      b.) and the “data clean up/enrichment” etc. process (after load)

      The “success” of the mapping process depends on knowlegde of people doing the job; the success therefore depnds on “who is acting”. But even if you have some”success”:in most cases yo do a “UAT” validation of data. And here: you can improve mapping. But once again: to do so: you need people with the “right” exprience. The “overall” risk of such process is the “data  amount”. According to my experience. this topics is not considered well in such projects. In most cases the “business” is validating may be 1% (somehow at max) the data migrated. MOst of the issues” are only dectected by business after “go live” load

      BUt i assume that you can as well write a “book” regarding your experience indata migration projects.

      C.B.

      (0) 

Leave a Reply