Hi Michael

I think it's to do with the scope/lifespan of objects - you can read more in Shannon's common pitfalls post:

https://our.umbraco.org/documentation/reference/Common-Pitfalls/

Essentially ApplicationContext is scoped for the lifetime of the application and is shared by all threads.

Whereas UmbracoContext is based on HttpContext bound to the current Http Request and can't be shared between threads.

So the obsoletion is just to make the distinction clearer, eg people may get used to accessing the ApplicationContext via UmbracoContext.Current.Application, however this won't work in a non HttpRequest context, eg a background task (gathering nodes event etc)

So the advice is, if you are in an Umbraco base class eg Surface Controller, use the Services. property as a gateway to Umbraco's api services...

var contentService = Services.ContentService;

.. and if outside of a special Umbaco base class, maybe some sort of custom service perhaps that needs to use the Umbraco Api Services, then construct your custom service class, so that the api service you need can be passed into it via the constructor (injecting the dependency)

public class MySuperUpdateService {

IContentService _contentService;

public MySuperUpdateService(IContentService contentService) {
_contentService = contentService;
}

}

or if you have to use singletons to access these contexts, then use their own constructs to do so eg

UmbracoContext.Current or ApplicationContext.Current

and not

UmbracoContect.Current.Application.