Part of your go-live planning must address business contingency planning. Conduct a premortem session to brainstorm areas that may go wrong and to find ways in which the team can reduce the likelihood or mitigate the business impact if the issue occurs. Review the critical business functions that are important for the organization and develop contingency plans in order to run the business if you don't have the computer systems in place momentarily.

The goal of this contingency planning is to plan for the unknowns that may come your way. The following are a few examples that will help with the brainstorming process:

• Additional workforce considerations: Look at adding temporary staff or approving overtime for areas that have changed the most or processes that would need more hand-holding. Suppose the warehouse area has the most processes that have been changed. Here, it would be advisable to add more staff to the warehouse so that they can do extra work during go-live.
• Additional technology resources to support go-live: You may have a lot of things being uncovered during go-live. It is like having an insurance policy – it's good to have it, but it's better if you don't have to use it.
• Third-party considerations: You have SLAs for next-day deliveries to customers; work with your shipping carriers and have them stand by to schedule a delayed pickup in case you need it.
• Inventory levels: You have a great dependency on planning and the stock levels; consider increasing your inventory prior to go-live.
• Communication team: Have them stand by in case you need to communicate with the outside parties (customers and vendors) or even internally. You may not want to let the customers know ahead of time about the ERP release as they would see it as an upcoming glitch and go somewhere else.
• Cash flows: You need to plan for additional cash flow as it may take a little longer to get paid for a few weeks (or months) after go-live due to system or training issues. You need to have an additional line of credit available in case you need it.
• Key processes and proactive planning: Identify the key processes and their first occurrence to provide some hand-holding and validation. For example, after processing the checks for the first time, ensure that you can validate the printed checks against the checks that have passed during the testing process. The first time you are ready to start invoicing, try to invoice a few orders first manually and verify the results before you use the batch process to invoice orders automatically in the hundreds. In the case of files that are supposed to be sent out (such as EDI or positive pay files for the bank), verify the ones that were sent and were accepted faultlessly at the receiving end.
• Going back to the previous system after a few days or few hours into using the new system: Once you move to the new ERP system, it may not be possible to go back to the previous system. It is not easy to perform a reverse migration from a new platform to legacy. Make sure that everyone understands that once you are live, there is no going back. Everybody is in it together and issues need to be resolved on the new system. This helps in avoiding unproductive discussions of going back to the previous system after going live.

• Running parallel: This means that you are running your legacy system/ERP in parallel with Dynamics 365 for finance and operations. It seems like an easy solution for business contingency planning. However, it may not be practical, unless you are highly staffed and the transaction volume isn't very high.
  Running in parallel usually adds more burdens and stress on your staff while they are trying to deal with the new system. In general, it will cause issues/noise (as users may make more mistakes under stress) more than helping. If you had to go for running both the systems in parallel, the amount of time to run in parallel should be kept to a minimum.
  Quite often, running in parallel is looked at as a replacement for inadequate testing; you think you are better off not doing testing in production (and hoping everything will be fine). There is sometimes a belief that running in parallel helps validate the new processes against the legacy system processes. This is a fallacy as part of the point of implementing a new system is to improve the processes that may fundamentally change the way you do business. So, it is like trying to compare apples with oranges.
• Release validation: As we mentioned earlier, going back to the previous system or running in parallel is not easy. How can you verify that there are no critical issues as part of the release itself? It is ideal if you can hold certain transactions from the previous day; for example, let the AP team enter real vendor invoices, perform a check run based on what's due, enter orders that were received from the customers during system downtime, enter the incoming EDI transactions, and so on. The goal is to have good samples and real transactions to verify system behavior.

These are some ideas based on my past experiences. You need to review these with the business leaders and determine what is applicable to your business in order to make appropriate arrangements.

So far, we've learned about the go-live readiness and go-live activities that, as a customer, you need to understand. However, at the same time, it is equally important to execute these activities for a successful go-live. In the next section, we'll talk about the planning and execution of these activities.