Skip to Content
Product Information
Author's profile photo Sagar Shridhar Bhide

Content Repository Migration in mind ? Part II

Dear Reader,

I hope you have read the earlier part of this series where I introduced different ways in which you can perform the content repository migration. You can read about the same here

As mentioned I would try to explain the difference in Report RSIRPIRL, Z_DOC_COPY, Z_MIGRATE_ARCHIVELINK.

You may ask a question, Why did I select these three reports only and not adding about other reports?

The reason is that other reports are derived core module which is being used in the report RSIRPIRL and thus other application reports would have the same technical behavior as RSIRPIRL. (Exception: Migration/Copy with Transport Layer  )

Also why this is a separate blog post and not part of the same?

I like to keep things short and simple. Also, I feel that I may have lost some of my genuine readers if the blog post would have been very long.

So let’s come to the point.

As you know now, There are 3 main reports from the which are suggested for the migration of the data. The differences are as below.

This works in the application context, In other words, this needs a PHIO Class and storage category for selection screen for execution. In other words, this works at the DMS level This report works in a context with the content repositories. This report works only on Archivelink documents

This report migrates to the attachments. In other words, it copies the attachments from the source repository to the destination repository and then deletes the attachments from the source repository.

As this report deletes the attachments after copying it to the destination repository. There is a chance of attachments loss in case the create operation on the destination repository is inconsistent.

This report copies the attachments between the source repository and the destination repository. The report does not delete the attachments at the source repository. You have to delete the documents from the source repository.

No chance of data loss. Ideally, we double the data volume.

Same as Z_DOC_COPY
This report also changes attachments metadata in SAP tables. The program modifies the tables in a way that KPro would read the documents from the destination once the migration of the document is complete. Works on one document at a time. No changes in metadata tables are made, the customer has to adjust them manually. After a successful document copy. Works on one document at a time Report adjusts the Link table entries and attachments would be accessed from the destination repository / new repository
As this report works on the application level, there are chances that after migrating the data from source to destination, We may have residual documents on the content server. These documents can be from other applications like Archiving / Archivelink. These can also be orphan documents (documents do not have application context) All consistent documents are copied. The report copies all the consistent documents from the source repository to the destination repository. Documents remain on the source repository and are not deleted
This report can work with any type of storage like HTTP content Servers, RFC repositories, SAP System Database storage, etc. Works with only with SAP content Servers, in other words, SAP System Database storage repository and SAP HTTP repository (Undocumented* Command docidlist ) This report can work with any types of storages like HTTP content Servers, RFC repositories, SAP DB
It can be restarted and the report would continue from where it left in last execution. It can be restarted and the report would continue from where it left in last execution. It can be restarted and the report would continue from where it left in last execution

Undocumented *:-  This command is not documented in SAP HTTP interface guide and only SAP repositories have implementation for this.

Limitations with all these reports.

1) These report needs to have different repository names. Because the customer has to create repositories in the same SAP system (Transaction OAC0) and SAP would not accept the duplicate in this case.

2) These reports will not work across the systems. In other words, you need to connect both the repositories to the same SAP system. This does not work via RFC.

Issues that can occur:- 

1) The report is Slow:- These are ABAP reports and the customer would be moving a large amount of data (a couple of GBs or TBs) via SAP system and thus copy process is slower. This report works with a single document at a time. In case you feel that the report is slow and you would like to execute this in parallel, please schedule the report manually by using the date range option in the report RSIRPIRL.

Report Z_DOC_COPY cannot be executed in parallel unless you trigger this with a specific list of documents in parallel.

Please note that Z_MIGRATE_ARCHIVELINK cannot be executed in parallel.

2) Memory Overflow while report execution.

KPro communicates with the content server with SAPHTTP or ICM client. In some cases, ICM may run out of memory and thus your background job may be terminated. In this case, we would recommend you to add the following entry in table SDOKPROF and restart the job.


(This setting would use SAPHTTP client to communicate with the content server instead of ICM).

3)  Always make sure that you are using the latest version of the content server patch and SAPHTTP while performing the migration. You would be touching a large number of documents during the migration process and thus any bug in these components can cause a large impact on your systems. Please also make sure that you have a necessary backup of the content server, KPro Header table, and link tables. In case the migration fails you have to restore these tables.

