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, setting up a new system, data migration, data validation, release testing, or a rollback process.

All these steps need to be documented in the go-live plan and should contain any 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, setting up 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 completed, and so on. Also, identify that your source for data migration has the latest information, runs the extraction and migration tasks, communicates at specific intervals during the release, takes backups during the release, and identifies good checkpoints when backups should be taken (in case you have to go back to the previous state). For example, you do this before you start posting transactions as you can't un-post them easily if you find 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 or functionalities that were identified in the release validation, and so on).

• Decisions (Go-No-Go): Identify multiple checkpoints when you need to make Go-No-Go decisions with the executive or 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, communication for release, turning on automated processes, verifying the acceptance of outgoing EDI files by customers, verifying the acceptance of positive pay files by each of the banks, and so on.
• Rollback: You may have to roll back to a state prior to the release in unfortunate events such as 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 rollback procedure to be completed.

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 the 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 being 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 documents, configuration checklist, code artifacts, and so on.
• Put together a visual summary of the detailed plan. This 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 exhausted 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.

Once you have made the go-live plan, it's time to execute it. Without a great execution, the plan is of no use, so, as a project team, you will be working on executing the plan you have put together.