Skip to Content

Data migration in EHS classic


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 module 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?


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”:

What data is (or must be) in focus?

Looking on the SAP EHS standard data model we have to consder these data objects as part of scuh a migration:


– potentially REAL_GRP data

– LIST_SUB data

– PURE_SUB data

– DG data (DG_CL_SUB and corresponding sub objects)

– Link MM to EHS (REAL_SUB does have a material assignment)

– phrases

– potentially legal content

Depending on the scenario: you should add the topic of WWI reports (and/or inbound reports) as well to be migrated.

Consolidation of SAP landscape

Here we can have many subscenarios. Typically are these scenarios:

– You are using at least two seperate SAP ERP installations

– You are using one SAP ERP installation withat least two clients

Scenario 1:

The “Best practise” to be used dependson this question:

Is there an ALE data exchange between the systems?

If answer is “Yes” you can assume that customizing set up is similar. If answer is “No” you can assume that there are differences in setp

Scenario 2:

Here the question is. is there a data exchange existing via ALE between the clients. Based on the answer the same challenges can be seen as in Scenario 1

But in many 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:




DG_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” as 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

On top: you need to decide: how to handle the SDS/MSDS dispatchment (as we can assume that in both systems/clienst a SDS/MSDS dispatchment is used).

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.

The main challenge in this data migration is: there is no “mapping” tool provided by SAP. You can “Export” and “Import” the data. But if e.g. customizing is different: there is no tool available to do that,

If you try to use “ALE” for data migration: the same is true.

You can try to handle the data mapping using ABAP environment or any “tool” you can think about to map/transform data. But it is not an easy job.

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


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

As explained above:  we have REAL_SUB etc. To load data for REAL_Sub you need first “component” data (e.g. PURE_SUB/LIST_SUB etc.).  Therefore most of the work is “mapping”. E.g. CAS number 50-00-0 can have spec key “A” in the source system but “B” in the target system. So for any compositition/spec listing etc. you must make sure that you can map on “B” (if “A” was used in source system)

What are the options to migrate?

As mentioned: you can use standard export/import options; you can use “OCC” and you can use “ALE”. But most of the work is not the “technical” part (not easy anyhow) but the mapping and to do the migration in the right sequence.

What are the challenges in migration?

Mapping of any kind is a challenge. On the top: as SAP is not providing any “tool” or “methodolgy” to work on the mapping: it is your job to look for solutions to do the mapping and to apply it (for all the data). Keep in mind. even for small companies you can assume that at least 10.000 REAL_SUB might exist.




You must be Logged on to comment or reply to a post.
  • 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.



    • 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. But we have to differentiate this topic a 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 knowledge 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.