Introduction
You have invested so many years in developing your PLM system and are either aware or unaware that it might fail during upgrade. Surprises during upgrade are common but your company expects you to know them in advance and not disrupt their already stressed schedules or cause stoppage or reduce performance. Upgrade is no doubt a complex phenomenon as it involves upgrade of lot of dependent systems, hardware and software. It is a test of your environment that how much it is deviated from standard or Vendor’s roadmap.
It is tempting to have the latest version with fancy features advertised by vendors in PLM conferences and roadshows. But with new versions also comes new problems and challenges. Customizations may not work; new functionalities may not be good for business, performance may not improve, etc. Upgrade is imperative, but the timing is important. You need to enjoy the stability of current version and recover return on investment for the last upgrade before you go of next.
Upgrade should be driven by need rather than other factors as it is a very risky phenomenon. A company with roughly 1000 users who happily and successfully upgraded and went live. After a week a critical bug was discovered which made their entire environment stop after roughly a week of activity. This was difficult to identify in testing as it is not possible to simulate the production load behavior over long time although load testing was done beforehand. When reported the PLM supplier said they are fixing the bug and will release new patch soon. Sounds familiar? It takes so much time and energy to replicate, log, follow-up and find workaround with such problems. Performance was supposed to increase drastically but did not improve so much. Problems like this will take all the fun out of new functionalities and we feel that we have been fooled to just spend money on new versions. Does this mean that we should stay on old unsupported versions? No! again the timing is important. Unless you are not sure that you have found a very stable and functional release, wait… Normally you will find that the second last version satisfies this criterion, given it is out in market for some time. But every production environment is different and needs to be tested properly to stamp on this. Do not forget to read problem reports and bugs logged already. Make sure your supplier has this verification in their plan if you outsource the job.
Ask yourself- why do you need to upgrade? Is it performance? Or is it the new feature? What is cost vs benefit? Do not assume anything. Remember all the claims about performance and feature the PLM vendor has made when last time you upgraded. “This is much better in performance. This new feature is good.” Sounds familiar. If that was better so why do you have same problems? Something is wrong in your environment rather than version. First resolve those otherwise it will create more complex problems. Take upgrade as opportunity to revisit, simplify, standardize and future proof your PLM environment. See if you can get rid of some customizations or redesign data model that will increase performance and make future upgrades easy. See if you can use new OOTB functionalities instead of existing customizations. See if you can make PLM ready for future like cloud hosting, IoT and digital transformation related changes. Make your upgrade investment gain you significant benefits and peace of mind rather than just version up and new round of troubleshooting. If you feel you are short of competency, we can help you.
Some Important considerations for upgrade:
