Skip to Content


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

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

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?


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

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.

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 data model (inculding e.g. phrases) in both systems.

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” of meta data). This is now 80% of the work as we do not have any kind of SAP tool to support. Therefore: this is quite customer specific. But if you suceed: you will create e.g:





stuff quite easily either using EHS import or the 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)

You need to decide by your own if you would like to migrate released WWI reports.

Acquisition of a new company

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.

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.).


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


What are the options to migrate?


What are the challenges in migration?





To report this post you need to login first.


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.



    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.



Leave a Reply