You should not ever have any spatial data in the SDE tablespace (it should be exclusively reserved for geodatabase metadata tables), so the quota on SDE should not in any way be impacted by geometry storage migration.
I would not recommend in-situ geometry migration (the process does significant damage to the base table [through fragmentation and high water mark creep]). If you need to recreate the tables for performance reasons, then you might as well create new tablespaces to manage them as neatly as possible (provide for storage increase by setting a quota 50% larger than the previous usage, then reducing it when the smoke clears.
Another recent thread discussed this same issue, so I recommend you review the spatial defragmentation recommendation as well.
