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.

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.

NAME = USEHTTPPLG and VALUE = OFF.

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