I would guess it’s some json it’s tripping up on from a property editor that’s no longer supported like that old grid. Seems a bit nuclear but deleting this property off the doc type would probably do it - though you’ll loose data.
Might be worth trying to change it to a text field and see if that at least gets you stable. In these situations I usually see what it is, how used it is and then rethink my migration strategy (either not doing a direct upgrade, or using uSync migrations or writing my own migration or even using an API on each Umbraco instance and “update” and transform the missing content.
I didn’t have Umbraco Grid, i did make use of nested content. they were upgraded/migrated to blocklists, during the upgrade stages.
Its these fields that seem to be causing some sort of issue on the nodes. Nodes, so far, i have come across don’t have or did not have data within the nested content fields while upgrading.
It sounds like you’re onto the right lines with nested content. Not sure what might have gone wrong during the migration but if I was to start debugging this I would take a look into the database and see what the raw value of the property is that’s being stored.
Here’s a script that pulls back all of the latest version of all the content. You can uncomment that last line and add the page node ID (integer) to filter for just that node. You’ll be looking for a value in the textValue column that should be a JSON field, but isn’t.
SELECT
upd.[id] as propertyDataId
,ucv.nodeId
,[versionId]
,[propertyTypeId]
,[languageId]
,[segment]
,[intValue]
,[decimalValue]
,[dateValue]
,[varcharValue]
,[textValue]
FROM [dbo].[umbracoPropertyData] upd
inner join [dbo].[umbracoContentVersion] ucv on ucv.id = upd.versionId
where ucv.[current] = 1
-- and ucv.nodeId = 1234
That should then enable you to either fix it in the data or work backwards through the merge to see what might have gone wrong.
The other thing to check - from memory - my test upgrade hit publish errors and it was a property was using the legacy media picker. Updating the datatype to the newest one just fixed it (and this supports the legacy values it seems).
Do you mean in your v8 DB? There has been a renaming exercise going on - cmsXXXXX tables are becoming umbracoXXXXX but seemingly a bit at a time per version try:
[dbo].[cmsPropertyData]
A guess - don’t have a v8 db laying about but it was this in v7.
What we saw is that content that was previously deleted was migrated anyway. Using the uSync content handler to delete the content was the solution for us.
Just enable the content handler and use the following template to create delete actions for the affected content:
Went back through the upgrading steps… checking what the state of the troublesome nodes before updating to nested content to blocklist. They were empty and expanded, not sure if that has an effect on them when the conversion happens when you do the convert via the uSync.miragrtions ui.