To begin with, VeraCrypt is open source. So, you can ensure the code does not contain backdoors. While BitLocker is closed source and hence not open to inspection. For this reason posts like, Can the NSA Break Microsoft's BitLocker have come about. While Microsoft Opens Windows Source Code to EU Governments is good news, it still allows me to make the statement BitLocker is as trustworthy as Apple's FileVault, because the source code is not public, until that date, this statement remains true.
To my understanding, VeraCrypt's hidden partitions work similar to the discontinued TrueCrypt. The hidden partitions work very nicely,
It may happen that you are forced by somebody to reveal the password to an encrypted volume. There are many situations where you cannot refuse to reveal the password (for example, due to extortion). Using a so-called hidden volume allows you to solve such situations without revealing the password to your volume.
The principle is that a VeraCrypt volume is created within another
VeraCrypt volume (within the free space on the volume). Even when the
outer volume is mounted, it should be impossible to prove whether
there is a hidden volume within it or not*, because free space on any
VeraCrypt volume is always filled with random data when the volume is
created** and no part of the (dismounted) hidden volume can be
distinguished from random data. Note that VeraCrypt does not modify
the file system (information about free space, etc.) within the outer
volume in any way.
The password for the hidden volume must be substantially different
from the password for the outer volume. To the outer volume, (before
creating the hidden volume within it) you should copy some
sensitive-looking files that you actually do NOT want to hide. These
files will be there for anyone who would force you to hand over the
password. You will reveal only the password for the outer volume, not
for the hidden one. Files that really are sensitive will be stored on
the hidden volume. - Source
VeraCrypt has cross-platform support. Such that you can access VeraCrypt volumes on FreeBSD, Linux, Mac OS X and Windows. However, BitLocker volumes can only officially be supported, as of writing, on Microsoft Windows. Furthermore, Cryptsetup can decrypt and open VeraCrypt volumes
cryptsetup --tcrypt-hidden open --type tcrypt [volume] [name].
If looking for aspects of BitLocker which are less secure, it should be noted that TPM does not aid security when compared with using a removable USB key, as this can be taken with you more easily, while the TPM cannot. Furthermore, BitLocker does support password decryption, similar to that of LUKS. So, BitLocker provides three options for where to store the decryption key: TPM, USB key or password (which you remember).
Assuming that there is the ability to adopt Veracrypt, I imagine the natural progression would be to decrypt the devices currently using Bitlocker first. If yes, what risks does this present to the data on the disks?
Storing any sensitive data on a decrypted drive presents a considerable risk. As once done, you have to properly overwrite the data after, which on SSDs can become considerably more tedious.
Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?
As the devices that currently use Bitlocker store sensitive information such as personally identifiable data, financial statements, etc, i would like to limit the risk of data leakage.
Copy the sensitive data directly from the BitLocker encrypted directly onto the VeraCrypt encrypted partition, this mitigates data leakage. Alternatively, if this is not viable archive the data into a 7z archive and encrypt that using AES256 with a strong random password. Then extract that archive onto the VeraCrypt partition. Then discard the password and overwrite the 7z archive, the overwrite part is optional.