it means you can upgrade directly from v 14.1.x to 16.1.x .
> also there is a website or a tool called F5 Bug scrub tracker , you can choose V 16.1.3.5 and check all bugs on it before performing upgrade, by the way you can check any target version you want to upgrade to.
Hi, I did this resently, its very simple and worked for me even on my BEST licensed BIG-IP's.
The one thing of warning just to be prepared for is that i found some of my older BIG-IP that were installed from older 14.1.x images wanted to have the license file reuploaded or in my case reset by support (i don't keep the license files) before they took the config and allowed me to rebuild the cluster.
Something i'm glad i knew before i hit my production deployments! As our place gets really ratty when you have a degraded cluster whlist sorting.
As others have mentioned, every version is going to have bugs. Which ones impact you are going to be specific to your environment. That being said, I can share my experience as I went through a similar upgrade path a few months ago (14.1.5.1 to 16.1.3.4)
The main issue we had was a few of our virtuals were using TCP WAM profiles. This caused the upgrade to fail and it was a mess because it wouldn't load even after after manually modifying bigip.conf. We had to roll back, update the virtuals to use different profiles, then start the upgrade again. I recommend auditing your virtuals to see if any of them are using TCP WAM profiles and change them to another profile before you upgrade. This KB has more info: https://my.f5.com/manage/s/article/K30113094.
We also ran into a minor issue on our GTMs where several GTM pool members that were legitimately down would continuously log status change events going from a 'down' status to a 'down' status. This was only noticed because we had Splunk alerts that triggered off of these events. I can't find the bug but I'm almost positive it was fixed in 16.1.3.5. As a workaround, I ended up creating a log filter in syslog-ng settings.
