Content Management and Capture

Likely due to big-endian vs little-endian. Support has a GCDEdit tool to decrypt the GCD and export and re-import it on the new platform.  When the string GUIDs in the export are imported, the binary formats will be converted automatically.  That said, there are surely "well-known" GUID constants in the source code. In theory, two related GUIDs on the ObjectStore DB would still be related if you didn't transform them, but I wouldn't take the risk, especially if you have encryption on the file stores. Even if you serialized and reloaded all the GUID columns, there will be GUIDs in the blobs. You would be testing and validating this for a year and it would be unsupported. You could see if professional services has something - I recall one case where IBM outsourced it (same scenario) and the vendor ran into issues. They may have resolved it. I can ask if you DM the details. Or do it yourself. You can write something to export and re-import the docs to take care of the encryption, and sync the metadata using database exports/imports. If you have workitems, try and process them all before the cut-over - manually process them for a few days if you must. I have used this approach several times. The first was 400TB and the second was just 12TB but they both took 9 months - due to hardware differences (e.g. x86 and ethernet vs AIX with multiple HBA's and fiber SAN). You can make it fit a given timeline if you need to. The beauty of doing a parallel install is it doesn't impact production. 

Thank you, Stephen.

We migrated the data using DB2 scripts. The content storage is not encrypted, and we are able to view/download the documents we migrated. We observed that certain operations are failing such as changing the system user password and loading workflow tabs and isolated regions.

Interesting part is that on AIX when we reused the engine-ws.ear file from one server to another we got exactly the same behavior within ACCE. In this case, there is no data migration or AIX > Linux involved but same behaviour was observed upon moving the engine-ws.ear file. Would it be safe to assume that the error does not have anything to do with aix vs linux platform since it appeared even on aix vs aix setup.

> When we reused the engine-ws.ear file from one server to another we got exactly the same behavior within ACCE.

I was assuming a SystemZ, but that was just an assumption. You can ignore that if the chips are similar. 

The newer versions (after 5.5.0) the GCD is encrypted.  

A seed is generated when the app is installed. That seed will be instance specific. Think of the wsengine.ear under the lib as a template. As you patch it, configmgr references the existing ear under the profile and modifies it.  Whenever I've done a platform upgrade, After I install the software to install the installer bits, I copy the entire directory from the old server to overwrite the new install to keep the seeds the same and then rebuild and deploy that ear. You may seed seed xml files. (I think, but don't know for sure, it is also serialized into one of the eclipse resource files. 

Then I dump the GCD file to change the server name.  I remove all but one server entry and then edit that.  You need one matching WebSphere node name entry for P8 to bootstrap. Once it bootstraps, it will add any remaining nodes to the cluster. 

Roster and Queue fields in the database assist with workitem searches, but IIRC, the work object values are also stored in a blob.  If you revise a workflow and change the column schema for NEW workitems you still need to access the version specific content - hence the blob.  In the original eProcess days we would open and rewrite the values using something called jigGlue but there is no such thing in p8 but you might use the PE REST services for that. Bottom line is there COULD be values in the blob that were left unchanged by db scripts.

I no longer have any RISC workstations to look at platform swaps, but our team periodically copies the prod objectstores db to qa for testing but not the gcd.  They do that periodically and I go in and change the URL, add a new local file store area and that takes care of doc retrieval. I also change the primary workflow group but have instructed them to create new work items and attachments for testing. 

Back to the GCD

If you get hold of GCDEdit from Tech support and export the GCD, you will find these elements:

Hi, I have re-platformed from Windows to Unix and Unix to windows without these issues but not the flavors you mention. Since the GCD is up I can't say its encryption key / encoding for the gcd blob affecting you.  Can you verify you updated connection point host information and step processor urls? Does a newly transferred workflow work? Can you execute a workflowsearch in ACCE? Last item what do you see with PE tools either vwtool or PE Designer? Can you open/view the region?

Hit up lab services. They have a GCD_Util for your version. You can do an export, reset the encryption keys and import again.