I would think that a very high priority would be maintaining the integrity of the existing database prior to incorporating changes. To manage this well you might want to consider the following:
1. Maintain in unchanged copy of the stage 1 database, if something goes wrong then you can always revert back to this copy while troubleshooting and making corrections to the next stage.
2. Document a data export process (in other words how is data migrated from state 1 into state 2).
3. When you are ready, take the data from state 1 and then import it into a TEST copy of the state 2 database.
4. Perform what my group calls a "Conference Room Pilot" (CRP). The purpose of the CRP is to bring actual users into a testing environment and have them run through their paces. The purpose of this is to put users hands on with the changes and determine what the problems are, what did you not get right as a designer, what things can they accidently screw-up that you need to prevent.
5. After CRP go back to the drawing board and make any corrections/updates needed.
6. Repeat CRP after corrections. (All this time stage 1 is up and running and still available for "production".)
7. Once stage 2 is ready to "go live", backup an unchanged copy of stage 1 as a backup that can be restored if there are problems. Deploy stage 2 after importing all the "live" data from stage 1.
You might also consider using the Convert to Seperation Model approach. It splits your file into two parts, Interface and Data. This reduces the frequency with which you need to export data as you can replace interface files with new copies (or revert them to an older copy) without having to import any data from one file to another.