It's allowed, as it doesn't have anything to do with the physical hardware vendor, it is more between the app+guest OS and ESXi.
Just note that Cisco only tested/validated the procedure on UCS.
If this is done on 3rd-party server hardware and there are issues, Cisco TAC's scope of troubleshooting/fix is limited to UCM software (as you would expect with customer-provided VMware and 3rd-party specs-based server hardware as clarified at http://www.cisco.com/en/US/customer/products/ps6884/products_tech_note09186a0080bf23f5.shtml ).
If troubleshooting of ESXi or server hardware required to figure out what's wrong with a VM-jump, Cisco TAC would not be doing that and customer would need to engage their internal teams for triage or root cause determination.
Would also like to confirm that the jump procedure is supported going from a MCS server to BE6K server?
Can't see why it wouldn't be supported but will ask anyway.
A few gotchas if doing BE6000 …
1. VM-jump only works for UCM 6.1/7.1 to 9.1(2), no other apps. So if doing BE6000, you’ll need to follow other procedures for the other apps (e.g. COBRAS for CUC).
2. Check the license/services/UCSS entitlements migration procedures for non-BE6000 to BE6000. Based on what your MCS is using CUWL vs. DLU.