You should upgrade site where you have access to source code. After upgrade - it's pretty essential to have referenced correct EPiServer dlls within the web project. To reference correct EPiServer dlls you have to link your project code to those EPiServer dll during source code compile time. After you have managed to get upgraded site up&running locally / on test server / wherever, you should be good to proceed with re-deployment of new site version to the production environment.

Upgrade processes may never be easy and usually there is no silverbullet solutions. It may depend from case to case.

Thank you Valdis.

1) Not sure I understand what you mean by "you have to link your project code to those dll during source code compile time". The dlls are referenced in Visual Studio, but nothing more happens at compile time.

2) To be clearer about my request: The compiled site (aspx/ascx + dll + config files) is at one location. The Visual Studio Project with all code-behind (.cs) + aspx/ascx + config is at another location on my computer. When I run the upgrade with the Deployment Center, it's the compiled site which is modified. Should I copy all the changed files from the compiled site (dll + config) back to my Visual Studio project? It seems I also have to remove manually dlls from VS that have been removed on the compiled site by the Deployment Center..

Is there a reason behind "compiled site in one place, VS project in another one"? I bet you are using VS Publish? I suppose it would be easier to upgrade "on-site": directly VS project that is hosted in IIS.

But more or less - yes, newly added / changed files you should copy back to VS project, removed files remove from VS, and retarget (update packages from NuGet feeds) to correct version of EPiServer packages, if you are using NuGet to get EPiServer dll, which you should :)

Also question about database, VPP and AddOns - how are you going to handle those in context of getting back correct upgraded version to I bet source control?!