I'm currently using Umbraco version 7.3.8 with 50+ sites along with multilingual capablity using vorto components and am looking to upgrade to the version, Umbraco 10. I would appreciate any guidance, tips, or best practices from those who have already made this transition.
If you have experience with this upgrade or can point me to relevant resources, it would be incredibly helpful.
Additionally, if there are any potential challenges I should be aware of or specific steps to follow, please share your insights.
There is no 'upgrade' path to V10, but you can migrate the existing content and media in the Umbraco database to the new database formats and reimplement your site in Dot Net Core / new Umbraco syntax.
Then you'd need to migrate again to V10, to get all your content and media migrated to the later database format.
The problem you then have, is if you have third party property editors - that aren't compatible with V10 - eg Vorto! then you may have migrated the content and media associated with them, but V10 doesn't know how to work with content stored in that way! So you'll have to choose an alternative property editor, and then migrate the data stored from the old property editor format into the new equivalent property editor format.
Something like Vorto can be problematic because although V10 has the new Variants approach to editing languages that is similar to Vorto, it doesn't currently vary on a block by block basis - so if you have Vorto within Stacked Content or the Grid on your site, there isn't a direct modern equivalent... the clever leftfield workaround is that Vorto stores it's property data in exactly the same way as the Nested Content property editor, and so you 'can' switch it to be nested content items for each language, it's clumsy but it works!
But I think, because you have 50 sites, it's going to be long long big bang process, with lots of issues, to take the official approach...
... so your other option would be to use uSync Migrations:
This uses uSync Content Edition to export out all your content and media from your V7 site into files on disk, then uSync Migrations has lots of migrators (also the community keep adding to it, so even obscure property editors have migrators now) that will migrate the content from a legacy content format into a modern equivalent, it then uses the functionality of uSync Content Edition in the V10 version to import the migrated content, doctypes, media etc into your new site.
You'll still need to reimplement all your views and code etc, but this is done in one hop so it's much quicker than the official process. You will lose 'history' of who edited what when, if that is important (keep an archive of the old V7 site somewhere).
What I think might be good in your scenario for this approach is you might be able to tackle your sites, one site at a time, eg only migrating the content for one site, and reimplementing then doing the same for a second site etc, which would break down the scariness of testing 50 sites all in one go!
I built my own import export routine. Would recommend usync now ;)
I have done a subsequent one using uSync Migrations for the doc types alone. Was much smoother. Using source control and manually tweaking various bits to get it in a state I wanted then importing the content later (via my custom stuff).
Basically standing up a v10 site - creating a DB backup and then importing and tweaking, rolling the db back until I was happy - new backup. Then running my custom content import and tweaking until happy again (rolling back where necessary).
I needed a custom process as the data structure was changing quite a lot too - and we wanted to leave behind lots of legacy.
Some things that caught me out.
Media - having a way to import just what I needed, keep any folder structures / create new ones.
Media - there was direct linking of pdfs that were scoring well on Google - the media library folders have moved from numeric IDs to a text string. Easiest solution was to import - and then identify missing 404s and just copy in those numeric folders that were required. (Web spider will help here). Just having these folders and pdfs in the media folder means they still get served. There were too many to bother with rewrites for now
Image crops - made no attempt to remap these. Customer was happy with this.
Very complex "blocks" / modules. It was a modular site (sounds like yours). I run some quick scripts to count which blocks were used and how often. Very complex ones infrequently used I didn't bother trying to write an import to map to the new structure - just created an empty block / or a placeholder. Handed a list to the editors to hand copy and paste / recreate.
I think my findings were - if you're going to have to do a big change then use it as a chance to restructure / tidy up legacy and have on hand some keen editor resource to fix issues via exception reports.
The good news is now the site runs faster than ever, I can more quickly fix issues (as I'm super familar with everything) and I won't have to do this again for hopefully another 5+ years :)
uSync migrations was the game changer for us, it made an upgrade from umbraco 7 for our main corporate website a genuinely viable option without compromising content editors with unreasonable delays.
Some of my takeaways...
Take an initial back-up of your production database and download the uSync migrations source and work local to build a working prototype. Concentrate on getting the schema right first (doctypes) before moving to content & media.
You'll need to write migrators for any property editors/datatypes not supported.
It's not a full-proof process, particularly on a complex project. uSync migrations failed to convert one of our properties and I couldn't get to the bottom of why it was failing on one text field for social media. So I decided to drop it in favour of getting the project over the line.
I recommend auto converting nested content to blocklist, that part worked flawlessly!
Remember, along with the significant architectural changes, you'll be doing a lot of refactoring of your controllers and views.
Dive into the documentation (which is pretty good) and build in as many of the recommendations around new working practices as you can from the start. This way you'll end up with something that feels fresh rather than a bit of a compromise!
Want to upgrade umbraco from 7.3.8 to 10 version.
Hello All,
I'm currently using Umbraco version 7.3.8 with 50+ sites along with multilingual capablity using vorto components and am looking to upgrade to the version, Umbraco 10. I would appreciate any guidance, tips, or best practices from those who have already made this transition.
If you have experience with this upgrade or can point me to relevant resources, it would be incredibly helpful.
Additionally, if there are any potential challenges I should be aware of or specific steps to follow, please share your insights.
Thank you in advance for your assistance!
Hi Kare27
What a scary prospect!
There is no 'upgrade' path to V10, but you can migrate the existing content and media in the Umbraco database to the new database formats and reimplement your site in Dot Net Core / new Umbraco syntax.
The steps to get the content to V8 are here: https://our.umbraco.com/Documentation/Fundamentals/Setup/Upgrading/migrating-to-v8
Then you'd need to migrate again to V10, to get all your content and media migrated to the later database format.
The problem you then have, is if you have third party property editors - that aren't compatible with V10 - eg Vorto! then you may have migrated the content and media associated with them, but V10 doesn't know how to work with content stored in that way! So you'll have to choose an alternative property editor, and then migrate the data stored from the old property editor format into the new equivalent property editor format.
Something like Vorto can be problematic because although V10 has the new Variants approach to editing languages that is similar to Vorto, it doesn't currently vary on a block by block basis - so if you have Vorto within Stacked Content or the Grid on your site, there isn't a direct modern equivalent... the clever leftfield workaround is that Vorto stores it's property data in exactly the same way as the Nested Content property editor, and so you 'can' switch it to be nested content items for each language, it's clumsy but it works!
But I think, because you have 50 sites, it's going to be long long big bang process, with lots of issues, to take the official approach...
... so your other option would be to use uSync Migrations:
https://github.com/Jumoo/uSyncMigrations
This uses uSync Content Edition to export out all your content and media from your V7 site into files on disk, then uSync Migrations has lots of migrators (also the community keep adding to it, so even obscure property editors have migrators now) that will migrate the content from a legacy content format into a modern equivalent, it then uses the functionality of uSync Content Edition in the V10 version to import the migrated content, doctypes, media etc into your new site.
You'll still need to reimplement all your views and code etc, but this is done in one hop so it's much quicker than the official process. You will lose 'history' of who edited what when, if that is important (keep an archive of the old V7 site somewhere).
What I think might be good in your scenario for this approach is you might be able to tackle your sites, one site at a time, eg only migrating the content for one site, and reimplementing then doing the same for a second site etc, which would break down the scariness of testing 50 sites all in one go!
regards
marc
Not quite 50 but had 8 or so.
I built my own import export routine. Would recommend usync now ;)
I have done a subsequent one using uSync Migrations for the doc types alone. Was much smoother. Using source control and manually tweaking various bits to get it in a state I wanted then importing the content later (via my custom stuff).
Basically standing up a v10 site - creating a DB backup and then importing and tweaking, rolling the db back until I was happy - new backup. Then running my custom content import and tweaking until happy again (rolling back where necessary).
I needed a custom process as the data structure was changing quite a lot too - and we wanted to leave behind lots of legacy.
Some things that caught me out.
I think my findings were - if you're going to have to do a big change then use it as a chance to restructure / tidy up legacy and have on hand some keen editor resource to fix issues via exception reports.
The good news is now the site runs faster than ever, I can more quickly fix issues (as I'm super familar with everything) and I won't have to do this again for hopefully another 5+ years :)
Hi Kare27,
I have done this with a huge project developed by another company. Send me a private message and maybe I can help with tips or code examples.
Johan
Hey Kare27
uSync migrations was the game changer for us, it made an upgrade from umbraco 7 for our main corporate website a genuinely viable option without compromising content editors with unreasonable delays.
Some of my takeaways...
Take an initial back-up of your production database and download the uSync migrations source and work local to build a working prototype. Concentrate on getting the schema right first (doctypes) before moving to content & media.
You'll need to write migrators for any property editors/datatypes not supported.
It's not a full-proof process, particularly on a complex project. uSync migrations failed to convert one of our properties and I couldn't get to the bottom of why it was failing on one text field for social media. So I decided to drop it in favour of getting the project over the line.
I recommend auto converting nested content to blocklist, that part worked flawlessly!
Remember, along with the significant architectural changes, you'll be doing a lot of refactoring of your controllers and views.
Dive into the documentation (which is pretty good) and build in as many of the recommendations around new working practices as you can from the start. This way you'll end up with something that feels fresh rather than a bit of a compromise!
is working on a reply...