There will probably be a period of time where the site will go down or at least the editor will not be able to produce content, so during night would be best. 

I would upgrade dev.environments first. Making sure the db from prod is running great on the new platform. When that is done you have at least a website running with all that you need and ready for deploy. 

Then do upgrade for a website, copy of production, you will probably need to do the process with deployment center. So install first 7 and then 7.5 on the server. Go through 7 and then up to 7.5, the latest releases is not that troublesome if you have the site up and running on 7.5.

If you managed to go throught the process with deployment center, you need to recompile and release new binaries. Since you have your dev.environment up and running already the final step should be to release the new code.

Earlier versions had the sqlscripts for upgrading the database so that you could run them manually. Not sure if that is possible but they probably is available. That could be a solution as well. But when you do the upgradeprocess with deployment center it will also fix the config-files for you. 

And of course always make sure you do a complete backup of your db:s and website including VPP.

Final step if you like is to convert the VPP to the new Blobprovider. You could of course do this but be aware that it might be a lot of work to fix all assets first since it is a complete new way of handling files and images.

Best of luck!

This is the process we usually do when upgrading:

1. Take a copy of the actual production site and setup on a developer machine / test server

2. Perform the upgrade on that one and document closely all errors you find. Check in all code changes in a separate branch so that you still can do support on the production site. 

3. Add any new requested functionality.

4. Setup a new "staging" site on their production environment and test the new functionality (don't switch the DNS yet though)...when the customer is happy...=> 

5. Inform the customer that for a few days (depending on how much new content they want to add mostly), their old site shouldn't be updated by editor / any xforms or similar input that is stored to database needs to be redirected to mail. 

6. Take a new copy of the production environment database and vpp files (always take both at the same time or you risk getting broken links btw). Perform the upgrade again using your log of errors from step 2.

7. Deploy changes again to your new "staging" site on production, test it

8. Switch DNS so that your new staging site is the new production site.

9. Merge changes to your trunk or similar...switch Xforms to store in database again if needed

It's often forgotten that the old server might be Win2003 or running on Everweb shared hosting which means an upgrade needs a new (or another) machine in production = which normally means DNS updates unless the network guys can work something out.

It's always less hassle if DNS records can remain the same when deploying the upgrade.