As part of the release, you may be performing hundreds of tasks, so it is important to track their progress, dependencies, and corrective actions. Go Live planning involves the following:

• Putting together all the steps in the plan
• Defining the sequence and dependencies between the steps
• Determining the time needed for each step
• Defining the owners and ensuring that all the concerned parties have a clear understanding of what is required

Multiple reviews with the IT and business teams can ensure that you have identified every task that needs to be performed as part of the cut-over and that everyone involved understands the big picture of all the tasks involved in the release. Using such a plan for UAT, end-to-end testing, and pilot releases can help you identify any gaps in the plan as you practice the overall release execution process. This includes the communication required across groups, such as turning off certain integrations of the legacy system, the setup of a new system, data migration, data validation, release testing, or a roll back process. All the steps need to be documented in the Go Live plan and should have relevant information, as described in the following table:

The following are some typical task types you will be putting in your Go Live plan:

• Pre-release: Identify all the tasks that can be completed prior to getting into the system's downtime window for release. For example, communication for the upcoming changes, setup of the future production environments, moving the golden configuration and master data, and any dependent application code or configuration that has no hard dependency. Also, add the tasks for tracking all the necessary sign offs.
• Release: Identify the tasks to be completed during the system's downtime window for release, such as taking the systems down, ensuring that all the transactions are complete and that your source for data migration has the latest information, running the extraction and migration tasks, communicating at specific intervals during the release, taking backups during the release, and identifying good checkpoints when backups should be taken (in case you have to go back to the previous state), say for example, before starting the posting of transactions, as you can't unpost them easily if you found an issue.
• Validation: These are the tasks for validation, such as IT validation and business validation (verify the vendors and addresses, open balances, the validation of processes/functionalities that were identified in the release validation, and so on).
• Decisions (Go/No-Go): Identify the multiple check points when you need to make Go/No-Go decisions with the executive/project team.
• Post release: These are the tasks to be performed after the final decision has been made to Go Live. These tasks may go on for multiple days into using the new system, for example, the communication for release, turning on automated processes, verifying acceptance of the outgoing EDI files by customers, verifying the acceptance of positive pay files by each of the banks, and so on.
• Roll back: You may have to roll back to a state prior to the release in unfortunate events like when something goes wrong during the release, when critical issues are identified, or when external, uncontrolled dependencies have caused issues. In any case, you need to have rollback steps defined and practiced in the release simulation phase in order to have an uninterrupted availability of the systems to  the business. The time needed for the rollback procedure needs to be considered in the release process and the Go/No-Go decisions must be made in a timely manner to allow the completion of the rollback procedure.

The following are some guidelines for putting together your Go Live plan:

• A smaller number of manual steps and more automation is ideal to ensure that you don't have too many steps to perform and track.
• Minimize the dependencies; if activities can be completed in the production environment, mention them as a pre-release item. For example, if an integration solution requires creation of a new database, and if it can be done prior to the release, mention it as a pre-release item.
• You may be implementing ISV solutions or integrations with third-party systems, or integrating with an application managed by a different team in the same organization. Coordinate with the different teams to understand the dependencies and activities needed to deploy their solution. There should be one single deployment plan for all the components that need to be deployed as part of the release.
• Keep the overall deployment plan simple. Add additional attachments or links for the detailed steps that need to be performed.
• Create a repository to collect the artifacts and documentation required for completing individual tasks, including release notes, validation plan document, configuration checklist, code artifacts, and so on.
• Put together a visual summary of the detailed plan. It helps in communicating with the stakeholders.
• Every step, including logistics such as booking hotel rooms and ordering pizza, should be put on the plan with their owners.
• Ensure that you have not burnt your key resources with the release. Spread out the tasks in a way that allows for some downtime for the key resources. The real journey starts after putting the system into production, and you need everyone to stay energized for those first few weeks of transition.