Well, a few things.
I'd suggest, just due to the 6 pages of changes for the upgrade to the database schema, that you do a regular upgrade without the name-change. Just get the community running properly.
Change the name:
Changing the name is pretty easy. It's the jiveURL property. You can change that in the setup of each web application cluster node (do one first and stand the entire thing up so it's solid, then setup the next node)
You'll need a rewrite rule in your load balancer (i'm assuming you're on-prem?) to say "all things for community 1 go to community 2" so everyone's bookmarks will continue to work.
The bookmark rewrite rule ( in apache terms) will have to become legacy as you'll probably not know who has bookmarked what.
That doesn't seem too hard. I agree that we should upgrade and then name change. The rest seems pretty simple. Will the internally linked documents, people, and content automatically redirect. For example, if I have a document that has the URL http://community1/docs/DOC-2423, will it automatically redirect to http://community2/docs/DOC-2423?
Theoretically it should. Assuming the apache front-end with the rewrite rule....your content isn't going anywhere, right? That means whatever was community1 is rewritten as community2.
Definitely do it on a QA/Staging/UAT solution first.
We went through this in the spring. We intentionally changed the name at the same time as the upgrade. It worked very well for us, as we emphasized how different the site would be after the upgrade. Given the significant changes to the UI from 4.5 to 5, that made sense.
Did you use Apaches internal rewriting or permanent redirects (HTTP 301)?
Using SSL this may be a little bit tricky as all SSL certificates expire one day.