Skip to Content
Personal Insights
Author's profile photo Christoph Bergemann

Data migration in EHS classic


First: happy new year to all of you

Second: 2019 some additional interest have been seen in the area of “Data migration”. Therefore: some update of this document seems to be needed

Coming back to the primary question as such:

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 (e.g. set up of Label View Data in the material master data segment)).

First you should get answers to these simple questions

  • Why do you have a need to migrate data? (e.g. because you would like to get rid of old legacy system?
  • What data is to be moved/migrated? and is this move to be done in several phases (because of your project plan)?
  • What are the options to migrate?
  • What are the challenges in migration?
  • What about the “Cleansing” part in the migration?

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

and “Can I benefit from these approaches?”


Coming back to the “Cleansing” part… in many cases the data in the “old system” is not in a good shape (becaus of lot of reasons).

It is a good idea to check: can you improve this situation during the migration?

Honestly: in most cases you will not really focus on the cleansing part. You will be lucky to migrate something to get a new system with data and the data can be used in the subsequent process. Data, in this case, can be as well “documents” (e.g. Safety Data Sheets).

Coming back to the questions as such:

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 “Carve 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 consider these data objects as part of such a migration:


– potentially REAL_GRP data

– LIST_SUB data

– PURE_SUB data

– DG data (DG_CL_SUB and corresponding sub objects like LS_UN_SUB)

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

– phrases

– potentially legal content

But the most critical part here is:  you will only ! succeed if you have mapped as well your materials so that all of the newly generated REAL_SUB does have some link to a material. On the top: if GLM is in your focus: you must populate the LabelView; and clearly: your material must be “active” for EHS (environmental indicator in the material master data).

In many cases: a migration will/might happen to a certain extent as well in the area of Substance Volume Tracking; but the approach to use is 100% company specific.

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 with at least two clients

You need to check on top which SAP processes you use (in the old system) or you would like to use in the new system. E.g. sometimes you should ask this question:

  • Do you use different process per “system”? so in one system/client you use BOMBOS but not in the other etc.

Scenario 1:

The “Best practise” to be used depends on 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 setup which you need to consider in the “consolidation” process

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 difference 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 basic EHS framwork.

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

The “core” EHS sub 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

So for the “material part” you need to use other SAP options/tools to load the data

On top: you need to decide: how to handle the SDS/MSDS dispatchment (as we can assume that in both systems/clients 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. So this “mapping” is in most case the most time consumig part; keep in mind: you will do may be a lot of “test loads” in the target system; here SAP does not provide an easy option to “delete” data from “test loads”. This you need to take care by your own.

If you try to use “ALE” for data migration: the same is true. Never have seen somebody using “ALE” to move the data; but in theory: it is possible.

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 which is 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.

Bad news here. You need to “release” the DG data after migraiton (by using some mass action).

For HS Master Data: luckily there is no “release” process in place; so you need “only” to use the ABAP reports to generate the HS Master 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 new 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.


I have now added some threads discussing as well ALE topics

Some recent threads can be listed here discussing “import”/export topics:—import-specificationsphrasesreportsetc—err.html

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mark Pfister
      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.



      Author's profile photo Christoph Bergemann
      Christoph Bergemann
      Blog 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. 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 depends on “who is acting”. But even if you have some ”success”:in most cases you 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 (and whih have enough time to do the job). 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 detected by business after “go live” load

      But i assume that you can as well write a “book” regarding your experience in data migration projects.


      Author's profile photo Christoph Bergemann
      Christoph Bergemann
      Blog Post Author

      Dear Mark

      nether checked in "detail" your feedback as:

      "For a SAP System -> SAP System migration / carve-out one can use ALE as well."

      This option i have never used. In theory you can do it "more complex" like

      SAP System => SAP PI/XI/PO => SAP System

      Using SAP PI/XI/PO you can then "map" data if needed.

      Any how: using this approach you can migrate this data

      1.) substance data

      2.) phrases

      3.) DG data

      4.) Reports (released)


      But what you can not migrate using this approch is:

      1.) generation variants

      2.) WWI templates

      3.) Expert Rules

      4.) and many other stuff


      The "trick" might be the "right" use of the SAP PI/XI/PO interface: Here you can apply a lot of mappings if needed.

      If you do not use this option; then the SAP target system must ! have the same customizing set up as the source system or ALE will not work

      This variant can be used as well for "client to client" migration (and not only for SAP to SAP migration)


      Author's profile photo Mark Pfister
      Mark Pfister

      Hello Christoph,

      Happy New Year!

      I used that approach a couple of years back when I migrated a standalone EHS into a Logistic / ERP System in order to eliminated the need for one complete SAP System landscape only for EHS.

      I think you got it completely right above - some vital parts of the system you can't ALE (Like GenVars).

      And you need the customizing to be identically (maybe besides the Number Range intervals).
      One of the advantage was the reprocessing of failed IDOCs (Due to not yet migrated data (e.g REAL_SUB is part of another REAL_SUB)) was very easy.



      Author's profile photo Christoph Bergemann
      Christoph Bergemann
      Blog Post Author

      Dear Mark

      for ALE (an push data from one system to the other) the approach to be used is (from my point of view) simple; start at the lowest part..

      E.g. Phrases may be first; then LIST_SUB; then PURE_SUB.. etc.

      Your topic with the “REAL_SUB” story adds then the complixity but can be handled as well.

      Materials can be a problem as well (as we can assume that REAL_SUBs or DG_CL_SUB_SUB do have assigned materials); the materials must be in place in the target as well.

      On top: if all the master data is available in the target system and e,g, GenVars the same: you can distribute WWI based (and inbounds as well) reports to the target

      But the other challenge is not easy (that means not SAP => SAP but Non SAP => SAP) using e.g. may be a middleware like XI/PI/PO or other approaches you might succeed (i never tried it: We use standard EHS import only).

      E.g. if you check some of the many threads: e.g. even the “simple” ALE Phrases part can stuck ( i still assume a problem either with the number ranges or the use of “Change numbers”)

      Overall: you need some experience in using ths approach to get a result


      Author's profile photo Sonja Koehler
      Sonja Koehler

      Hi Christoph,

      Do you have you any recommendation/experience with moving IBD documents from DMS to KPRO. In this case ALE is not an option. Important is also the linked table such as ESTDH as well as the DMS documents.

      any ideas would be appreciated.


      Author's profile photo Christoph Bergemann
      Christoph Bergemann
      Blog Post Author

      Dear Sonja

      start a new thread. The move of "DMs" to "KPRO" or "KPRO" to "DMS" is not a "data migration" story. It is a "technical story" and discussed here  often. The pitfalls are huge (if you just just all the existing threads here)