Importing WCM content library from v6.1 to v8

I’ve been helping out a customer who is migrating from WebSphere Portal v6.1.0 to v8. To overcome some issues in their migration we decided to attempt importing their WCM library directly using the WCM export & import commands rather than via the migration utility itself.

The first step was to get the customer to make an export of their content library, which they did, zipped it up and sent it across. The library export contains about 33,000 files and was around 300 Mb in size. This export was done using the normal WCM export commands.

The import was much more problematic, but worked eventually. The issues encountered were:

  • First time I tried I was using the Derby database. This amount of web content breaks that database and I had to rebuild my server, this time using DB2.
  • On the first several occasions, the library import failed part way through, leaving me with a library to delete. This library deletion failed with various DB2 errors:
    • DB2 SQL Error: SQLCODE=-964, SQLSTATE=57011
      SQL0964C The transaction log for the database is full.
      User Response: Execute a COMMIT or ROLLBACK on receipt of this message (SQLCODE) or retry the operation.
    • The solution to this is in this technote here: 
    • As indicated by the technote the DB2 transaction logs should be increased in size by increasing both the number of primary logs and size of the files. The inital total size was around 500Mb, I found that I had to increase the total size to around 4GB.
    • I increased LOGPRIMARY to 24 (from default 12) and LOGFILSIZ to 16000 (from default 4000)
  • I also received transaction timeout exceptions in the WebSphere logs and various hung threads, both when importing the library and when deleting it. Increasing the transaction timeouts, as the documentation suggested, resolved this. I set total transaction lifetime timeout and the maximum transaction timeout to 420s, not 360 as suggested in the documentation.

Now able to delete the library successfully, I needed then to resolve the import errors. The WCM library import is quite fussy, and will fail if anything goes wrong – e.g. an expected file is missing or any inconsistency is found. The logs tell you which content item the import failed at, and you have to iteratively fix the content item in the source system then try the export & import again. If there are lots of errors this is a time-consuming and tedious process.

In my case, I did not have access to the source system so I decided to try to resolve the issues in the library export itself (keeping a careful backup, of course). This isn’t supported but it was moderately illuminating.

  • In many cases there were missing files called e910e1b8.value and f869ab82.value which, on inspection, contained the content item’s ACL and change history respectively. The filename is constant and the file references the content item simply by it’s path in the library export. So to resolve errors I just copied the files from a neighbouring content item into the one where the import reported that the files were missing. This gave an incorrect version history on the items I imported but I decided I could live with this.
  • There were also content items where a missing element was reported. In this case I just removed the whole content item directory from the export (if I’d had access to the source system I’d have checked these items and potentially deleted them there).
  • All told I probably had to fix up about two dozen nodes, it took me all evening.

The end result, apart from a well-tuned portal VM using DB2 (an unexpected plus) was that the library import was successful.

There are situations where I’d recommend using this technique to facilitate migration to v8. These are:

  • There’s a large jump in versions and all you want to keep is the web content
  • You want to rework the portal site and build a new theme post-migration
  • There are no user customizations to migrate

4 thoughts on “Importing WCM content library from v6.1 to v8

  1. Hi,

    We are also doing migration from to and finds that the JCR migration takes soo long to complete. I am thinking to use your approach by export/import the JCR library. My question is that what will happen with the ConfigEngine upgrade-profile task? From what I understand, the ConfigEngine upgrade-profile will also perform JCR migration. How to skip this portion then?


  2. Hi,

    Regarding the proposed steps as explained in my previous thread, I would like to further detail out to be as the following:
    1) Connect the new Portal 8 to the existing customization, community, likeminds, and feedback WPS61 database
    2) Clone the existing WPS61 Release database
    3) Connect the new Portal 8 copied/cloned WPS61 Release database
    4) Create empty JCR database and perform database transfer only for that JCR database domain in the new Portal 8
    5) Run ConfigEngine upgrade-profile. This still includes JCR database, but with the no JCR data, so it has to be a lot faster.
    6) Export WCM Libraries from WPS61
    7) Import those WCM Libraries to the new Portal 8

    To me, it should be logically working.

    Please kindly advice.


    • Hi Fernando, Thanks for the comment. I think what you outline there sounds logical – I guess you’ve had time to try it out by now, what happened?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s