Part of your Go Live planning must address the business contingency planning. Conduct a pre-mortem 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 to run the business if you did not have the computer systems in place momentarily. The goal of this exercise is to plan for the unknowns that may come your way. The following are a few examples to help with the brainstorming process:

• Additional workforce considerations: Look at adding temporary staff or approve overtime for areas that have changed the most or processes that would need more hand holding. I quote one of my customers, If I was to make a mistake on spending here, I would rather make it by spending more than less.
• Additional technology resources to support Go Live: You may have a lot of things uncovered during Go Live. It is like having an insurance policy: it's good to have it, but it's better if you do not have to use it.
• Third-party considerations: You have SLAs for the next day deliveries to the customers; work with your shipping carriers, and have them stand by to schedule a delayed pick up in case you need it.
• Inventory levels: You have a great dependency on planning and the stock levels; consider beefing up 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 consider it as an upcoming glitch and go somewhere else.
• Cash flows: 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 them against the checks that have passed the testing. The first time you are ready to start invoicing, try a few orders first and verify the results before you open the flood gates of batching hundreds of orders. In the case of files that are supposed to be sent out (such as EDI or positive pay files for the bank), verify those 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 discussion of going back to the previous system after going live.
• Running parallel: It seems like an easy solution for business contingency planning. However, it may not be practical, unless you are staffed high and the transaction volume is not high. Running in parallel usually adds more burden and stress on your staff while they are trying to deal with the new system. In general, it will cause more issues/noise (as users may make more mistakes under stress) 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 would be fine). There is sometimes a belief that running in parallel helps validate the new processes against the old system processes. This is a fallacy, as a 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 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 the 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.