I have just upgraded this website from .NET 7 to .NET 8, and also the associated Azure function from .NET 6 in-process to .NET 8 isolated. Upgrading an app service (website) from .NET 7 (or 6) to .NET 8 is pretty straightforward and essentially just involves changing the target framework ...

For security reasons, you should not be storing production setting values in source control. But this means that by default, you don't have your own backup of the values for your live, production settings. What if you want to store a copy of your settings (e.g. along with the artifacts) ...

I was able to migrate a legacy project using .net framework and entity framework to .NET 7 and EFCore relatively easily. EFCore Power Tools was very useful in doing a first draft of model code from the existing database.

Upgrading a .NET 6 to .NET 7 app service seems very straightforward. Upgrading Azure functions to .NET 7 looks to be a more significant change, and might require some investigation first.

If your legacy code uses Entity Framework 6.3.3 or later, you don't necessarily need to move to Entity Framework Core at the same time that you move from .net framework 4.7/4.8 to .NET 6 or 7.

One possible solution to a "You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated" error might be to upgrade any older app services that are using older versions of .net framework.

Microsoft's Natural Language Processing LUIS apps seem to be deprecated in favour of CLU but are currently difficult to migrate. However the LUIS apps still seem to work - for now at least!

I have found app.diagrams.net useful for doing architecture charts to document and explain how the different components in a distributed application work together..

When deploying code, it is important to be able to have an easy way to check that the deployment worked and that the version deployed is the one you published. This is particularly important when deploying by swapping (e.g. from stage to production): in my experience, the swaps work about ...

In the Azure portal, for Azure Functions, I've found that the Monitor section for individual subfunctions is not infrequently a bit buggy, in that it misses out some function runs, particularly for functions trigged by a timer. To check whether the function actually ran on a particular day, check the logs for the function: they are usually far more complete.