Easy case:
If you are NOT using fast provisioning - storage vMotion the VM, nothing else needs to be done if the source and destination data-stores are in the same storage profile/policy.
If you are using fast provisioning this is not a very easy task:
The API has a method "Relocate" this method is suppose to make a shadow and relink the delta VM's - the trick is you need to move the VM's in order that they are chained or you will get a lot of bloat (the VM's that do not have a single link on the destination will consolidate during the migration). If this is the state you are in I would suggest Researching the "Relocate" API - you might also want to check with VMware support to see if they have a tool so you can avoid having to write one yourself.
I do not know your environment but I have a feeling I know why one data-store fills quicker than the others. If you are using fast provision when you create a clone (add from catalog or copy) a VM/vApp it will not go to the datastore with the most space free, it will go to the datastore that the source exists on by default. You can override this by using different storage profiles, or if a datastore is "RED" it will not be used. I would make sure you have good yellow and red thresholds set on your datastores to try and keep a datastore from filling up. (I like to use 75% and 90% bu this is really a calculation based on how large your datastores are and how much data grows)