What's The Best Time To Roll Out A Major Upgrade?

Calculating the ideal date to roll out a major change to business IT systems is always tricky. Can you get away with switching directly from one approach to the other? And if you do, what's the right time to do this?

I've spent a couple of days this week on the Gold Coast at the Perspectives 2011 for enterprise resource planning (ERP) software developer Epicor. One of the themes I was interested in was the decision-making processes involved in planning major changes, which are inevitable with ERP systems. As well as being inevitable, they're also often fiddly: moving from one version to another is invariably much more complex than just testing and running the relevant upgrade code. That's especially the case when customisations have been made to the basic system.

That challenge is being faced by Victorian engineered products provider Tieman. Last year, it moved one division onto version 8.03 of Epicor's Vantage system. This year, it is planning a much more comprehensive shift, moving the entire company onto Epicor 9.05. That will mean major changes to the financials and planning systems for every single division of Tieman, which employs over 300 people. When's the best time to do that?

Chief financial officer Barry Greig argues against the conventional wisdom that the easiest approach is to finish out one financial year with the old system and begin the new one with a clean slate. Instead, he favours aiming for a very specific time frame. As he told me:

The best time to do it is at the start of your second quarter of your financial period. Get the first three months of the new period out of your way, because then you're finishing off all your old stuff and you're setting up the new year. The start of the second quarter still gives you enough time to get something embedded in and you've got the majority of the year left. That's the rule of thumb I've come across through experience and trial and error.

While that's the target date, the other theme which Greig emphasised was that rolling out an incomplete system purely to meet a deadline doesn't make sense. If the system requires further tweaking, a different date will be chosen once that becomes apparent:

You've got enough time in the year. OK, if it slips into the third quarter, you've still got enough time to get the system bedded in. Forget the first quarter, forget the last quarter: it's somewhere in between.

What timings have you found most effective when you've had to make changes to systems that might affect hundreds of users? Insights are, as always, welcome in the comments.

Evolve is a weekly column at Lifehacker looking at trends and technologies IT workers need to know about to stay employed and improve their careers. Angus Kidman travelled to the Gold Coast as a guest of Epicor.


Comments

    For an application accessible 24/7, deploy on a Wednesday night. Less people using it, lots of "real world" testing will be done the next day, and you'll have technical support staff readily available.

      I try to aim for either Friday afternoon or weekday mornings, depending on the type/update.

      -Hardware work just after close of business Friday, always. almost nobody complains, and it gives you a full two days of low-use in case of a worst case scenario (say, a second drive fails while rebuilding a raid array and you have to do a full restore from tape) or if you couldn't do thorough testing for the production environment.

      -software work is good on a weekday morning, (say at 5am, remotely) for the reasons jjokin gave. I also like any nightly backups to run just beforehand.

      Of course, none of this is an issue at all if everything is redundant...but alas, those budgets are hard to come by.

      In relation to the actual topic: Any big migrations like that should be scheduled for as empty a patch of the calendar as you can. The less overworked the staff are, the more likely they'll pay attention to the training/manuals you've provided ahead of time and the less frustrated they'll be by any quirks in the new system.

Join the discussion!