Going Live

After the Sprints have been completed (congratulations!), Go-Live is the all important time when your system is pushed into production. It is “make or break” time and so devote time for planning and execution. Your Go-Live plan should be planned well in advance. Here's a sample plan:

Data Migration

• No data is in perfect condition. Is it the right time to clean it now before migration? It depends...
  • Yes, garbage in = garbage out. Fixing it in .CSV is way easier.
  • No, data cleansing is an endless process and will delay the project and increase risk. We can clean it later.
• Get a sample of data to the consultants early. Real data in small batches but representative of all situations is ideal to start with.
• Data, already cleansed, already combined into a single .csv, properly structured makes data migration go smoothly. Costs will go up if the consultant must pull the data from multiple sources with non .csv formats (e.g. JSON, XML, etc.) which will require additional processing.

Go-Live

During Go-Live have an hour by hour plan

• Who is taking what action when?
• Who is on-call and when (on-call schedule)
• Checkpoints to make sure rollout is monitored and running smoothly (daily check-ins can turn into every other day and so forth)
• Run tests with each rollout - test the finished production environment for any potential glaring mistakes
• Iterate - just like in software development, Go-lives can be conducted iteratively. Not all has to be done in a “big bang” fashion. Some strategies we recommend
  • Rollout in smaller groups so that you can adjust and tweak based on feedback e.g. “office by office” and “department by department”
  • Run two systems concurrently (e.g. only newly created accounts in new system, existing accounts still serviced through original system) until confidence is gained and the final data migration can occur.
• Choosing the right, least disruptive time. Some examples:
  • Wait until a few days after quarter close so as not to disrupt during a critical time. C
  • Choosing a Friday evening may be great from an end-user perspective but can be disruptive to the rollout team and may not adequately “test” the system before peak usage occurs.
  • Pick a quieter day during business hours (for example a Friday morning) so that some real “traffic” can go through the new process during business hours and any issues can be addressed. In addition, it allows a little “baking” time for people to get used to the new system.
• Have a back up plan. Although failure is not an option, good planning requires thinking through how to “roll back” the changes.