The number of times you practice the steps involved with an upgrade is directly related to its success.
I can’t emphasize enough the importance of refreshing your environments with production data. The majority of content files don’t necessarily have to be copied. The issue is mainly around the potential issues with data quality and upgrade duration measurements.
Write documentation as if you have been up for 24 hours and are stress out. Create lists and take screenshots. Make believe you are dumb and need step by step instructions, don’t cut corners. Also, don’t blow off any install messages: these can blow up upgrades.
It’s fine to have tech support on a support retainer for the cutover weekend, but I would try to do all of the actual pre work, testing, and troubleshoot. This is one of the best chances to learn more about your system, to gain an in-depth understanding beyond what the manuals or basic maintenance can offer.
Try to include as many individuals in on the upgrade procedures. Distribute the troubleshooting tasks among them.
Regression testing can get so bogged down in the weeds that larger issues are missed entirely. Try to design a multifaceted strategy that balances the number of tests with the likelihood that it would be affected by the upgrade.
Please don’t forget that the User base is not like you. Their PCs may not have been included in the last round of OS upgrades or patches. Their web browsers or java versions may be configured with different options. Their PDF viewer may be old.
If you have a multiple person team, keep one home and rested, ready to come in on the following day to deal with the post upgrade issues because there will always be some.