additional hassle needing mention, is that the db would have to be completely inactive to do the table shuffle. with use of in DB re-indexing tools can still cause some down time but insignificant compared to making a checklist and crossing fingers.
being that this is an SQL DB you can use some of the admin tools to handle it, also could write a group of SP's that would order/sort/group what you need as you need/want it, replicate a temp table, fill it, re-assign keys, the whole shabang. then thes e sp's could be stanked into a macro sp to run all tables, all keys, all re-indexes..much testing this route tho.
last option worth mention, is replicate the DB minus the data, then import everything as you want it (SAVE the scripts generated with the imports), check it over(especially with your web pages, little shifts can make big effects), delete the contents of the replicate.
re-run all the saved scripts to replicate earlier actions that were valid, at a point just before a set downtime/maintenance, and perform the switcheroo.
i personally would be more comfortable with this scenario. for one you still have your live DB, you make a replicate "test" db to play with as you need, get a chance to test all pages in a staging environment without compromising anything, and should the roof cave in on the ordeal, you still have your live environment (i tend not to trust automation i didn't create, murphy's law and all

)
![[thumbsup2] [thumbsup2] [thumbsup2]](/data/assets/smilies/thumbsup2.gif)
DreX
aKa - Robert
if all else fails, light it on fire and do the happy dance!