My team and I have attempted an umbraco upgrade to the latest stable 13.x.x on a production environment (at the time of work sign-off). We maintain three deployment environments for our client: - An internal test and a prep-prod/UAT environment. - Production All of these umbraco applications are hosted in Azure in the form of Azure Web Apps. Pre-Prod and Prod are the closes architecturally speaking as each have two app web apps: 1) An Administrative instance for the umbraco backoffice 2) A public facing instance of the website An upgrade on all environments prior to production has been relatively painless - allowing Umbraco to applicate the necessary changes to facilitate the upgrade to 13.0.3. Unfortunately, the same can be said about production: The production database contains significantly more content that that of the non-prod environments and could be a contributing factor to the SQL timeout exceptions observed in the installation splash screen and in the trace logs *Troubleshooting * There was two key issues that we resolved together on pre-prod: Ensuring that the .NET stack version on the Azure Web app was updated to v8 (which I did) Adding and increasing the **DistributedLockingReadLockDefaultTimeOut **values in the appsettings. I also came across one example of the issues with an Umbraco 13 upgrade as described in this Umbraco forms thread. The suggested remediation steps didn’t resolve my issue. If you have any ideas for next steps, I’d be appreciative. https://cdn.discordapp.com/attachments/1219659453012639856/1219659453155250196/fe0d208e-9f4d-4ae2-99b5-28a59d8d9fa0.png?ex=660c1b61&is=65f9a661&hm=a1dbe9908a72a51961dcb7b998f104e523489b853719e20c37f0b78a8229f598&

Hi Kieran! When upgrading, besides the appsettings, does the connectionstring that your application uses contain a Connection Timeout as well? If not, perhaps adding something along the lines of ';Connection Timeout=3600' could help extend the period Umbraco has to execute all the queries it needs to when upgrading, just for the upgrade process

Also double/triple/quadruple check that the connnection string is correct and the SQL user has access to the correct schema (be that

dbo

or something else).

Thanks both for your responses! Connectionstring does make use of a timeout and I have increased it (admittedly not that high). For the purposes of testing, the db user has owner permissions. My initial hunch was similar to yours @Sebastiaan but that's been ruled out by our IT department. I'll try cranking up the timeout value for starters and feedback with my findings 🙂

I could also imagine you want to try this upgrade against the live database locally first to see how long it actually takes. Additionally, when hosting on Azure (etc) the database server itself might be severely constrained as well so it would be good to check that you're not being throttled due to that.

@Corné Hoskam I've had success - albeit slow - with your suggestion to up the connection timeout. The upgrade did seem to hang after the "Installation is complete! Get ready to be redirect to your new CMS" message appeared and I was forced to restart the app. After this, I could sign into the backoffice with no issue. @Sebastiaan Exactly! My own machine is pretty limited on resources too ha, but with the size of the database used, it took a little over an hour or so to go end-to-end with the upgrade. Now it's a matter of planning for a further rollout in production. Thanks for taking the time out to assist. It's been most helpful 🤝

You're very much welcome, glad that we were able to help you out! 🙂