Umbraco-cms: Upgrade from v7 to v8.6+ throws exception on media URL migration

[benjaminc]

Overview

In trying to upgrade a database that uses RTEs and Grid heavily, the upgrade fails if I got directly to v8.6.0. It works if I first go to an earlier version, and then try to go to v8.6.0. The error is in the ConvertTinyMceAndGridMediaUrlsToLocalLink migration, on line 113.

Details

Umbraco version

I am seeing this issue on Umbraco version: v8.6.0, from v7.15.3

Bug summary

This is caused by the ConvertTinyMceAndGridMediaUrlsToLocalLink migration using a service reference to retrieve data instead of using direct database access. Thus when new columns were introduced in the AddPropertyTypeValidationMessageColumns migration, the service is trying to read from these new columns that don't yet exist in the database.

Steps to reproduce

Create a v7.15.3 database, and add Grid and RTE data that contain media links. Then try to upgrade the database to v8.6.0.

Expected result

The site is upgraded to v8.6.0 successfully.

Actual result

The upgrade wizard fails with the message "The database failed to upgrade. ERROR: The database configuration failed with the following message: Invalid column name 'mandatoryMessage'. Invalid column name 'validationRegExpMessage'. Please check log file for additional information (can be found in '/App_Data/Logs/')". Reviewing the trace log shows the following stack trace for that error:

System.Data.SqlClient.SqlException (0x80131904): Invalid column name 'mandatoryMessage'.
Invalid column name 'validationRegExpMessage'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at StackExchange.Profiling.Data.ProfiledDbCommand.ExecuteDbDataReader(CommandBehavior behavior) in C:\projects\dotnet\src\MiniProfiler.Shared\Data\ProfiledDbCommand.cs:line 223
   at Umbraco.Core.Persistence.FaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func) in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\FaultHandling\RetryPolicy.cs:line 172
   at NPoco.Database.ExecuteReaderHelper(DbCommand cmd)
   at NPoco.Database.ExecuteDataReader(DbCommand cmd)
   at NPoco.Database.<QueryImp>d__164`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Umbraco.Core.Persistence.Repositories.Implement.ContentTypeCommonRepository.MapGroupsAndProperties(IDictionary`2 contentTypes) in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\Repositories\Implement\ContentTypeCommonRepository.cs:line 192
   at Umbraco.Core.Persistence.Repositories.Implement.ContentTypeCommonRepository.GetAllTypesInternal() in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\Repositories\Implement\ContentTypeCommonRepository.cs:line 114
   at Umbraco.Core.Cache.AppCacheExtensions.<>c__DisplayClass0_0`1.<GetCacheItem>b__0() in C:\projects\umbraco-cms\src\Umbraco.Core\Cache\AppCacheExtensions.cs:line 22
   at Umbraco.Core.Cache.FastDictionaryAppCacheBase.<>c__DisplayClass21_0.<GetSafeLazy>b__0() in C:\projects\umbraco-cms\src\Umbraco.Core\Cache\FastDictionaryAppCacheBase.cs:line 285
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Umbraco.Core.Cache.WebCachingAppCache.GetInternal(String key, Func`1 factory, Nullable`1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, String[] dependentFiles) in C:\projects\umbraco-cms\src\Umbraco.Core\Cache\WebCachingAppCache.cs:line 174
   at Umbraco.Core.Cache.WebCachingAppCache.Get(String key, Func`1 factory, Nullable`1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, String[] dependentFiles) in C:\projects\umbraco-cms\src\Umbraco.Core\Cache\WebCachingAppCache.cs:line 40
   at Umbraco.Core.Cache.DeepCloneAppCache.Get(String key, Func`1 factory, Nullable`1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, String[] dependentFiles)
   at Umbraco.Core.Persistence.Repositories.Implement.ContentTypeCommonRepository.GetAllTypes() in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\Repositories\Implement\ContentTypeCommonRepository.cs:line 48
   at Umbraco.Core.Persistence.Repositories.Implement.MediaTypeRepository.PerformGetAll(Int32[] ids) in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\Repositories\Implement\MediaTypeRepository.cs:line 54
   at Umbraco.Core.Cache.FullDataSetRepositoryCachePolicy`2.GetAllCached(Func`2 performGetAll) in C:\projects\umbraco-cms\src\Umbraco.Core\Cache\FullDataSetRepositoryCachePolicy.cs:line 166
   at Umbraco.Core.Cache.FullDataSetRepositoryCachePolicy`2.Get(TId id, Func`2 performGet, Func`2 performGetAll)
   at Umbraco.Core.Persistence.Repositories.Implement.MediaRepository.MapDtoToContent(ContentDto dto) in C:\projects\umbraco-cms\src\Umbraco.Core\Persistence\Repositories\Implement\MediaRepository.cs:line 538
   at Umbraco.Core.Services.Implement.MediaService.GetMediaByPath(String mediaPath) in C:\projects\umbraco-cms\src\Umbraco.Core\Services\Implement\MediaService.cs:line 631
   at Umbraco.Core.Migrations.Upgrade.V_8_1_0.ConvertTinyMceAndGridMediaUrlsToLocalLink.<>c__DisplayClass3_0.<UpdateMediaUrls>b__0(Match match) in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\Upgrade\V_8_1_0\ConvertTinyMceAndGridMediaUrlsToLocalLink.cs:line 113
   at System.Text.RegularExpressions.RegexReplacement.Replace(MatchEvaluator evaluator, Regex regex, String input, Int32 count, Int32 startat)
   at System.Text.RegularExpressions.Regex.Replace(String input, MatchEvaluator evaluator)
   at Umbraco.Core.Migrations.Upgrade.V_8_1_0.ConvertTinyMceAndGridMediaUrlsToLocalLink.UpdateMediaUrls(Regex mediaLinkPattern, String value, Boolean& changed) in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\Upgrade\V_8_1_0\ConvertTinyMceAndGridMediaUrlsToLocalLink.cs:line 103
   at Umbraco.Core.Migrations.Upgrade.V_8_1_0.ConvertTinyMceAndGridMediaUrlsToLocalLink.Migrate() in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\Upgrade\V_8_1_0\ConvertTinyMceAndGridMediaUrlsToLocalLink.cs:line 59
   at Umbraco.Core.Migrations.MigrationBase.Umbraco.Core.Migrations.IMigration.Migrate() in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\MigrationBase.cs:line 73
   at Umbraco.Core.Migrations.MigrationPlan.Execute(IScope scope, String fromState, IMigrationBuilder migrationBuilder, ILogger logger) in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\MigrationPlan.cs:line 316
   at Umbraco.Core.Migrations.Upgrade.Upgrader.Execute(IScopeProvider scopeProvider, IMigrationBuilder migrationBuilder, IKeyValueService keyValueService, ILogger logger) in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\Upgrade\Upgrader.cs:line 67
   at Umbraco.Core.Migrations.Install.DatabaseBuilder.UpgradeSchemaAndData(MigrationPlan plan) in C:\projects\umbraco-cms\src\Umbraco.Core\Migrations\Install\DatabaseBuilder.cs:line 501

[hfloyd]

I had the same issue migrating from a 7.15.4 site to 8.6. What fixed it for me was to update "UmbracoPlan.cs" to move:

To<AddPropertyTypeValidationMessageColumns>("{3D67D2C8-5E65-47D0-A9E1-DC2EE0779D6B}");

up above the line:

To<ConvertTinyMceAndGridMediaUrlsToLocalLink>("{B69B6E8C-A769-4044-A27E-4A4E18D1645A}");

I think the issue is actually caused by a call to "MapDtoToContent()" - the v8.6 Dto assumes the existence of those DB columns which haven't been added yet.

This is a screenshot of the code with a debugger running:

The green highlight is where the error was bubbling up.
I've created a pull request for this: https://github.com/umbraco/Umbraco-CMS/pull/7940

[nul800sebastiaan]

Very interesting @hfloyd and I much prefer this change to the addition of a lot of code by @benjaminc 😃

However, I am wondering if we should use an intermittent DTO instead, I think that's what we used to do in v7. I'll need to have a chat at HQ and see what we want to do with this!

[jaddie]

Think it's a much nicer solution and defo agree as especially using SQL instead isn't pleasant as a thought 🙈

[genckastrati]

Hi all,

Just to confirm that this is also happening when upgrading from 7.15.4 to 8.6.1, as I just tried it today. Was hoping to migrate our cloud solution to version 8 this weekend hah!

thank you!
Genc

[jaddie]

@genckastrati Are you not able to do an upgrade to an interim version in the mean time, say 8.2 or 8.3 if I recall & then go to 8.6? Adding a hopping step version like this instead of going straight to 8.6 should allow the upgrade to take place

Cheers
James

[genckastrati]

@jaddie I did think of that but not sure how to do it locally from a version I've pulled from the Cloud. I did have a second thought before going ahead and upgrading to 8.6, gut feeling. What would be the safest way to do this? Pull the repo commit from version 8.5.x only and do the upgrade there, then move that MDF to 8.6.1?

[jaddie]

I'm not sure how things work in terms of messing with the Cloud if you are referring to all that Umbraco made gubbins, I don't bother with it, what you need to do however you do it, is grab a copy of say 8.2 or so, upgrade to it, the DB should then be modified as required, after which you can go straight to the latest version.

I'm not sure that you should have to mess with the direct versions of the original Umbraco source as you should be able to get the files needed from the releases page which should be all you need I believe, either that or just use NuGet to change versions.

https://our.umbraco.com/download/releases/850 for example :)

So for anyone else reading this until Umbraco at some point hopefully get round to fixing this irritating issue which hopefully won't be long considering how important it is the steps are below:

1. Get site DB & Files
2. Get all ready for the upgrade
3. Don't go straight to latest, instead upgrade to a version ranging from 8.2 -> 8.5
4. Run the upgrade for the DB & get through to the CMS to make sure it loads without issue.
5. Upgrade to the latest version of Umbraco now
6. Run latest DB upgrades & re-test in the CMS, it should now work as intended.

Let me know if you need any help :)

