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.