Impact/Risks:
The approach listed here cannot be used in below cases:
a. For upgrading the edge to next major version/minor version.
* Like if versions are changing from 6.2.2 to 6.4.4
* Like if versions are changing from 6.3.2 to 6.4.4
* Like if versions are changing from 6.4.2 to 6.4.4
b. It’s not advisable to use it to upgrade to next patch version. If it’s done, it should be fully validated in lab.
* Like if versions are changing from 6.4.3 to 6.4.4
It should be only used for hotpatch application where it is known that only Edge OVFs have changed and no other components are changed. For example in 6.4.4a Hotpatch only Edge changes are there. So when upgrading from 6.4.4 to 6.4.4a it can be used. However, this approach must not be used when upgrade to 6.4.4a from any other patch release like 6.4.2 or 6.3.4 etc.
c. It must not be used for downgrade of edge.
* If NSX Manager is 6.4.4, OVF must not be replaced to any older versions.
* It could lead to new deployment, HA enablement or redeploy failures due to version mismatch depending upon what services are configured on edge. And the errors should will be not user friendly. It could fail with "Config failed on edge" or syntax errors on edge side.
d. After OVFs are replaced, reboot of NSX Manager is required before any edge operations so that right build versions are reflected in internal caches. Which gets updated on NSX manager reboot