[c9mbundy]

Irritating - LOL - Migrating UaaS definitely brings its own set of additional challenges to this game.

[genckastrati]

Hi all, just to confirm this is also happening when migrating from 7.15.5 to 8.6.1. Same error appears:

The database failed to upgrade. ERROR: The database configuration failed with the following message: Invalid column name 'mandatoryMessage'. Invalid column name 'validationRegExpMessage'. Please check log file for additional information (can be found in '/App_Data/Logs/')

[genckastrati]

Hi! Are there plans to merge this fix into an upcoming version of Umbraco 8? Upgrading from 7 to 8 for the Cloud is still not possible. Thank you!

[genckastrati]

Hi all, confirming this is also happening when migrating from 7.15.5 to 8.6.2:

The database failed to upgrade. ERROR: The database configuration failed with the following
message: Invalid column name 'mandatoryMessage'. Invalid column name
'validationRegExpMessage'. Please check log file for additional information (can be found in
'/App_Data/Logs/')

[timlaughlin]

Confirmed 7.15.5 to 8.6.2

[benjaminc]

For all who have left a comment, be aware that you can still upgrade to v8.6.X right now, you just have to do it in two stages. First upgrade to v8.1, then once the DB has been upgraded apply v8.6.X. Multiple PRs have been submitted for this, so hopefully one of those will make it into v8.7 to allow for direct migration up from v7. I don't think we can expect a migration change in a patch release on v8.6.

[brano]

