Breaking changes when upgrading inRiver PIM using Episerver connector

The change log for inRiver 6.3 (which you'll find on their wiki if you have access to it) says the following:

GUID code is duplicated for products when they exist in many channels, different places in CatalogEntry in epi database.

This seems to mean that the format of the content GUID for catalog entries have changed. If you have content areas with catalog entries (variants and products) in them, these will seem to be invisible after the upgrade. The content fragments are still there, but as their content GUID is now invalid, Episerver can't really display anything.

If you look up one of your content nodes which have catalog entries in a content area in the database:

SELECT [pkID]
      ,[fkContentID]
      ,[LongString]      
  FROM [dbo].[tblContentProperty]
  WHERE fkContentID = 68880

...you'll find something that looks like this:

  <div data-classid="36f4349b-8093-492b-b616-05d8964e4c89" data-contentgroup="" data-contentguid="007158bd-0000-0000-0000-000000000000" data-contentname="Entry name">{}</div><div data-classid="36f4349b-8093-492b-b616-05d8964e4c89" data-contentgroup="" data-contentguid="00715b69-0000-0000-0000-000000000000" data-contentname="Entry name">{}</div>

And it is the values in data-contentguid that changes. The content name can still be located in your CatalogEntry table, proving the entry itself is still there.

Now you know. If you have loads of catalog entries in content areas like this, it might just be worthwhile to write some form of automatic job to do it all. I guess you could even match the content name with entries in CatalogEntry table, and do it all after the upgrade + full channel resync, thus needing no work up front. If not, I'd highly advise to backup your old commerce database, having something to use as a reference when fixing this in your own solution.