Color me cautious ... but here's how I just upgraded from 4.5.5 to 4.8.4 yesterday. I don't go to quite these extremes for every case but when it's critical to a client, it's critical ...
Put up app_offline.htm and as Sebastian noted recently make sure it is over 512 kb in size so that it works. Do it now and leave it there so no one updates website content in the interim. Then I backed up the database and I backed up the file system. I downloaded the backup files for the database and the file system. I created a new database locally and restored the downloaded database over it (forced). I unzipped the file system into a newly created directory. I altered the web.config file in that directory to aim at the database I had just restored. I ran a script on the database to change the dbo to the user specified in the connection string that is in web.config. I inserted some records into portalalias table so it would take "localhost/SomeValue" and "localhost/SomeOtherValue" and aim incoming requests to the correct portals so I could test them. I created virtual directories in IIS match those alias values. If they are the same as the real portal names then paths to images etc will work; otherwise they won't; but that's not critical for this at any rate.
Now I can navigate to the portals on localhost at the current DNN level 4.5.5. I don't need to do much testing - just that it works is good enough. Couple-three-four pages on each portal and I'm satisfied. I have a very nearly exact local copy - exact enough in any way that matters.
Now I upgrade locally to 4.84 ... and it goes just fine. But if it didn't i would note any issues and work through them. I can drop the file system and database locally and do it over as many times as it takes to get it right. But it only takes one time and a few minutes.
I still have the original backkup files for both the database and the file system in case anything goes wrong on the production site. So now I go ahead and proceed to upgrade the production site. It goes fine, too, and I'm done.
I'm not addressing all the details of each step - just giving what I think is the responsible and right way to approach such an upgrade for an important production instance. These are steps I have followed since the days of DNN 110 and following.
Considering that the file system for this install is 400Mb when zipped and the database is 57Mb when zipped ... most of the time involved was backing up and downloading and unzipping and setting up, etc. Had I skipped all the cautionary steps and just done the upgrade, I'd have been done in 20 minutes or less.
Considering all that is involved in what I describe above, and the fact that everything went along right at each step (except when my laptop battery died in the middle of a download) ... I have to say that the DNN upgrade process really does work very nicely. Makes me think that I kind of over did it in the anal department. But I am not at all interested in rolling back even though I could. I prefer to go forward only with strong confidence that it is real progress and that I've really covered all the bases. So that is how I do it for my most critical installs.