I have also had issue with determining good reliable info on this topic.
And I'm part-way through the upgrade process, so thought I'd give you notes on my experience so far...
We have had 8.6 on Ubuntu 14.04 for years, but with the Zimbra version going out of support (and 14.04 too), I needed to try and move it up.
Our config is a VM, so preserving states between each change stage has been an absolute lifesaver, as not everything goes as planned.
Our original plan was:
1. Temporarily disable the (separate hardware) firewall's email NAT rules, to prevent intermediate message delivery to our system (prevent loss in case of system role-back)
2. Shut down VM and copy it to a named backup.
3. Upgrade Z.8.6 to Z.8.7 (to gain Ubuntu 16.04 support). This adds custom repo's for Zimbra.
4. Shutdown and take another copy of the VM's disk image.
5. Upgrade Ubuntu 14.04 -> 16.04
6. Take another VM copy
7. Upgrade Z.8.7 -> Z.8.8
In reality, I completed up to step 4 without any issue (very early one morning), so we now run Z.8.7 (though it has a new bug with some replies getting inline images attaching multiple times). However, the upgrade of Ubuntu to 16.04 did not go well (for Zimbra; the Ubuntu system itself was quite happy), with it removing the Zimbra repo's again (I think) and the Zimbra zmcontrol (required for any further Zimbra upgrading) not being able to run.
I had tried the suggestion from this forum post
viewtopic.php?f=13&t=60084 about the perl libraries, but it didn't help. I have several others bookmarked to re-review.
As I had at that point been at it for 4 hours from a 5:30 AM start and was starting to get brain-fade (and feeling like I would be grasping at straws trying to resolve things), I rolled-back the server to the (working) 8.7 on 14.04 state and re-enabled the firewall rule and tested mail delivery/user access again.
I see many suggestions to build a new server and use the trial edition of ZeXtras backup/migrate to move the accounts to the new version. I may investigate this more deeply, but server avaliability/resource pressure doesn't always make this a paractical option, along with business-continuity concerns;
Assuming there's asystem available to use, it's availability of network ports, disk space, impact of the server domain name + internal IP address, possibly also public DNS and firewall NAT settings (if originals cannot be retained/migrated), impact on DKIM, can TLS/SSL certificates for the server also migrate, and so on.
Doing an in-place upgrade is documented as supported (sort of - it's definitely implied) - but we still see so many questions (including my own) on the failures.
It's frustrating, but then again, we are getting a lot of capability for free...
