I have now spent five days of my holiday trying to upgrade one web from Umbraco 7.10.4 to 8.10.1. I give up. It is ridiculous. There is a video series on Umbraco forum "Migrate an Umbraco Cloud project from 7 to 8". But it involves so many steps and is so vague that it is ridiculous. The approach is that everything should be "automatic" but when it doesn't work you are stuck.
The approach assumes you have an inline database in your App_Data folder. I don't as I think this is contrary to good practice with speed and deployment. If I manage my site for some days in my computer and then deploy some changes I will overwrite all data that has been updated on the site. Does some people actually work that way?
So I tried to copy my database from webhosting environment to new database. Doing this online remotely with Sql Seerver Managament keeps failing all the time because the process is far too slow. So what do I do then?
It is fine to rewrite all code. It is fine to do a lot of manual work adjusting pages to the new way of working. I just want help to transfer the data.
How hard can it be? The data format must be known. I just want someone to offer a simple tool that will extract DocumentType, DataType and MemberType from the old database and then import them to the new one. Then the same with nodes: Documents and Member. As a last step I want to convert my Media section to use the new format.
I prefer explicit conversion where I can specify what to convert and point to a connection string of a new resulting database.
Have you thought about creating a package with all of your content and installing the package on your v8 install? I'm not 100% sure that will work, but that's what we do to install a bunch of boilerplate stuff every time we start a new project and it seems like that's what you're looking for basically.
This looks really good!!!
I really like the approach of Stuart Mullinger. Exactly what I was looking for.
There is still some things lacking for me. I had to recreate my Member Types and there was some manual adjustment needed for Composition Types now needed to be defined as Element Types. But still most of it worked!!
I've done a few upgrades to v7 latest. If I remember 7.10 to 7.15 is doable.
Can you give more details on what steps you followed and what the error is?
Also had a project that needed upgraded from v7 to v8. I opted to start from scratch and manually port over the code, it took a bit of time but working in small increments helped.
I was stuck in the state where I could not copy the database content from one database to another. Now I started over manually the same way as you did. Slow but stable process :)
And also anyone coming to this thread via google, I had problems migrating a site to the latest V8 a couple of days ago and this is because the migration script is currently broken to sites with a version > 8.6
This means you have to perform the migration in two steps, eg first to 8.5 and then upgrade again to V8 latest - but this isn't possible on Umbraco Cloud you can't provision a V8 site < 8.6
But there is a community plugin that works around the issues.
What I can't tell from your V7 dilemma, is if you are on Umbraco Cloud or not, and the problem lies with getting a copy of the site database from the webhosting?
If it's Umbraco Cloud you ought to be able to get help upgrading from Umbraco support or get access to the database:
But if you can get your database, the upgrade from 7.10 to 7.15.6 should be painless, and as long as you install the two packages, the migration to V8 should work.
Thanks for all well meaning help! It was a good exercise. After spending over a week on this I actually decided to give up. There is too much manual adjustment going on forever. My own conclusion is that I might give Umbraco 8 a go on next web project, but never try an upgrade again.
It can be done, but it also depends on what packages you have installed on the V7 site too :-( ... it's why they don't call it an upgrade, but talk about there being a migration path - but lots of potential for things to go wrong, and likely something you'll only have to do once, so not useful knowledge to master!
But if you have a particular error will try to suggest a solution/workaround if I've seen it before!
Hi Mark, yes I've been following that very same article and have installed the premigration healthcheck, but nothing, not even sure if it's run (or if there is something else I'm supposed to do to get it to run). I've used the healthcheck tool in the dev/packages section to clean up the database, so I'm pretty sure that's ready to go, but nonetheless each time I tried to migrate the database it would fail (after hours of waiting for it).
Yesterday installed ProWorks.Umbraco8.Migrations -Version 1.0.15 into clean copy of Umbraco 8.1.6 (via the package manager console) and it upgraded the umbraco application to the latest version at the same time (which I didn't want to do until I'd successfully migrated the database).
But I ran the migration again just in case, 2.5 hours later, it failed with yet another almost unreadable log file (json log files, obviously you can't read them unless you can get the Umbraco 8 CMS running, trying to read them using an online reader throws an error so I'm left with trying to work them out using text edit)
Anyway, I'm now on something like my 15th iteration of this (this time going to install the pro migrations package not using the console to avoid it preempting the version upgrade).
Failing that I have to try to convert the umbraco.sdf into SQL db (if that'll help). Doubtful I will get this done before Christmas.
Oh I've only got the recommended premigration packages installed on in the cms, nothing else
Do you perhaps have the error message that you are getting in the log file? I did have some issues with the migration as well due to the image versions missing (No idea, because images don't even have versions). But all fixed with an SQL script after that
Thanks Patrick, I'm halfway through a new attempt now so if (when) that fails I'll try to pick out the errors from the log and post them here.
But it started with It started with:
Error during installation
The database failed to upgrade. ERROR: The database configuration failed with the following message: One or more errors related to unexpected data in grid values occurred. Please check log file for additional information (can be found in '/App_Data/Logs/') (a couple of times)
Then after tweaking finding other articles (I can't remember exactly) errors moved to:
1. tables were found in the database, but are not in the current schema
2. columns were found in the database, but are not in the current schema
Got those errors a few times (each time after a couple of hours of the migration running.
But yesterday the error was different but I assumed it was because I'd installed the Proworks tool via package manager console rather than Nuget package manager - oh and also got told by my colleague to avoid 3rd party packages :) (have to laugh).
but yes, the only packages installed in the CMS are the migrations tool and the health check.
Once the premigration package is installed in the V7 site
and before you attempt migration
visit the backoffice developer section, and find the 'Health Check' tab and click 'Check All Groups'
that will run the premigration healthcheck and it will report if any of the common database and content issues that muck up migration are present in your db.
The instructions and steps are all geared around the database being on a SQL Server, and so the encouragement is to spin up a separate visual Studio solution and install V8.1 into that and point it at the database... but you can't as it's a sdf file! in the V7 solution
So I think you'll need to copy your V7 sdf file into your V8.1 solution (with the proworks package installed) and update the V8.1 connection string to point at it, to trigger the migration in the context of the V8 solution...
thanks Mark, yes I did that, and checked all Groups and according to that the database is now fine.
Yes, that is what I've been trying to do with the umbraco.sdf, just change the config to point to it, migration process starts runs for about 2.5 hours then I get an error and the log is fairly consistently reporting what I've posted below. It did this without ProWorks.Migrations installed as well.
I will take another walk around the 7.15.7 cms and see if I can see what it's talking about viz the grid editor datatype thingy, but not at all confident.
Thanks for your help anyway. I feel a little more sane for the conversation, at least!
Cannot deserialize the value as json. This can be because the property editor type is changed from another type into a grid. Old versions of the value in this property can have the structure from the old property editor type.
Usually means that there was a property editor on the site, perhaps it was called BodyText and perhaps it was a rich text editor, and then people put loads of content into different pages using it and published it... and then one day somebody decided to use 'the grid' instead, and they switched the underlying property editor for BodyText from RichTextEditor to Grid.
The Grid stores data in JSON format, the RichTextEditor would be a string of HTML
When the switch is made - Umbraco doesn't go through all the existing content pages that use BodyText property and update the saved format of the data to be the grid, the saved values only get updated to use the grid JSON format when the page is Saved by the editor.
So what this message is saying, is that one page or more, somewhere, after this switch was made, there is, saved in the database a page with that property, with it's value stored in the old non-json format.
So when the upgrade script encounters it, it knows BodyText should be in JSON format, and tries to deserialise it, to migrate it to the new V8 JSON format for grid, but can't cos it's just a string of HTML.
Soooooooo, do you know what property got changed and when?
(bet not!!!)
What I'd normally do here, is query the database direct (which again helps if it's in a SQL database and not SQL CE file)
I'd find all the Data Types that use the grid in the backoffice, and make a note of their unique ids (from the querystring at the top)
and then I'd query the cmsPropertyValues database table, that stores all the values for properties, and look for any values for that data type where the stored value didn't start with a { json bracket...
then I'd get the Ids of the document nodes that those property values were on, and go via the backoffice to edit them, and save them with the grid, or if there are thousands, maybe try something programmatically...
does that explain the issue? obviously might not be a rich text editor, but it's most likely change to grid...
Hi Marc,
Yes that does make sense! thank you
The grids are supplied via Macros that have been developed (and upgraded over time by another dev) so although I went through the Developer datatypes to ensure system isn't using obsolete references and then checked the db using CompactView (which BTW, whilst not as good as SQL studio, does a reasonable job for reading and editing .sdf db's), i missed those.
The plan is to move this to SQL but haven't got an appropriate server available for it yet, and need to wait until systems guy gets back from holidays until we can do this. Either way, I will still need to fix these issues and now I have a plan thank you! ....
I was getting quite exhausted (and mental) looking at this so thank you so much!
So I just notice that there is no way of installing ProWorks.Migrations without it automatically upgrading to Umbraco 8.14 (which we don't want to do until we've migrated the database and content and adding in our macros:
This error was generated when trying to migrate to the Umbraco 8.14+ site with Proworks installed
"System.InvalidOperationException: Cannot deserialize the value as
json. This can be because the property editor type is changed
from another type into a grid. Old versions of the value in this
property can have the structure from the old property editor type.
This needs to be changed manually before updating the database. "
I've had this error before, and cannot find anything that relates in the CMS. All datatypes have been upgraded to latest and images in this site are only populated from targeted folders not by using image pickers etc.
I'll take another look at the original CMS tomorrow.
Also getting:
"The following tables were found in the database, but are not in the
current
schema:\r\ncmsContent,cmsContentVersion,cmsContentXml,cmsDataType,cmsDataTypePreValues,cmsDocument,cmsMedia,cmsPreviewXml,cmsPropertyData,cmsTask,cmsTaskType,umbracoDomains,umbracoMigration,umbracoContent,umbracoContentVersion,umbracoMediaVersion,umbracoDocument,umbracoDataType,umbracoDomain,umbracoPropertyData,cmsContentNu,umbracoDocumentVersion,umbracoKeyValue,umbracoContentVersionCultureVariation,umbracoDocumentCultureVariation,umbracoContentSchedule\r\n
\r\nThe following columns were found in the database, but are not in
the current
schema:\r\ncmsContent,pk,cmsContent,nodeId,cmsContent,contentType,cmsContentVersion,id,cmsContentVersion,ContentId,cmsContentVersion,VersionId,cmsContentVersion,VersionDate,cmsContentXml,nodeId,cmsContentXml,xml,cmsDataType,pk,cmsDataType,nodeId,cmsDataType,propertyEditorAlias,cmsDataType,dbType,cmsDataTypePreValues,id,cmsDataTypePreValues,datatypeNodeId,cmsDataTypePreValues,value,cmsDataTypePreValues,sortorder,cmsDataTypePreValues,alias,cmsDocument,nodeId,cmsDocument,published,cmsDocument,documentUser,cmsDocument,versionId,cmsDocument,text,cmsDocument,releaseDate,cmsDocument,expireDate,cmsDocument,updateDate,cmsDocument,templateId,cmsDocument,newest,cmsMacro,macroScriptType,cmsMacro,macroScriptAssembly,cmsMacro,macroXSLT,cmsMacro,macroPython,cmsMedia,nodeId,cmsMedia,versionId,cmsMedia,mediaPath,cmsPreviewXml,nodeId,cmsPreviewXml,versionId,cmsPreviewXml,timestamp,cmsPreviewXml,xml,cmsPropertyData,id,cmsPropertyData,contentNodeId,cmsPropertyData,versionId,cmsPropertyData,propertytypeid,cmsPropertyData,dataInt,cmsPropertyData,dataDecimal,cmsPropertyData,dataDate,cmsPropertyData,dataNvarchar,cmsPropertyData,dataNtext,cmsTags,ParentId,cmsTask,closed,cmsTask,id,cmsTask,taskTypeId,cmsTask,nodeId,cmsTask,parentUserId,cmsTask,userId,cmsTask,DateTime,cmsTask,Comment,cmsTaskType,id,cmsTaskType,alias,cmsTemplate,design,umbracoDomains,id,umbracoDomains,domainDefaultLanguage,umbracoDomains,domainRootStructureID,umbracoDomains,domainName,umbracoMigration,id,umbracoMigration,name,umbracoMigration,createDate,umbracoMigration,version,cmsContentType,isElement,cmsContentType,variations,umbracoContent,nodeId,umbracoContent,contentTypeId,umbracoContentVersion,id,umbracoContentVersion,nodeId,umbracoContentVersion,versionDate,umbracoContentVersion,userId,umbracoContentVersion,current,umbracoContentVersion,text,umbracoMediaVersion,id,umbracoMediaVersion,path,umbracoDocument,nodeId,umbracoDocument,published,umbracoDocument,edited,umbracoDataType,nodeId,umbracoDataType,propertyEditorAlias,umbracoDataType,dbType,umbracoDataType,config,umbracoLanguage,isDefaultVariantLang,umbracoLanguage,mandatory,umbracoLanguage,fallbackLanguageId,umbracoDomain,id,umbracoDomain,domainDefaultLanguage,umbracoDomain,domainRootStructureID,umbracoDomain,domainName,umbracoLog,entityType,umbracoLog,parameters,cmsMacro,macroSource,cmsMacro,macroType,cmsPropertyType,mandatoryMessage,cmsPropertyType,validationRegExpMessage,cmsPropertyType,labelOnTop,cmsPropertyType,variations,umbracoPropertyData,id,umbracoPropertyData,versionId,umbracoPropertyData,propertyTypeId,umbracoPropertyData,languageId,umbracoPropertyData,segment,umbracoPropertyData,intValue,umbracoPropertyData,decimalValue,umbracoPropertyData,dateValue,umbracoPropertyData,varcharValue,umbracoPropertyData,textValue,cmsTags,languageId,umbracoExternalLogin,userData,umbracoRedirectUrl,culture,cmsContentNu,nodeId,cmsContentNu,published,cmsContentNu,data,cmsContentNu,rv,umbracoDocumentVersion,id,umbracoDocumentVersion,templateId,umbracoDocumentVersion,published,umbracoKeyValue,key,umbracoKeyValue,value,umbracoKeyValue,updated,umbracoContentVersionCultureVariation,id,umbracoContentVersionCultureVariation,versionId,umbracoContentVersionCultureVariation,languageId,umbracoContentVersionCultureVariation,name,umbracoContentVersionCultureVariation,date,umbracoContentVersionCultureVariation,availableUserId,umbracoDocumentCultureVariation,id,umbracoDocumentCultureVariation,nodeId,umbracoDocumentCultureVariation,languageId,umbracoDocumentCultureVariation,edited,umbracoDocumentCultureVariation,available,umbracoDocumentCultureVariation,published,umbracoDocumentCultureVariation,name,umbracoContentSchedule,id,umbracoContentSchedule,nodeId,umbracoContentSchedule,languageId,umbracoContentSchedule,date,umbracoContentSchedule,action\r\n
\r\nThe following constraints (Primary Keys, Foreign Keys and
Indexes) were found in the database, but are not in the current
schema:\r\nFKcmsContentcmsContentTypenodeId,FKcmsContentumbracoNodeid,FKcmsContentVersioncmsContentnodeId,FKcmsContentXmlcmsContentnodeId,FKcmsDataTypeumbracoNodeid,FKcmsDataTypePreValuescmsDataTypenodeId,FKcmsDocumentcmsContentnodeId,FKcmsDocumentcmsTemplatenodeId,FKcmsDocumentumbracoNodeid,FKcmsMediacmsContentnodeId,FKcmsMediaumbracoNodeid,FKcmsMembercmsContentnodeId,FKcmsMemberumbracoNodeid,FKcmsPreviewXmlcmsContentnodeId,FKcmsPreviewXmlcmsContentVersionVersionId,FKcmsPropertyDatacmsPropertyTypeid,FKcmsPropertyDataumbracoNodeid,FKcmsPropertyTypecmsDataTypenodeId,FKcmsTagscmsTags,FKcmsTaskcmsTaskTypeid,FKcmsTaskumbracoNodeid,FKcmsTaskumbracoUser,FKcmsTaskumbracoUser1,FKumbracoDomainsumbracoNodeid,FKumbracoNodeumbracoUserid,FKumbracoContentumbracoNodeid,FKumbracoContentcmsContentTypeNodeId,FKumbracoContentVersionumbracoContentnodeId,FKumbracoContentVersionumbracoUserid,FKumbracoMediaVersionumbracoContentVersionid,FKumbracoDocumentumbracoContentnodeId,FKumbracoDataTypeumbracoNodeid,FKumbracoLanguageumbracoLanguageid,FKumbracoDomainumbracoNodeid,FKumbracoLogumbracoUserid,FKcmsMemberumbracoContentnodeId,FKcmsPropertyTypeumbracoDataTypenodeId,FKumbracoPropertyDataumbracoContentVersionid,FKumbracoPropertyDatacmsPropertyTypeid,FKumbracoPropertyDataumbracoLanguageid,FKcmsTagsumbracoLanguageid,FKcmsContentNuumbracoContentnodeId,FKumbracoDocumentVersionumbracoContentVersionid,FKumbracoDocumentVersioncmsTemplatenodeId,FKumbracoContentVersionCultureVariationumbracoContentVersionid,FKumbracoContentVersionCultureVariationumbracoLanguageid,FKumbracoContentVersionCultureVariationumbracoUserid,FKumbracoDocumentCultureVariationumbracoNodeid,FKumbracoDocumentCultureVariationumbracoLanguageid,FKumbracoContentScheduleumbracoContentnodeId,FKumbracoContentScheduleumbracoLanguageid,PKcmsContent,PKcmsContentPreviewXml,PKcmsContentVersion,PKcmsContentXml,PKcmsDataType,PKcmsDataTypePreValues,PKcmsDocument,PKcmsMedia,PKcmsPropertyData,PKcmsTask,PKcmsTaskType,PKstructure,PKumbracoDomains,PKumbracoMigration,PKumbracoNode,PKumbracoContent,PKumbracoContentVersion,PKumbracoMediaVersion,PKumbracoDocument,PKumbracoDataType,PKumbracoDomain,PKumbracoPropertyData,PKcmsContentNu,PKumbracoDocumentVersion,PKumbracoKeyValue,PKumbracoContentVersionCultureVariation,PKumbracoDocumentCultureVariation,PKumbracoContentSchedule\r\n
\r\nThe following indexes were found in the database, but are not in
the current
schema:\r\nIXcmsContent,IXcmsContentVersionContentId,IXcmsContentVersionVersionId,IXcmsDataTypenodeId,IXcmsDocument,IXcmsDocumentnewest,IXcmsDocumentpublished,IXcmsMedia,IXcmsPropertyData1,IXcmsPropertyData2,IXcmsPropertyData3,IXcmsTaskTypealias,IXumbracoMigration,IXumbracoNodeObjectType,IXumbracoNodeParentId,IXumbracoNodePath,IXumbracoNodeTrashed,IXumbracoNodeUniqueID,IXumbracoNodeUniqueId,IXumbracoNodeParentId,IXumbracoNodePath,IXumbracoNodeTrashed,IXumbracoNodeObjectType,IXumbracoContentVersionNodeId,IXumbracoMediaVersion,IXumbracoDocumentPublished,IXcmsDictionaryParent,IXumbracoLanguagefallbackLanguageId,IXumbracoPropertyDataVersionId,IXumbracoPropertyDataPropertyTypeId,IXumbracoPropertyDataLanguageId,IXumbracoPropertyDataSegment,IXcmsTagsLanguageId,IXumbracoUserLoginlastValidatedUtc,IXumbracoContentVersionCultureVariationVersionId,IX_umbracoContentVer etc ... " seems like all of the tables in the umbraco.sdf are
mentioned here
Upgrade is ridiculously complicated
I have now spent five days of my holiday trying to upgrade one web from Umbraco 7.10.4 to 8.10.1. I give up. It is ridiculous. There is a video series on Umbraco forum "Migrate an Umbraco Cloud project from 7 to 8". But it involves so many steps and is so vague that it is ridiculous. The approach is that everything should be "automatic" but when it doesn't work you are stuck.
The approach assumes you have an inline database in your App_Data folder. I don't as I think this is contrary to good practice with speed and deployment. If I manage my site for some days in my computer and then deploy some changes I will overwrite all data that has been updated on the site. Does some people actually work that way?
So I tried to copy my database from webhosting environment to new database. Doing this online remotely with Sql Seerver Managament keeps failing all the time because the process is far too slow. So what do I do then?
It is fine to rewrite all code. It is fine to do a lot of manual work adjusting pages to the new way of working. I just want help to transfer the data.
How hard can it be? The data format must be known. I just want someone to offer a simple tool that will extract DocumentType, DataType and MemberType from the old database and then import them to the new one. Then the same with nodes: Documents and Member. As a last step I want to convert my Media section to use the new format.
I prefer explicit conversion where I can specify what to convert and point to a connection string of a new resulting database.
Hi Jakob.
Really sorry to hear that you have had a bad experience migrating to v8.
What I can see differs from you explaination and Umbracos documentation on migrating is that your Umbraco 7 version has been too low.
According to the docs, you should have minimum 7.14 before starting migration: https://our.umbraco.com/documentation/getting-started/setup/upgrading/migrating-to-v8
Hope this can help a little bit.
And sorry I can’t help with anything else.
Yes, I am aware of that, so part of my time has been spent to try to upgrade from 7.10.4 to 7.15. But I didn't even come past that point :(
Have you thought about creating a package with all of your content and installing the package on your v8 install? I'm not 100% sure that will work, but that's what we do to install a bunch of boilerplate stuff every time we start a new project and it seems like that's what you're looking for basically.
Interesting idea. Never heard of this approach ...
Comment author was deleted
check out https://our.umbraco.com/packages/backoffice-extensions/converge-8/ this might be a good option migrate instead upgrade
This looks really good!!! I really like the approach of Stuart Mullinger. Exactly what I was looking for.
There is still some things lacking for me. I had to recreate my Member Types and there was some manual adjustment needed for Composition Types now needed to be defined as Element Types. But still most of it worked!!
Thanks for all concern.
I've done a few upgrades to v7 latest. If I remember 7.10 to 7.15 is doable.
Can you give more details on what steps you followed and what the error is?
Also had a project that needed upgraded from v7 to v8. I opted to start from scratch and manually port over the code, it took a bit of time but working in small increments helped.
I was stuck in the state where I could not copy the database content from one database to another. Now I started over manually the same way as you did. Slow but stable process :)
Glad you got over the hump.
This is a pretty good guide:
https://24days.in/umbraco-cms/2018/upgrading-umbraco/
Hi Jakob
And also anyone coming to this thread via google, I had problems migrating a site to the latest V8 a couple of days ago and this is because the migration script is currently broken to sites with a version > 8.6
This means you have to perform the migration in two steps, eg first to 8.5 and then upgrade again to V8 latest - but this isn't possible on Umbraco Cloud you can't provision a V8 site < 8.6
But there is a community plugin that works around the issues.
https://www.nuget.org/packages/ProWorks.Umbraco8.Migrations
I've updated the general migration documentation to reflect this:
https://our.umbraco.com/Documentation/Getting-Started/Setup/Upgrading/migrating-to-v8#known-issues
There is also a healthcheck for the V7 site, to run pre migration to identify other known problems that will stop the migration from working:
https://our.umbraco.com/packages/developer-tools/pre-migration-health-checks/
But you are not there yet :-(
What I can't tell from your V7 dilemma, is if you are on Umbraco Cloud or not, and the problem lies with getting a copy of the site database from the webhosting?
If it's Umbraco Cloud you ought to be able to get help upgrading from Umbraco support or get access to the database:
https://our.umbraco.com/documentation/Umbraco-Cloud/Databases/Backups/
via Sql Server Management Studio and use export data tier application. to get a backup - or is this what is taking toooooo long?
Before the migration script was a thing Callum Whyte gave a talk at codegarden about migrating from V7 to V8 using uSync:
https://www.youtube.com/watch?v=jjZ2mRB21yw
But if you can get your database, the upgrade from 7.10 to 7.15.6 should be painless, and as long as you install the two packages, the migration to V8 should work.
regards
Marc
Thanks for all well meaning help! It was a good exercise. After spending over a week on this I actually decided to give up. There is too much manual adjustment going on forever. My own conclusion is that I might give Umbraco 8 a go on next web project, but never try an upgrade again.
I couldn't agree more, so far it has taken me 3 weeks to get nowhere trying to migrate a 7.15.2 umbraco.sdf database to Umbraco 8+.
Hi Karen
How far have you gotten? it's a horribly convoluted process, has you installed the premigration healthcheck?
https://our.umbraco.com/packages/developer-tools/pre-migration-health-checks/
Are you getting as far as the migration stage, and are you getting a specific error?
Have found this Proworks article to be the best explained 'step through' set of procedures to follow:
https://www.proworks.com/blog/archive/how-to-upgrade-umbraco-version-7-to-version-8
It can be done, but it also depends on what packages you have installed on the V7 site too :-( ... it's why they don't call it an upgrade, but talk about there being a migration path - but lots of potential for things to go wrong, and likely something you'll only have to do once, so not useful knowledge to master!
But if you have a particular error will try to suggest a solution/workaround if I've seen it before!
regards
marc
Hi Mark, yes I've been following that very same article and have installed the premigration healthcheck, but nothing, not even sure if it's run (or if there is something else I'm supposed to do to get it to run). I've used the healthcheck tool in the dev/packages section to clean up the database, so I'm pretty sure that's ready to go, but nonetheless each time I tried to migrate the database it would fail (after hours of waiting for it). Yesterday installed ProWorks.Umbraco8.Migrations -Version 1.0.15 into clean copy of Umbraco 8.1.6 (via the package manager console) and it upgraded the umbraco application to the latest version at the same time (which I didn't want to do until I'd successfully migrated the database).
But I ran the migration again just in case, 2.5 hours later, it failed with yet another almost unreadable log file (json log files, obviously you can't read them unless you can get the Umbraco 8 CMS running, trying to read them using an online reader throws an error so I'm left with trying to work them out using text edit) Anyway, I'm now on something like my 15th iteration of this (this time going to install the pro migrations package not using the console to avoid it preempting the version upgrade).
Failing that I have to try to convert the umbraco.sdf into SQL db (if that'll help). Doubtful I will get this done before Christmas. Oh I've only got the recommended premigration packages installed on in the cms, nothing else
Do you perhaps have the error message that you are getting in the log file? I did have some issues with the migration as well due to the image versions missing (No idea, because images don't even have versions). But all fixed with an SQL script after that
Thanks Patrick, I'm halfway through a new attempt now so if (when) that fails I'll try to pick out the errors from the log and post them here. But it started with It started with: Error during installation The database failed to upgrade. ERROR: The database configuration failed with the following message: One or more errors related to unexpected data in grid values occurred. Please check log file for additional information (can be found in '/App_Data/Logs/') (a couple of times)
Then after tweaking finding other articles (I can't remember exactly) errors moved to: 1. tables were found in the database, but are not in the current schema 2. columns were found in the database, but are not in the current schema Got those errors a few times (each time after a couple of hours of the migration running. But yesterday the error was different but I assumed it was because I'd installed the Proworks tool via package manager console rather than Nuget package manager - oh and also got told by my colleague to avoid 3rd party packages :) (have to laugh).
but yes, the only packages installed in the CMS are the migrations tool and the health check.
Hmm, could it be that the table definitions have been changed by any of the developers? That might be causing some issues.
Does it state something about which table is wrong? Or what migration is currently running?
we feel your pain :-(
Once the premigration package is installed in the V7 site and before you attempt migration
visit the backoffice developer section, and find the 'Health Check' tab and click 'Check All Groups'
that will run the premigration healthcheck and it will report if any of the common database and content issues that muck up migration are present in your db.
The instructions and steps are all geared around the database being on a SQL Server, and so the encouragement is to spin up a separate visual Studio solution and install V8.1 into that and point it at the database... but you can't as it's a sdf file! in the V7 solution
So I think you'll need to copy your V7 sdf file into your V8.1 solution (with the proworks package installed) and update the V8.1 connection string to point at it, to trigger the migration in the context of the V8 solution...
is that how you are fangling it?
regards
Marc
thanks Mark, yes I did that, and checked all Groups and according to that the database is now fine. Yes, that is what I've been trying to do with the umbraco.sdf, just change the config to point to it, migration process starts runs for about 2.5 hours then I get an error and the log is fairly consistently reporting what I've posted below. It did this without ProWorks.Migrations installed as well. I will take another walk around the 7.15.7 cms and see if I can see what it's talking about viz the grid editor datatype thingy, but not at all confident. Thanks for your help anyway. I feel a little more sane for the conversation, at least!
Hi Karen
yeah, it's not you!
this bit
Cannot deserialize the value as json. This can be because the property editor type is changed from another type into a grid. Old versions of the value in this property can have the structure from the old property editor type.
Usually means that there was a property editor on the site, perhaps it was called BodyText and perhaps it was a rich text editor, and then people put loads of content into different pages using it and published it... and then one day somebody decided to use 'the grid' instead, and they switched the underlying property editor for BodyText from RichTextEditor to Grid.
The Grid stores data in JSON format, the RichTextEditor would be a string of HTML
When the switch is made - Umbraco doesn't go through all the existing content pages that use BodyText property and update the saved format of the data to be the grid, the saved values only get updated to use the grid JSON format when the page is Saved by the editor.
So what this message is saying, is that one page or more, somewhere, after this switch was made, there is, saved in the database a page with that property, with it's value stored in the old non-json format.
So when the upgrade script encounters it, it knows BodyText should be in JSON format, and tries to deserialise it, to migrate it to the new V8 JSON format for grid, but can't cos it's just a string of HTML.
Soooooooo, do you know what property got changed and when? (bet not!!!)
What I'd normally do here, is query the database direct (which again helps if it's in a SQL database and not SQL CE file)
I'd find all the Data Types that use the grid in the backoffice, and make a note of their unique ids (from the querystring at the top)
and then I'd query the cmsPropertyValues database table, that stores all the values for properties, and look for any values for that data type where the stored value didn't start with a { json bracket...
then I'd get the Ids of the document nodes that those property values were on, and go via the backoffice to edit them, and save them with the grid, or if there are thousands, maybe try something programmatically...
does that explain the issue? obviously might not be a rich text editor, but it's most likely change to grid...
regards
Marc
Hi Marc, Yes that does make sense! thank you The grids are supplied via Macros that have been developed (and upgraded over time by another dev) so although I went through the Developer datatypes to ensure system isn't using obsolete references and then checked the db using CompactView (which BTW, whilst not as good as SQL studio, does a reasonable job for reading and editing .sdf db's), i missed those.
The plan is to move this to SQL but haven't got an appropriate server available for it yet, and need to wait until systems guy gets back from holidays until we can do this. Either way, I will still need to fix these issues and now I have a plan thank you! ....
I was getting quite exhausted (and mental) looking at this so thank you so much!
kind regards
Karen
So I just notice that there is no way of installing ProWorks.Migrations without it automatically upgrading to Umbraco 8.14 (which we don't want to do until we've migrated the database and content and adding in our macros:
This error was generated when trying to migrate to the Umbraco 8.14+ site with Proworks installed
I've had this error before, and cannot find anything that relates in the CMS. All datatypes have been upgraded to latest and images in this site are only populated from targeted folders not by using image pickers etc. I'll take another look at the original CMS tomorrow. Also getting:
is working on a reply...