This is actually pretty easy. You just need to add a "startupkey" protector (assuming this is a boot volume) or "recoverykey" (if not) protector to the drive, and remove the "pin" (if boot volume) or "password" (if not boot volume) protector. All of this can be done with the manage-bde.exe command-line utility, or using Powershell's BitLocker administration cmdlets. Note that, if this is a boot drive and the machine has a TPM as well, you should add a "tpmandstartupkey" protector (and probably need to remove a "tpmandpin" protector rather than just a "password" protector); if you use a "startupkey" protector instead of "tpmandstartupkey" then the TPM won't be used for BitLocker at all (although that's mostly relevant for "pin"-based protectors; the startup key isn't feasibly brute-forcible the way a PIN/password is, and the odds of an attacker stealing both an encrypted disk and the startup key but not the machine with the relevant TPM is quite low).
Depending on how much you trust your users to have configured things correctly, you might also want to set a new "recoverypassword" (the long numeric value used for recovery when normal unlock is impossible) protector, replacing the old one and optionally storing the new recoverypassword value in AD or somewhere else secure. (Of course, if your employees recorded the original recovery password like they're supposed to when turning on Bitlocker initially, they might need to know that it won't work anymore.)
Note that all of this is extremely fast, and happens without any need to decrypt (or re-encrypt) the drive. The reason is that every Bitlocker volume is actually encrypted with a totally random key that has nothing to do with any of those values (PINs, passwords, recovery or startup keys, etc.). The recoverypassword, TPM (if used), and all other key protectors are just that: they protect the actual volume encryption key by "wrapping" (encrypting) it with another key. These wrapped versions of the volume encryption key are stored within the Bitlocker metadata on the drive. When unlocking the drive, you need the key from any one protector (might be a password, the TPM, a file on a flashdrive, etc.; note that the "tpmand..." protectors count as a single protector but can require multi-factor authentication) to unwrap (decrypt) the volume encryption key. Neither the protector-derived key nor the volume encryption key are ever stored anywhere on the system except in kernel-only RAM.
You can even render a drive with Bitlocker completely unreadable forever by just removing all the protectors; even if somebody still knows e.g. the old recovery password, it won't help, because the recovery password doesn't actually have anything to do with the volume encryption key, it just is used to derive a key that unwraps an encrypted version of the volume encryption key. When the "recoverypassword" protector (or any other protector) is deleted, the corresponding wrapped version of the volume encryption key is also deleted. On the flip side, this means you can completely change the protectors for any volume (so long as you're able to unlock it at all, since you do need the volume encryption key in plain text in memory) for essentially free, because it doesn't change the actual volume encryption key (and therefore doesn't change the actual disk encryption) at all!
The only time you'd need to decrypt and re-encrypt is if you wanted to change the actual volume encryption key (e.g. to go from 128 bits to 256 bits) or the encryption mode (CBC, CBC-with-diffuser, or XTS), as those directly impact the way encryption of the actual data on the volume is performed and therefore you have to touch every single encrypted byte. Changing the protectors only requires touching a tiny bit of metadata.
