Each EV server can host more than one Vault Store, each with its own Vault Store Database. I would create new Vault Stores on the "heavy hitter" EV servers, and reconfigure provisioning groups so that all new employees have their archives written to the new Vault Store. This at least will slow the tide of growth.
The storage should not be co-mingled; for example, you don't need separate physical storage but you do need separate directories. If your current partition is on F:\EVStores\Ptn1 then it's pretty easy, just put up a new folder of F:\EVStores\Ptn2 or even create an F:\EVStores2\ and put your new partitions in there. You can definitely put the new store on a totally separate drive if you have one available though!
If there is a Journal Archive on any of these stores, it is fairly straightforward and easy to "close off" an existing Journal Archive and reconfigure EV to archive that Journal Mailbox into a new archive, which you would first create on your new store. If you need those steps, the creation of the new archive is here: http://www.symantec.com/docs/HOWTO58046 and then you'd just reconfigure your task.
I would not recommend moving archives until you get permission to delete the source archives; a move is basically a copy then an optional delete of the "old" archive, and without the delete at the end, you're basically duplicating your SQL records and your savesets. That's how the native MoveArchive tool works; I'm not sure if any of the third party tools would be able to complete the whole process if you're not allowed to delete.
You may want to be on the lookout for SQL performance issues--- the recommended limit comes in part, as Rob mentions, from the ability to perform regular SQL maintenance and also the general better performance SQL delivers when databases are smaller. If you are struggling with the SQL maintenance, you may have to implement a "split" schedule; instead of cleaning up all SQL indexes once a week, you'd have 2 different SQL jobs that run on different days and target different databases. If you see high SQL disk queue lengths then you may have to stretch the database across more than one physical drive. But if SQL performance is currently satisfactory then it is more of a "just watch it and if you see it start to slip, you might have to make some changes."
Anyway I'd get some new stores and databases stood up to at least prevent throwing new users and their data in with the existing mass. Your existing archives will continue to grow and the databases will continue to grow with them, but at least there is not the added burden of future employees in there.