So that’s all for now. In the next part of this series, I plan to provide details on what can be done as the next steps in your system or what you generally call follow up activities.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sagar Shridhar Bhide
      Sagar Shridhar Bhide
      Blog Post Author

      Dear Reader,

      You can check the Part III here 


      S S B

      Author's profile photo SUSI OKTAVIA

      This is a very useful information. Thank you very much !

      Author's profile photo Jignesh Bhesdadia
      Jignesh Bhesdadia

      Hi Sagar,


      We recently did the client copy and moved the data from PRD700 and QAS700 system. We had planned to use following approach suggested in your blog 1.

      Approach 2 ) SAP Development provided report Z_DOC_COPY  SAP note 2774469 


      However, we are not able to copy the content repository from Z_TEST_PRD_700 to Z_TEST_QAS_700 as we understand that the Z_DOC_COPY program is in supported as ours is cross client scenario (PRD-->QAS).

      1. Would you please confirm our understanding and confirm that this program is not useful in our case.
      2. If this is not useful, would you please suggest any approach which is best suited to our requirement.

      I will appreciate if you can suggest us appropriate approach in this scenario.

      Thanks and Regards,



      Author's profile photo Sagar Shridhar Bhide
      Sagar Shridhar Bhide
      Blog Post Author

      Dear Jignesh,

      To copy the contents between repositories directly, these reports are not very useful. You can look for a tools at DB level and there may be leakages and misses depending on the tool you used. I cannot comment on that.


      if you would like have a full proof approach then you need to connect your repository Z_TEST_QAS_700 to your PRD system and then use Z_DOC_COPY report.

      Author's profile photo Jignesh Bhesdadia
      Jignesh Bhesdadia

      Thanks for the reply. 🙂


      We tried this program Z_DOC_COPY program with success to move some sample DIR originals from Z_TEST_PRD_700 to Z_TEST_QAS_700. We get the message saying that attachments sent successfully.

      However, we are facing following issue when try to connect to the original from QAS system.

      • As I mentioned, QAS700 system is client copy of PRD700 with master data so all DIRs with GUID and other data copied from PRD700 and also we can see the originals with Checked-out status in CV03N
      • After these sample attachment transfer to these selected DIRs, we still see the DIRs have originals checked-out and file name is not maintained there. So, we are not able to access them and getting the error message as there is no file to show.

      I understand we may need to do some manipulation or run some report to populate the file name and path. would you please guide how we can connect DIRs and recently copied Originals from the source in QAS system.

      Thanks in advance.

      Author's profile photo Rajesh Mangote
      Rajesh Mangote

      Hi Sagar,

      We have an external vendor Brain tribe for Archive Link configuration in SAP, Now we need to migrate the Archive documents from Brain tribe CS to SAP Content Server.

      Can I go with Z_MIGRATE_ARCHIVELINK report approach. Any thing which we needs to take care before going with this approach.


      Thanks in advance


      Author's profile photo Solman Funcs
      Solman Funcs

      Hi Sagar,


      We used the report ZMIGRATE_ARCHIVELINK_FILES for migrating our documents from one repository (T3) to New one (A3) but when we try to access the documents from A3 repository, below error message is displayed. Could you please suggest on this also, how should we correct it?

      HTTP error: 404 (Not Found) "F:\SAP\ContRep\A3\0b08\EBCA91FBE3BC7DF1B2B6000D3ADDC84C directory not found"

      Thank you.



      Author's profile photo Turgay Samdanli
      Turgay Samdanli

      very useful post. Thank you very much

      Author's profile photo Chiranjeevi Saini
      Chiranjeevi Saini

      Hi Sagar,

      I am new to migration and this blog is very helpful. Currently, we are planning to copy a few DIRs from one content server (CS1) to another content server (CS2) with all the metadata, object links, and originals. These two content servers belong to different landscapes (DEV and DV1).

      I understand from the blog that

      • We can point Content repository CR1 of CS1 and Content repository CR2 of CS2 to the source system DEV and run the report Z_DOC_COPY in the DEV system to copy the attachments.
      • Now point Content repository CR2 of CS2 to the target system DV1
      • Run report ZZ_DMS_KPRO_CHECK_FILES for attachment integrity in the DV1 system.

      Is my understanding correct? Please confirm.

      Also, please suggest how do we copy DIR metadata and object links from the source system to the target system. BAPI_DOCUMENT_CREATE2?

      Thanks in advance.



      Author's profile photo Shailaja Stalin
      Shailaja Stalin

      Hi Sagar,


      Before doing this activity in quality system, I am trying in development by copying between two existing repositories in same system but in table TOA01 i don't find those values.. Any idea on this...

      Author's profile photo Krish Gopalan
      Krish Gopalan

      We are using Z_DOC_COPY to copy the archive link content server repository from one content server to another content server.


      How do we change the links in linkage table (to point to new repository)? Are there standard programs.