You’ll probably want to do at least 4 mock cutovers. One to build the initial development environment on the new hardware. One to start System Test. One to start User Acceptance Testing, and a “dress rehearsal” to prove out your cutover plan/strategy.
Start the cutover plan when you do your first migration. Capture tasks and timing. And continue to refine it with each additional mock cutover.
For the 3rd mock cutover, include items in the cutover plan for communication, external systems that will need to be modified and moved in parallel, shutdown sequence for batch, expected timeline, contact lists, etc. By now your communication plan should be fairly explicit and there should be no surprises from the extended IT team or the business as to what will happen and when.
One to two weeks prior to cutover, execute a “dress rehearsal” where you actually move your production database in as realistic of a fashion as possible. Validate your final timings and make sure nothing was missed.
Two words about cutover communications: They’re important. You need to keep all of your stakeholders informed of where you are in the cutover, raise any issues quickly, and insure all of the hand offs are executed cleanly with no loss of time. Identify a single point of contact (or contacts if you’ll be running cutover around the clock) who can get status from the team members without bugging them too much and prepare regular communications to the interested stakeholders.
In addition, you’ll probably want to maintain two open conference call bridge lines: One for executive/stakeholder updates, and another to allow your technical teams to quickly collaborate on handoffs or issues that arise.
A good cutover plan will include a final “Go/No-Go” decision point prior to starting any cutover activities. If you have no “Severity 1” or “Showstopper” issues the cutover should proceed on schedule.
Now the cutover plan becomes the script for everything over the next hours and days. A common scenario follows: Users close out transactions. Batch schedule is stopped in a controlled manner. Final interface files are sent. Validation reports are run that users will use to validate the system when it comes back up. Finally user accounts are disabled, the application is stopped, and the DBA team (who is hopefully caught up on sleep) takes over.
Now the DBA team executes the data migration using whatever tool you decided on. Row count reports and other validation will be executed when it’s complete and the PeopleTools upgrade will start on the database. This can be the longest part of the process. Then all of your customizations are migrated in, the application is configured and a non-destructive technical checkout is conducted.
It’s typical at this point to allow a limited number of users log in and enter and process real production transactions. This allows any problems to be identified and resolved before the system is turned over to the larger user population.
Finally we’re ready to go. Get your project sponsors and executives on the phone for a final Go/No-Go decision. Once you get the green light, unlock all of the users and start your batch schedule back up in a controlled manner. Congratulations! This is a big accomplishment!!