Skip to Content
Technical Articles

Migration of version history for ABAP Repository / Plan

Every developer surely knows this screen:

Version history is an important tool to track changes in products. But how do you migrate these data from one system to another, so that it remains accessible?


Company I currently work for has got two main development systems: an older on Web AS 6.20 basis, and a newer one. Support for our products for the SAP R/3 lasted until end of 2015. Then all the products got installed in the newer system. All but one, for which the R/3-support ends in this year. That’s the reason why there was no system upgrade. But as a result our version history is splitted — all changes until end of 2015 can be viewed in the older system, newer changes can be viewed in the newer system. With the end of R/3-support for the last product the system will be shut down so that the version history will not be accessible anymore. Since we don’t want to loose this valuable source of information, I’m currently looking for a way to migrate this data.


I don’t know any report to migrate the version history. But to be honest, I wasn’t looking for it either. I found that the version history is stored in some DB tables, particulary VRSD (somewhat like header information) and VRSX, VRSX2 and VRSX3 (actually there is also VRSX4, but not in the older system). It seems that it would be enough to migrate the entries from these tables. The only issue is, that from 2016 until now further development of our products took place. So we have to merge the history from both systems. But this should not be difficult, since there was no parallel development. So we only have to renumber the entries in new system and insert entries from the older one.

First checks were positive.

Dependent information

Transport requests and tasks

But then I realized, that the version history is not all we need. Often to get the background information of some change, one have to double click on the request number, to get more information, like short text, attributes, list of objects, tasks with their owners and last but not least — documentation.

But neither this point should be that difficult — all the information about transport requests and tasks is kept in DB tables, and since systems with different SIDs have different number ranges for transport requests and tasks, we can just migrate theses data the same way as the version history itself.

The tables which are relevant for transports are: E070 (header data), E070A (attributes), E070C (source / target client) — I’m not really sure that we need these data, E071 (list of objects) and E07T (short texts) — as a matter of fact, this table is language dependend, but I think SAP doesn’t support short texts in different languages for transport requests / tasks, at least not in our newer system, which is actually not that new anymore (NW 7.0). There are many more E* tables, but I don’t know whether these data is relevant. On the other hand, it wouldn’t bother me, to migrate these data too.

Only the documentation for transport requests / tasks is kept in the central tables with SAPscript texts. But the content of these tables has to be migrated also for the repository objects, so nothing new.


All (?) documentation is kept as SAPscript in DB tables, particulary DOKHL and DOKTL. I’m curious about the second one, in which the older versions of documentation is also stored. But I did not find the possibility to view and compare these older versions.

One way or another — we don’t want to loose these data either, so we will migrate it. And I hope these two tables are the only relevant. In this context I came across some header fields for each SAPscript text:

These are stored in DB table STXH. This can be important for documentation of transport requests and tasks, but not repository objects, since their documentation will be transported with the request. The above screen shot was taken in the newer system — in older these three fields are present in the DB table, but I didn’t find the possibility to display them among with all the other header informations.


There is a possibility to store comments to the translation of every object:

These are stored in DB table LXE_REMRKS. But since we don’t (yet!) use the system tools for translation but rather a third party product, we have no comments. If we were using the standard translation tools, we would have to migrate also the data for the translation projects, tasks or whatever these are called.


That’s pretty much all about my plan to migrate these data. I’m now preparing a PoC, but since there is too much data to migrate, and there are more relevant tasks to accomplish, the validation of the concept will be carried out for a small representation of our repository objects only.

The final migration will take place in February, assumed the PoC finishes positive.

And here’s my question to the community: did you ever have such a requirement? If yes, how did you realize it? Can you think of any other aspects, which I didn’t take into consideration until now? I’ll be more than glad to hear from you in the comments and hope you enjoyed reading this short blog.

You must be Logged on to comment or reply to a post.
    • Hi Edo!

      Thank You for this hint!

      Solution proposed in this note wouldn’t make it for us, cause we want to retain the version history from both systems, and not only copy it between systems. Besides, the solution proposed in this note copies only the version history, not the dependent data (it says explicit: Note that no change request data is copied in this case.)

      Best regards


    • Another problem with that solution from the note, that you cannot filter out a certain range of objects (eg a namerange), it takes every objects from the system. 🙁

      Our situation was that we tried to move the version history during setting up a new development system for add-on development, but this approach didn't work.

      In the end we decided to import all release and SP transports to the new system (as far as I remember export was also necessary), so it took some time, but in the end it looked good.



      • Thank You Peter for Your insights!

        We could use Your approch for the one product, which is still developed in our R/3 system, but not for all the others, that were developed there until end of 2015 and are since then further developed in our ECC system.

        Yet another problem with the solution from the note is, that it says, it is only applicable for systems with the same version of SAP_BASIS, which is not our case! But is it limited, because of different storage in the DB tables, or because of the way R3trans works? If the first, then my solution could also lead to runtime errors at the end.

        Best regards


        • Hi Edo,

          the situation was. that we had one of our “old” development system, where our add-on was developed. We wanted to move it to a “new” development system with higher basis release.

          The “old” dev system had the whole version history of the objects for the add-on, plus the whole history of millions sap notes, which were implemented there.

          We find no way to filter out only the add-on history and we didn’t want to move the history of the million other sap standard objects.

          Best regards,