by Jane Mugford
This article was originally published December 8, 2014 in WhatTheyThink?
Reprinted with Permission
In all industries, one of the biggest challenges facing any technology leader is when a software upgrade should be completed. In the print industry, the potential gains of new features and enhancements can quickly feel minimal compared to the risk of any fall-out that may occur if an upgrade goes “badly”. For web-to-print technology, an upgrade that has defects or bugs can negatively impact your customers and cause them high levels of frustration. For Print MIS systems, an upgrade that does not go well can send your organization in to a tailspin – even if it is just for a couple of days, the chaos can be painful. So, given all of that, why bother? You bother because without a doubt, the advantages of the new versions far outweigh lingering in the old versions. The longer you stay in a legacy version, the harder it gets to do system upgrades because the leaps to move your system forward become greater and more complex. Assuming you are going to keep your company on a path of continuous upgrades, what can you do to mitigate the risk and ensure the smoothest possible transition from version to version?
Do not go first
I strongly advocate against being the eager one that signs up for the upgrade the moment it is released, no matter how tempting the new features and functionality. I suggest holding off at least a couple of months and let the beta testers and other willing printers go first. Undoubtedly there will be issues that develop that will impact everyone. The developers are always on the lookout for these and usually there are some very quick point releases to correct defects after a major version is made available. Let a few of these point releases come out first and then get on the upgrade list. I typically like the 6 month window after a major release to schedule your upgrade. That timeframe will bring a lot of stability to the new release. Point or incremental releases usually cause minimal disruption and often add stability to the new major version, so I recommend doing those within one to two weeks after release.
Do not let yourself fall too far behind
Just as I advocate for not being too eager to upgrade, I also recommend not falling too far behind. You want to be within one version of the current major release. The reason being is the longer you wait and the more “major versions” you fall behind, the more challenging it becomes to upgrade. In this time, you are also losing out on potential new efficiencies and features. As time goes on, the vendor becomes less skilled in legacy versions so issues get harder to troubleshoot.
Consider investing in a staging/test server
While I know the additional expense of a staging server is not to be looked at lightly, the money it can actually save you is tremendous. A test server lets you do upgrades with a full replica of your live database and see what issues present – in the safety of a non-production environment. Staging servers usually run in the neighborhood of $4,000-$5,000 dollars. However, the ability to identify issues that impact you in a test environment can literally save you thousands each and every time. As an example, let’s say that you are able to identify in a staging environment that your web-to-print and Print MIS system no longer pass key information properly. You then can work with the vendor (or vendors) to resolve the problem without impacting the live environment. Assuming this fix takes a couple of weeks, how much money would it have cost you if the impact was realized only in a production environment?
Develop a post implementation test checklist
When you are NOT under pressure of an upgrade, you need to develop a checklist of all key functions and processes that need to be tested after an upgrade is completed. In essence, these are your checks and balances. This checklist should be used every time you face a major upgrade and it should be refined as time goes on. Here are 3 sample items for both web-to-print and Print MIS that I think should be on everyone’s checklists:
While the above may seem obvious, they are often overlooked or not tested in the chaos of an upgrade. One part of your checklist should be the listing of “show stoppers”. These are any failures or issues that cause you to abort an upgrade and roll back to the previous version. An example of this may be the failure of the Print MIS to receive orders from the web-to-print system. If show stoppers present after an upgrade, you need to go to your roll back plan as identified in number 7 below.
Buy yourself as much time as possible
While no one likes to work over holidays or weekends (let’s face it, most of us do it anyways), I strongly encourage attempting upgrades in a window of time where you have the most ability to troubleshoot and test. This is especially true if you do not have a development server. My recommendation is that you do not do anything near month end. The disruption can be too dramatic. I also think doing upgrades late in a week or ideally on a Friday afternoon is wise. That way you can have the weekend to test and ready any communication to go out to your teams for first thing Monday if issues present. This also minimizes disruption to your customers, particularly for web-to-print systems.
Do not approach the upgrade on your own
Have a team on standby to help with testing. This is a great way to have subject matter experts testing key areas. They will be the best ones to help identify issues and determine how to work around them.
Have a roll-back plan
After the upgrade is complete and you do some testing, what are you going to do if a show stopper presents? A roll back plan is like travel insurance, you hope you never have to use it but you are really glad you have it in case something happens. Thinking this might not happen is naïve so you need to be prepared. Are you technically prepared to revert back to the previous version? Do you have documentation of how to do this? This plan can be a lifesaver and lets you make an intelligent decision of when to roll back to the previous version because the risk of the organization working in the new version is too great. You need to identify who has the authority to say “we are rolling back”. You do not necessarily want to put that pressure on the IT person actually doing the upgrade. It most likely needs to be someone from the senior leadership team – along the lines of the VP of Operations and should be decided before the implementation process starts.
Consider the Cloud
If you are considering a new Print MIS or web-to-print system and there is a Cloud/hosted version available, strongly consider it. It takes all of the upgrade pressure out of your hands and plants it firmly on the vendors. With the Cloud there are still risks of issues with an upgrade. However, when it is the Cloud version, issues affect everyone at the same time so they are often addressed so fast with the most senior engineering resources of the vendor.
Communicate the communication plan in advance
The last thing you need to deal with on a Monday morning after an upgrade is everyone calling, emailing or stopping by your office to say “this isn’t working” or “I don’t know how to do this”. Before the upgrade, send out company-wide communication to advise on the protocol such as a help desk type email address for managing questions and concerns. In addition, designate a team (ideally your testing team) that helps to triage all the various questions. The ability to identify any trends and also prioritize issues is important.
While no implementation ever goes perfectly, there is a lot you can do to mitigate the risk. If you take the time to plan out an implementation that is controlled and carefully executed, you will quickly reap the benefits of the new version while minimizing the disruption to the business and your customers post-upgrade.