Export domain should work, with the usual constraints that you have to detach/attach the
whole domain and you'd probably want to test with one or a few pilot VMs first.
There could be issues with 'base' templates etc. for VMs that where created as new
on 4.4: be sure to try every machine type first. Ideally you have 4.4 and 4.3 farms side
by side, instead of rebasing your hosts on 4.3 and *then* finding issues. Things to watch
out for are hardware base lines (those mitigation-enhanced CPU types can be nasty), BIOS
types (Q35 vs. all others) etc.
Personally I see OVA files as something that should be least risky and minimal
functionality that just ought to always work. The oVirt team doesn't seem to share my
opinion and views OVA as a VMware->oVirt migration tool, mostly.
I still try to use OVA export/import for critical VMs, because sometimes it means I can at
least resurrect them on a stand-alone KVM host (even VMware should work in theory: in
practice I've seen both VMware and VirtualBox barf at oVirt generated OVA exports).
Note that there is an issue with OVA exports from oVirt 4.3: They can result in empty
disks due to a race condition that wasn't fixed even with the last 4.3 release. In
your case, that shouldn't bite you, as you are moving in the other direction. But
should you decide to go forward again be sure to check your 4.3 OVA exports via 'du -h
<OVA-file>' showing more than a few KB of actuall alloaction vs. the potentially
multi-TB 'sparse' disk full of zeros 'ls -l' might hint at.
With oVirt I consider blind faith as extremely ill advised. Everything you haven't
tested several times after every change of every component yourself, is much more likely
to fail than you ever thought befit a product that carries "a free open-source
virtualization solution for your entire enterprise" on its home page.