• In addition to the advice from Eliott W and robert.mcleod, I would also recommend that you have a QA version of the database that mirrors live. First test all your scripts for the migration against that. Then have a number of users test all apps which access the database and SIGN OFF the tests - or highlight weaknesses or failures against the testing schedule.

    If you do not have a formal testing and signoff process agreed by management, which they know can be traced back to them in the event of issues arising, you are - in my experience - going to get no worthwhile effort from a significant proportion of the user base. <waves hand in airy fashon> yeah, yeah. Whatever, I'm busy you know. User may actually bother trying to log in ... if you're lucky.

    Amend your scripts AND DOCUMENTATION to take into account any issues arising from the qa - then restore and do EVERYTHING again. Once you have full signoff - then you can use the exact process you have set up, and documented, to do the move to live.

    While this process is undertaken, there should be a code freeze on both the database and the apps accessing it. If the freeze has to be broken - eg to fix a critical bug, then it's back to the start with qa, etc to ensure the changes work with the updated functionality.

    You should also have tested your rollback in a qa enviromnent so if you get a user who has signed off, but not done thier testing job effectively - or indeed if you make an error in your process - whatever, and something critical breaks, your way back has also been tested appropriately.