Tip 7: test everything when you are doing "mock" go-lives

As I said, if I'm at a go-live, it's not my first rodeo.  Sure, I'll always have a nervous demeanour and perhaps a bit of sick feeling in my stomach, but I do love it.  I like seeing all of the data and statistics around me that somewhat affirm the planning and efforts that have gone into the project.  It's simple, when things go to plan.

Of course when a user does an open find over the F4211 and F42119 using a single non-indexed field and then wants to go to the end of the grid… with probably 20 million rows to be displayed…  I might not have tested that (nor catered for it in the sizing).  Oh, and when it doesn't return and they do it another 10 times (to be sure), that also was not in our test plan.  Nonetheless – there will always be challenges and things unexpected – your job is to reduce the number of them.

Mock go-lives are critical.  They do the following important tasks:

Assign responsibilities to all tasks, both prior to, during and after the upgrade.  Ensure that these are on the run sheet and have all been tested before.

Version your run sheet, make sure all line items are filled out and ensure that there are accurate timings.  You will not get good timings on the first conversion, and perhaps not the second.  Subsequent to that you should be building out exactly how long the conversion is going to take so that you can determine if you need to "look outside the square" when it comes to outage windows.

Make sure that people run integrity reports and check the results every time.  I've been involved in go-lives where an integrity did not match on the go-live weekend – but guess what?  It never balanced in the last 5 mock go-lives – it was not compared.  Getting everyone to run every step is a big lesson.

I only really care about rowcounts, but I know that the business will want integrity reports – so you might want a few.  Summing amount columns or hashing is another way to make technical people really happy.

Ensure that you move some WSJ history too.  Nothing worse than a user logging in and not seeing the report they ran on the Friday before go-live weekend.  Anything you can do to reduce the call volume on the Monday after go-live – you should do it!

Timing, if things are too fast you probably have a problem.  If things are too slow, you probably have a problem.  Make sure that things are predictable.

Sleep is important, people do not make good decisions under lots of pressure and with a lack of sleep.  Go-lives are tough and should be, but not at the expense of the team.  Don't let the team drive if they've worked 20 hours, get a local hotel and an UBER.  Plenty of food and drinks for the project team too.

Get a runsheet, live by the runsheet and succeed with the runsheet.  Regular comms are critical – good luck!