While I definitely encountered some flaky behaviour with early 8.0 & 8.1 releases, reliability-wise I've not received any reports from my customers of issues with 8.2 or 8.3 and (as far as I am aware) all of them are running at least 8.2.1 now.
In certain aspects v8 is quite a bit different from the previous release and it can take a little getting used to. If you look in the document list you will find a document written by Sam Leidl which I have found to be a go-to recommendation for any of my customers migrating between 7 & 8 as it goes a long way to explain the difference between the way application defenses are implemented in the two versions. With v7 the service definition determined whether the service in question was going to behave as a proxy or a packet filter. Now this is handled completely by the application defenses.
It is important to understand that v7 (in the form of 7.0.1.03) is still in active support, it probably isn't going to live forever, so it is probably in your interest to start looking at v8 while have time to experiment and get used to the new envrionment. The upgrade process has been engineered in such a way that when a system is upgraded from v7 to v8 it should behave just as it did before. So, while the is the new application discovery and signature mechanism present in v8 an upgraded v7 Firewall does not have this functionality enabled. Some rules may be changed to accommodate the new application defenses implementation, but it should otherwise be identical.
I've been involved with v8 since its launch and am personally still eager for McAfee to clarify some of the changes in functionality and provide some clearer best practise documents. There appears to be a very specific relationship between rules using the SSL/TLS service (replacing the HTTPS service in v7) or indeed any service using TCP port 443 and the implementation of network address translation.
You will also become familiar with the all-too-frequent appearance of "Unknown TCP" in the audit. When implementing a rule using one of the new application-aware signature services, it is necessary for the firewall to pass a couple of packets through in order to be able to match the traffic to the signature. These initial packets, becuase the Firewall doesn't yet know what it is, will be logged as "Unknown TCP" (or UDP). I have encountered some client/server processes which do not seem to like this very much. I had one such example with a customer who decided to replace their old v7 appliance with a brand new appliance running v8. Because the configuration was quite simple in this case, the decision was taken not to upgrade, but to simply configure the new appliance from scratch. Pretty much everything went to plan and the transition was fairly painless. However, the customer reported one key service wasn't working. A DMZ host needed to establish a Kerberos connection to a domain controller on the Internal LAN. Because v8 has a Kerberos "Application", I chose to use this in the rule. But, when examining the audit, all I could see was traffic being logged against the nominated TCP port as "Unknown TCP". It appeared that the time the Firewall was taking to identify the Kerberos traffic as Kerberos traffic was too long for the DMZ host and it was terminating the connection as a result. In the end I resorted back to the old-school method of using a user-defined service using the same port numbers instead of referencing the Kerberos application signature. As soon as I did so the service burst into life. The really ironic aspect to this was that I was still running the Audit Viewer in order to see what was going on and after an initial entry showing the custom service being allowed through all subsequent entries referred to the service as "Kerberos" - go figure.
But there are clearly some very useful functions available in v8. The integration of transparent Windows authentication using the MLC (McAfee Logon Collector) has proved to be very popular with my customers as has allowed them to easily create Firewall rules based on AD username & group while the users are blissfully unaware and the new application signatures give you greater control over the ever-increasing number of services that use TCP ports 80 & 443 to communicate.
Hope that is useful.
I don't think you'll get a more complete answer on this than the one from Phil.
I will add in my own experience with 8.x which might help.
I installed from 8.2 clean iso then started to work my way through the patches to bring it up to date. At one point (can't remember which patch) it required a reboot and when the firewall came back it had lost all it's network cards (ifconfig showling only the psudo interfaces).
Lost a bit I struggled and managed to boot into some kind of safe mode (I know that's not the correct term) with a different kernel. Back in the admin console I could not uninstall the updates and just kept on plowing on to the next patch. Not sure if I got lucky but next reboot all the cards came back.
This was not a production firewall at the time, but I know that I won't be rushing to install 8.4 if it ever comes out...
Worth keeping in mind as you plan any migration. Always better to start with a fresh install (if possible) then migrate the rules across as there is always the posibility your config has a gotcha that might impact service when you plan the upgrade.
All the best