There are surely breaking changes 

https://world.episerver.com/documentation/upgrading/Episerver-CMS/10/breaking-changes-cms-10/

https://world.episerver.com/documentation/upgrading/Episerver-CMS/cms-11/breaking-changes-cms-11/

upgrading to a major version is a big task, I would suggest you to try it out on your development environment to get used to it. 

Hi Jonathan,

Last year I moved a project from CMS 8 to v11 and I didn't find the experience too bad (Commerce 7-12 on the other hand...a lot more painful).

As QM points out, there are definitely breaking changes, but how much impact they have will depend on how much your site relies on those areas - I've done similar upgrades where the sites were barely effected, and others where quite a lot required fixing.

Don't forget that you always have the option of upgrading incrementally, i.e. going from 9 to 10, then 10 to 11, fixing changes along the way. It is possible to do it all in one big leap but if it's your first time performing an upgrade, you may find the incremental route easier. There isn't too much overlap between the 10 and 11 changes, so you wouldn't be re-treading old ground.

In regards to updating the database, this guide may help - https://world.episerver.com/documentation/Items/Installation-Instructions/Installing-Episerver-updates/updating-configuration-and-database-schemas/

You can probably ignore the config transform part as that happens automatically through Nuget, whereas the database schema changes aren't automatic unless you've already set that option in config (which the article also explains).

Hope that helps :)

- JJ

Breaking changes are mentioned above..

I would suggest the following procedure:

• That you first upgrade to last version of Epi 9 and solve build warnings that concerns obsolete methods.
• Secondly to the last version of Epi 10 and solve build warnings that concerns obsolete methods.
• Lastly to 11 and solve build warnings that concerns obsolete methods.

Episerver is usually quite good at giving warnings on methods that might be removed in upcoming major versions.

Hello

I performed an upgrade of our CMS a few months ago from version 10 to 11. I took a copy of the code base and created a DB copy as well as once you run locally, all your DB schema changes will run on your local database also (and on the next environment when you push it). So take a copy of DB, point to that in web.config and take a code branch to allow yourself to work on this while continuing work on the production code in the meantime.

update target framework of .net to 4.6.1

unsupported packages- if you are using unsupported packages in next version remove or replace with the newer version. This may or may not apply.

upgrade episerver CMS nuget packages to latest version, dependency lowest

upgrade episerver.forms to latest

I had to update Geta.SEO.Sitemaps to version 3.0

We had a lot of external dependencies which I removed one by one and replaced with nuget packages, this will depend on your solution

Breaking changes at compile time are mostly easy to deal with, some involve removing overrides that no longer are supported, but mostly you can easily find the solution for these compile time errors.

Runtime error - we got a 500 error and it was related to the site header block controller returning a partial view - we had "return Partialview(SiteHeaderBlock)" instead I changed it to return PartialView(nameof(SiteHeaderBlock), currentBlock)

Escaped HTML markup - basically in some blocks the html started to render w/ markup (like a visible <br> tag). You can either change the @Html.PropertyFor(m => m.theTExt) to @HtmlRaw(Model.theText) or else if your cshtml is actually saying @Model.theText directly, you can say @Html(Xhtml(Model.theText)). For me now I add only XHTML string properties if people need to include HTML tags in their text going forward.

Other Issues I had

1) Add-Ons in CMS stopped working. Solution- the version of episerver.cms.packaging was different to episerver.cms.packaging.ui version, make them the same version

2) IF YOU USE CUSTOM REDIRECT MANAGER- export all your redirects initially before upgrade, at least for us, this tool (geta tool) wiped out all custom redirects. it is an easy fix provided you first EXPORT ALL REDIRECTS before upgrade. Luckily we had a recent xml file and could easily import them back in. We have many redirects so for us this was an issue, but may not be for you.

3) tinyMCE editor now will by default have only the very most basic of options. So in my case, my CMS editor had a lot of issues w/ missing functionality in the tiny MCE editor such as not having code view, not having cut paste, format options and such. In order to provide them with what they were used to having, I had to write some code to run on initialization to override the base tinyMCE options. I will share more detail on what I did for this if you like.

Good luck!