I am planning on migration all users to a new database on the same partition.

Once migrated, the old DB will have lots of white space.   When performing offline defrag on the old database, will I still need double the free disk size on the volume?

I want to try not to delete the database in the long run and rotate databases for production mailbox moves.

DB1 - current

DB2 - current

DB3 - empty - ready for migration

Since you're moving all the mailboxes to a new database, I would say just delete the old mailbox database.  It'll really save you alot of time and space in my opinion.

If you really want to save the original database, you need approximately 110% of the actual database size free on disk for the temp file that is created during an offline defrag. Not the size of the database on disk, the actual size of the database ( Size on disk minus whitespace). You can determine that using eseutil. By why bother? I would just delete the empty DB.

1/.2 agree with Hinte, HOWEVER don't delete it from EMC instead do a dial tone

AFTER YOU HAVE MOVED ALL MAILBOXES OUT OF THE DB

1. Dismount the DB in EMC

2. Navigate to the location of the DB and delete the Physical file, then Stop the Search Index Service and Delete the catalog folder

3. Navigate to the location of the LOGS for that DB and delete ALL Physical file

4. Now go back into the EMC and Mount the DB.  Exchange will squawk saying that it cannot find the files and if you continue a NEW empty DB will be created

5. Say yes

New small empty DB is now created and its now ready for other mailboxes to be moved into it in the future so that you can continue to use same DB names and rotate them as needed

This method is much better IMO since you can continue to protect/backup the DB etc. 

NOTE: This is also a great method to use if you have a corrupt DB and you want to get users back up and running, send receive email again, however instead of deleting the DB and LOGS you

A: rename the Folders there are in

B: Create new folders of the same name

C: Mount and create the new DB as above and then users can start sending/receiving email immediate so business can continue

D: Then you can either repair the other DB and use RDB method to recover OR use our DigiScope product to attempt to open the damaged database via our Forensic Mount which can blow by most corruption and also doesn't require log roll-up.  Then you can connect DigiScope to the production sever and restore all mailboxes to the production server and it can be done while users are within the mailboxes.

This are all great answers.

Since there are few customization to each DB, I wanted to avoid redoing them.

So if all mailboxes have been moved out of the DB, compressing them should be minimal impact? space wise?

Yes you can run an ESEUTIL /D to defragment the DB, however to do that the rule of thumb is that you should have 115% of the DB in free disk space.  Now if its truly empty then you can probably get away with less since what really happens is the DB is rebuilt and all data that has passed the retention period is left behind.  That said this process will take substantially longer then the dial tone which will achieve the exact same result of keeping the same DB name