Hi Nathan -
Eugene has already given you really good advice and I second all he mentioned. I'll add one item associated with your specific plan. If you convert the LUN in question from thick to thin, you may not recover any space to create a second LUN. Let me explain.
Because it's a LUN, the client operating system controls allocation of blocks within the LUN. Consider how DoT sees it. Let's start with a simple case for illustration. Let's assume a LUN that only contains 10 data blocks. The client OS writes a file that needs 2 blocks. DoT sees 2 blocks have been written. If you switched from thick to thin at that's moment, since only 2 blocks have ever been written, 8 blocks are physically available for use other LUNs like you want. So you create another LUN and maybe do some copying or whatever.
Now consider the case where three such files have been created, so 6 total blocks are used. Then you go and delete all the files. Now you switch from thick to thin. How many blocks do you get back? Answer is 4. Because the blocks in the LUN were once in use, DoT has no way to tell that they aren't still in use. The client OS logically knows that those blocks don't contain any meaningful data, but DoT doesn't.
Why is this important? Consider a 4TB LUN. The OS thinks it is 1TB in use because files have been created, destroyed, added, deleted over a long time. Question is over that time, how many unique blocks have ever been written to by the client OS using whatever allocation scheme the client has for its file system? Assume that 3.5TB worth of unique blocks in the LUN have been written over time, even though at the moment only 1TB worth, per the OS, actually contain useful data. Switch that 4TB LUN from thick to thin and you only get back 0.5TB - the sum of e blocks that have never been used in the LUN.
It's only been in the DoT 8.2 code line that support has been added for SCSI UNMAP (the general LUN equivalent of SSD TRIM), and even if you retrofit it in it only affects deletes done in the client OS after support has been enabled. I've been in this situation where to "generate" free space after marking the LUNs to support UNMAP (a disruptive event since you have to cycle the LUN offline to make it take affect) by artificially creating large files in the LUN and then deleting them for legacy LUNs I couldn't just recreate from scratch.
This is same situation doesn't apply where DoT is your file share directly via CIFS or NFS. Then, since DoT is both the file system and the disk manager, it knows exactly what blocks are in use if you switch from think to thin. LUNs are a special case because the contents of the LUN are opaque to Data OnTap, by design. Be sure to take this into consideration when you plan how much space you expect to get back when you convert.
Hope this helps you.
Lead Storage Enginer
Huron Legal | Huron Consulting Group
NCIE - SAN Clustered, Data Protection