We had to install v8.1.6 instead of v8.1.0 because Umbraco migration was failing on this issue:
https://github.com/umbraco/Umbraco-CMS/issues/5852
The database failed to upgrade. ERROR: The database configuration failed with the following message: Invalid cast from 'System.DateTime' to 'System.ValueTuple2[[System.Nullable1[[System.DateTime, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Nullable1[[System.DateTime, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'. Please check log file for additional information (can be found in '/App_Data/Logs/')`

Basically you cannot upgrade your v7 Umbraco project (v7.15.1 in our case) directly to v8.6.3 for example, but you have to do migration from v7.15.1 to v8.1.6 first.
This information should be mentioned in official documentation & Umbraco TV videos because we had to find it out the hard way by trying migration many times with multiple v8 versions :)
https://our.umbraco.com/documentation/Getting-Started/Setup/Upgrading/migrating-to-v8
https://umbraco.tv/videos/umbraco-cloud/umbraco-cloud-tutorials/upgrades/migrate-an-umbraco-cloud-project-from-7-to-8/content-migration/

[brano]

Then you should be able to upgrade v8.1.6 to latest v8.6.3 for example.
Guys #H5YR for this migration code btw 🙌 5️⃣ 🚀
https://github.com/umbraco/Umbraco-CMS/blob/e4cba73decb53b9dacc509535f011e740c38728a/src/Umbraco.Core/Migrations/Upgrade/V_8_0_0/VariantsMigration.cs

[benjaminc]

If you want to work around this issue until one of the PRs fixing this is merged in, and you don't want to have to stop along the way, you can use the ProWorks.Umbraco8.Migrations package (with source code here). It works around this issue with a custom IMediaService implementation that is used only during the initial v7 to v8 upgrade, and isn't used after that. It also includes a bunch of fixes for the #7939 issue related to content that didn't get migrated properly from v7 to v8, which were in another PR that is still pending, #7957.

[dawoe]

@nul800sebastiaan what is the status of this one. We have some v7 to V8 migrations coming up.

[arknu]

@nul800sebastiaan Just hit this bug again. I can't believe that the relatively simple fix above hasn't been merged yet.

[jaddie]

The migration of Umbraco 7 to 8 is still tainted by the lack of effort from Umbraco's side, even though there are contributions that have already done the majority of the leg work when they couldn't be bothered, its quite interesting to see how many big players are moving away from Umbraco because of the slow and rigid way it is run with no ability to be dynamic whatsoever, apparently for a platform that is trying to get people on board and really grow especially in the enterprise world with big clients, sorting out a stable migration from their previous to latest version is not important --- try flying that one with any enterprise clients and wonder why they're still not even close to the same page as Sitecore who have already been .NET Core for a long time and are so big, I think even I am going to switch sides after trying so hard to fight Umbraco's corner in the web dev world.

In short of the above -- Umbraco don't change or adapt for what the users want, they do what they want at their own speed, if you want the various fixes and such, the majority of the time most things get worked on or fixed in Umbraco its because the community has done it so just make your own fork & merge everything in and maintain that instead it'll make your life far easier.

[benjaminc]

I realize it is an outside fix, but if you use the ProWorks.Umbraco8.Migrations package, you can get from v7 to v8 without an error.

[nul800sebastiaan]

I really understand the frustration, unfortunately we have many things we want to work and when prioritizing we need to work urgency vs. impact. In that regard, the impact is low, there's few user who are migrating to v8 and v8 has been out for 2 years now, with migration problems for only the unfortunate few, which indicates that it's not getting more urgent.

Of course this is not what you want to hear but I hope it give some insight in why this isn't prioritized higher.

Additionally: migrating safely without causing problems is terribly difficult, as we know, we thought we had done a good job at it when v8 was released.. until we found all kinds of people having strange databases that we didn't cater for. Trying to patch this all up and making sure that everyone else has no sudden errors (the people NOT migrating from v7) is a huge task.

Finally: indeed, Benjamin has a solution (that might need a bit of documentation? 😉) and there's other workarounds (https://github.com/umbraco/Umbraco-CMS/pull/6002#issuecomment-628825687) and options like using uSync (https://www.youtube.com/watch?v=jjZ2mRB21yw).

Wish I could give you the magic answer that we'll get around to fixing all migration issues but right now it's not in the cards any time soon I'm afraid.

[arknu]

@nul800sebastiaan We are certainly migrating sites whenever we have the chance, as v8 is much nicer to work with for both developers and editors. Maybe people aren't migrating because of bugs like this? Issues like this that make upgrading to the latest version should have a high priority. I should think that you would _want_ people to upgrade to the latest Umbraco whenever possible.

This issue isn't "for the unfortunate few". It is _every single site_ upgrading from v7 to v8.6+. Upgrading in multiple steps is a deployment nightmare.

I really can't believe that simple issues like this that have a tested PR submitted don't get fixed. What more do you have to do to help fix an issue, other than creating a PR? It is really disheartening as a community member to discover an issue, spend time creating a fix and submitting a PR, only to have it ignored for 6+ months. Not that I have submitted a PR in this case, but I know the feeling...

The package by @benjaminc is a great workaround, but it should not be necessary when upgrading from one version of Umbraco to another. One thing is that third-party packages can mess up migrations. That I can understand and work around. But the fact that a Core migration added in 8.6 doesn't take into account that a particular column might not exist is entirely fixable and preventable.

I can't help but feel that development of the opensource core Umbraco CMS has been de-prioritized in favor of Cloud, Heartcore and other commercial ventures. I know v9 (and yes, it's v9 and not v1!) is being worked on, but this issue has been open since April 2020...

[benjaminc]

Its pretty disrespectful to throw shade on the publicly available package I created to fix the problem I identified for you when your internal testing failed, and then submitted a tested fix for which you ignored, and so finally created a community package to fix the issue instead of just fixing it for myself, all because my one-off package to fix your hole doesn't have as much documentation as you'd like to see. That's pretty low.

And as has been said above, this isn't affecting just a few people. This bug actually affect EVERY upgrade that tries to go directly from v7 to v8.6 or above. So either you were an early adopter, or you hit this bug. There isn't any way around it, and it doesn't only affect you if you have a specific set of data. It affects every upgrade. If you haven't had more reports of it, that means one of two things: either your clients aren't upgrading to v8 or they are so used to poor service that they aren't even bothering to mention it to you anymore. Both of those should really be pretty chilling options to anyone who cares about their product.

[marcemarc]

Just run into this on 7.15.6 to 8.9.1 upgrade - doh! - will give the package a try!

if it all works then reckon we should update the version specific upgrade advice (https://our.umbraco.com/documentation/getting-started/setup/upgrading/version-specific) which I read first for any known gotchas

and also: https://our.umbraco.com/Documentation/Getting-Started/Setup/Upgrading/migrating-to-v8

to reflect the required migration steps until a fix can be organised, so people know before they plan a migration.

[nul800sebastiaan]

Its pretty disrespectful to throw shade on the publicly available package

Sorry it came off that way! It was just me wondering out loud how to use it, I'm sure it's great and I appreciate you picking up our slack here 👍

[nul800sebastiaan]

I've just had a look at the code involved here, I'll be honest I didn't look at it before. This SEEMS like a small change at least so it might be feasible to get this into a future release. I'll just need to wrap my head around it.. Not sure what the cause of the problem is and why the ordering needs to be different.

In the mean time, good suggestion to add this to the docs if there's an intermediate step (does it work to migrate from 7 to 8.5 and then 8.9/10?).

[marcemarc]

@nul800sebastiaan Yes, that's what people are saying, and the analysis, is basically a new migration was added in 8.6 that relies on a column existing, that won't exist in V7, until the migratons are run...

... so it's not a weird index naming thing from an Umbraco 4 site, which we all agree not worth chasing down!

and migrating to 8.2 first and then beyond will work.

Whilst' it's been 2 years since the V8 release, the release of the block editor has sparked people's interest, a very compelling feature! - and some of the fixes for nucache and load balancing in 8.6+ has increased confidence in the V8 series for larger sites, plus the progress and announcements on .net core, have all combined - so you may see a bit of an upswell in V7->V8 migrations, even though so much time has passed since the migration script was put together.

Anyway, I'll try in the morning and update the docs with what works.

[marcemarc]

@benjaminc Thanks so much for putting together the migrations package together and also of course sharing it! With the package in place, the migration was successful! - and it was just for a quick POC, so I wouldn't have had chance to work it out for myself.

I've updated the Umbraco 8 migration documentation page 'Known Issues' to detail the existence of the problem, and to describe the two workarounds, linking to the package:

https://github.com/umbraco/UmbracoDocs/pull/2975

So anyone attempting migration 'by the book' will at least be aware of the problem and can plan before finding themselves knee-deep in migration and googling to find the valuable information on 'this issue'...

I've also linked to the Pre Migration Healthcheck, which again is really useful took for spotting those database schema inconsistencies that crept in from really old versions of Umbraco that have been upgraded through all the versions!

As it's a one-time activity for most people, there is a pragmatic argument that it's not a high priority to continually make the migration from V7 to V8.x work forever, eg utilising Umbraco dev resources to consider and accept PRs that people have contributed that fix things like this - but it's essential to make sure that the workaround is then officially documented to manage expectations, to avoid people wasting time or 'giving up'. There could even be a line drawn in the sand, so the migration step says "looks like your upgrading to > 8.16 - migration isn't supported from 7 direct to 8.16... please migrate to 8.5 first, we're sorry but it's been 6 years... what took you so long etc"

With this particular issue though, it will be affecting V7 cloud users who might want to migrate to V8, so if there are lots of people still on V7 cloud, it might be good for the future if @nul800sebastiaan can squeeze the fix in somewhere.

[nathanwoulfe]

@marcemarc sensible as always - I agree it's not realistic for HQ to support 7=>8 migrations for all versions into the future. It's an opportunity-cost thing.

If this is a minor fix to merge, then it probably should be done. But I think a community supported package to compliment the core migration is important too - it can manage edge cases and oddities as they arise, and allows HQ to look ahead, rather than putting time into the past. So long as the package is included in the migration docs (which it is now), it feels like a sensible solution.

[c9mbundy]

@marcemarc Yes, with regards the Umbraco-Cloud issue, Umbraco stated that v7 sites are supported until Sep-30 2023, and the obvious problem with migrating a UC site is that your target is always going to be the latest version. There would need to be a well documented plan for UC if a 2-stage migration is required - e.g. create a local 8.5 site, migrate a local copy of the UC-v7 site to the 8.5 target, upgrade the migrated site to v-latest, merge that upgraded local site back to UC. There is a guide for moving a local v7 site to UC but this would need to be updated to deal with v8.

[hfloyd]

@c9mbundy, For Cloud-specific migrations, I have found that this documentation gives a good overview, but do agree that if you are starting from a new clone, that would be the latest v8, and the directions as written wouldn't work exactly.

https://our.umbraco.com/documentation/Umbraco-Cloud/Upgrades/Migrating-from-7-to-8/

[marcemarc]

There would need to be a well documented plan for UC if a 2-stage migration is required - e.g. create a local 8.5 site, migrate a local copy of the UC-v7 site to the 8.5 target, upgrade the migrated site to v-latest, merge that upgraded local site back to UC.

Yep that's what I'm trying to 'subtly flag' above :-P, for 'off cloud users' it doesn't really matter what the steps are, as long as they are documented and work, and you can jump through the hoops - but on Cloud you are kinda sold 'not having to jump through such hoops' - but whether it's made easy to move from Cloud V7 to Cloud V8 is more of a HQ strategy decision as it's a commercial product. It may be only 1% of cloud users are on v7 and 99% already on V8, so, unfortunately, it may be a case of diminishing returns... and support can always manually help people out migrating a cloud site with one-off advice - it's not impossible... but yeah, if it's 80% of sites on Umbraco Cloud are V7, and HQ have a strategy to try to encourage people to migrate to V8 asap - then that strategy will be more successful if the process is as seamless as possible, but that will require ongoing investment/effort in development/documentation.

The first thing we can do as a community is flag the problem
And if you reference the forum as an indicator, you can see a lot more people are moving to V8 from V7 than six months ago.

I'll mention it to @sofietoft to look at the Cloud migration page - but the update the the general migration advice page has now been merged:

https://our.umbraco.com/documentation/getting-started/setup/upgrading/migrating-to-v8

[jaddie]

Yeah, I couldn't agree more @arknu it certainly has seemed that way for quite a while, like the cloud gubbins getting features and not the open source variant its a shame considering the open source side is what "made" it. As for the upgrades, migrations from old versions of a product like this to the newer latest version should always work, not to mention its completely false to say its because of not anticipating people having such custom databases or whatever rubbish -- that should not affect Umbraco migrating its own data and tables over, not to mention we're talking about Umbraco's own data migrations not including 3rd party data, if 3rd party changes or so break it then it would be unreasonable to expect that to work or be fixed without issue.

In terms of saying that people are slow to upgrade or similar, its not really surprising in the instance of anyone dealing with either large companies or even small ones that have invested. The process of getting either of the 2 to put money into the upgrade effort is exceptionally hard to do, hence why 80-90% of the client sites I and many others work on are still V7. So no, its not that surprising to be migrating from V7 to the very latest version.

[c9mbundy]

@marcemarc I can't comment other other people's reasons for not migrating earlier, but I can say that we have quite a number of v7 sites on Umbraco-Cloud, and the primary reason we haven't yet migrated them to v8 is - COVID19. It made a huge impact on both our financial capacity to re-develop an existing v7 solution to v8 replacement, and our clients' desire to spend anything on a solution that is 'good enough' for their existing needs, as they just see the working solution and not the platform. Is v8 a better platform than v7? - absolutely - but do our clients actually need to upgrade their working solution right now? - probably not, which makes it a hard one to sell, and that obviously has a circular effect on the ability to finance development of it.

However, reasons for not upgrading aside, I'm not sure that UC sells anyone on not having to jump through hoops - or at least it doesn't for me - as Umbraco makes it quite clear from the outset that the 'product' is exactly the same, and so has the same requirements of devs. However, the Hosting-Deployment service (obviously what UC is) definitely has its own requirements, conditions and 'quirks', so yeah, that does need to be fully documented if an extra stage is going to be injected into the local migration process by not going direct from v7 to v8.latest. Complicating that, of course, if that UC itself is undergoing changes over the coming months, and so may require injecting its own updates into the process.

[c9mbundy]

@jaddie Not sure what you see as being 'variants' of Umbraco? UC is just a commercial managed Hosting-Deployment solution for Umbraco, and a direct alternative to other hosting services you can choose to deploy your Umbraco site to. The decision on whether or not to use UC comes down to its unique Hosting-Deployment feature-set and the value it provides to you. I have developed sites using the so-called 'open source' version of Umbraco, and then deployed to UC - same-same as far as the Umbraco part of it is concerned.