Weird, like you said it's like EPiServer set the SysSiteAssets to be 3.

The site config is now stored in the database so you will have to find and alter the value there.

View name VW_EPiServer.Web.SiteDefinition

Table name tblSystemBigTable

Set it to a value that doesn't exist yet.

Well, in that table, the SiteAssetsRoot is set to 17255.  Not 3.

I looked for that value in tblContent, and it is a content item called -- wait for it -- SysSiteAssets right under Start (parent is "3").

What I think might have happened here is that when we were investigating, we set to Manage Websites and clicked "Use site-specific assets" (it was not checked).  My gut tells me that doing this changed the value at that time.

So, I re-ran the VPP migration tool.  However, I got the same error, which I just find completely confusing, since the database table is clearly showing 17255.  The tool is still trying to put things under 3 for some reason.  I can't figure out where it would be picking that value up.

I decompiled the VPPMigration tool.  It appears to be looking for the "GlobalAssetsRoot," not the "SiteAssetsRoot."

I have no idea where that value is defined.   I'm walking the decompiled backwards, but I can't see where it's set or where it might be in the database.

So, it's failing on this line in the migration tool.

ContentFolder destinationFolder = this._contentRepository.Get<ContentFolder>(SiteDefinition.Current.GlobalAssetsRoot);

I walked back through the code and found that the GlobalAssetsRoot is set to 3 (it's hard-coded to a specific PageGUID, and retrieved using the stored proc "netContentRootList")

AHA!....no.  That's normal.  We checked other 7.5 installs, and they're all 3 for the GlobalAssetsRoot.

But I can't see how that would even work -- that line of code is clearly trying to get content ID 3 (the start page) and cast it to ContentFolder.  Just for giggles, I followed my Start Page class up the object hierarchy all the way back to ContentData.  There's no ContentFolder up that hierarchy, so I can't see how this isb't simply an invalid cast by design.

It appears that the globalblocksfolderid and sharedfolderid was equal to the pagestartreference during the upgrade process.  Once that was changed, it was resolved.

Joshua, what did you change to? A non-existing ID as Toni points out above?

I'm experiencing sort of the same problem, although my globalBlockFolderId and siteBlockFolderId are set to an ContentReferenceID (the random number 3286) pointing to just a regular page. This happened mysteriously in the upgrade step from 6R2 to 7 (I'm upgrading all the way to 7.5).

Good morning Eirik,

I was going from 6 -> 7.5 on another and the same thing happened to me.  I am not sure what it was but I ended up re-runing from 6->7 and it worked the second time around.  this has happed on more than one occation.  Is this your 1st attempt?

We are experiencing the same problem. GlobalAssetsRoot is pointing to a random news page and the migration tool failes when it tries to cast it to a ContentFolder.

As you where saying Deane, the GUIDs are hard-coded in the stored proc and I belive we get the error since we have an existing page that happens to have that same guid. 

We are now looking in the database prior to migration for content having any of the hard coded guids. If we find any pages we delete dem after we copied the page to a new one.

I had this one figured out, at least for our case (sorry for the late reply Joshua).

The important thing to prevent is allowing the content ids written to the config attributes globalBlockFolderId and siteBlockFolderId to become out of sync with the database one are trying to upgrade. This came to happen during our upgrade process from 6R2 to 7.1 in the dev environment, as we were testing the upgrade of the database in different states, i.e. it was backed up from production at different points in time. As the config file was under version control (Git), a mismatch between the config file at state A and the database at state B occured during an upgrade attempt, leading to the above described failure (they should both have been at state A).

To ensure a clean upgrade, make sure that the upgrade process all the way up to 7.5 is performed without intermediate deploys or interventions (assisted by source control) of config files. When the upgrade state is successfully at 7.5 or above, the problematic config files have been stored to the database itself, and we are no longer bothered by this problem.

Thanks for clearing that up Eirik! That was the root cause to our problem to it turns out :)