We all know ECM upgrades can be challenging, we also know
that in a perfect world there would be no hiccups. When does this ever happen? Some
of the worse issues can explode when an upgrade is “supposed to have no impact”
on other systems.
In Mike Bourn’s blog article, ECM System Production Deployments – What Could Go Wrong?,
he describes the ways to mitigate the “busted weekend”. He describes the
infrastructure and expertise requirements to mitigate risk. I’d like to add a
few others:
1. Frequency There’s a reason that cloud services is supplanting onsite installation beyond cost: maintenance. It’s a way to have other do upgrades every year without the hassles of begging for resources. If you are still have your ECM system in-house, great! Keeping up with the version service pack 2 release upgrades is ideal for mitigating the various infrastructure and database risks.
2. Number of environments
The number of times you practice the steps involved with an upgrade is directly related to its success.
The number of times you practice the steps involved with an upgrade is directly related to its success.
3. Using Prod data
I can’t emphasize enough the importance of refreshing your environments with production data. The majority of content files don’t necessarily have to be copied. The issue is mainly around the potential issues with data quality and upgrade duration measurements.
I can’t emphasize enough the importance of refreshing your environments with production data. The majority of content files don’t necessarily have to be copied. The issue is mainly around the potential issues with data quality and upgrade duration measurements.
4. Type of Documentation
Write documentation as if you have been up for 24 hours and are stress out. Create lists and take screenshots. Make believe you are dumb and need step by step instructions, don’t cut corners. Also, don’t blow off any install messages: these can blow up upgrades.
Write documentation as if you have been up for 24 hours and are stress out. Create lists and take screenshots. Make believe you are dumb and need step by step instructions, don’t cut corners. Also, don’t blow off any install messages: these can blow up upgrades.
5. Reliance on outside services
It’s fine to have tech support on a support retainer for the cutover weekend, but I would try to do all of the actual pre work, testing, and troubleshoot. This is one of the best chances to learn more about your system, to gain an in-depth understanding beyond what the manuals or basic maintenance can offer.
It’s fine to have tech support on a support retainer for the cutover weekend, but I would try to do all of the actual pre work, testing, and troubleshoot. This is one of the best chances to learn more about your system, to gain an in-depth understanding beyond what the manuals or basic maintenance can offer.
6. Empowering the right individuals
Try to include as many individuals in on the upgrade procedures. Distribute the troubleshooting tasks among them.
Try to include as many individuals in on the upgrade procedures. Distribute the troubleshooting tasks among them.
7. Testing Efficiently
Regression testing can get so bogged down in the weeds that larger issues are missed entirely. Try to design a multifaceted strategy that balances the number of tests with the likelihood that it would be affected by the upgrade.
Regression testing can get so bogged down in the weeds that larger issues are missed entirely. Try to design a multifaceted strategy that balances the number of tests with the likelihood that it would be affected by the upgrade.
8. Diversity of User’s OS and Browsers
Please don’t forget that the User base is not like you. Their PCs may not have been included in the last round of OS upgrades or patches. Their web browsers or java versions may be configured with different options. Their PDF viewer may be old.
Please don’t forget that the User base is not like you. Their PCs may not have been included in the last round of OS upgrades or patches. Their web browsers or java versions may be configured with different options. Their PDF viewer may be old.
9. Ready to Go
If you have a multiple person team, keep one home and rested, ready to come in on the following day to deal with the post upgrade issues because there will always be some.
If you have a multiple person team, keep one home and rested, ready to come in on the following day to deal with the post upgrade issues because there will always be some.
There are infinity ways an upgrade weekend can go bust. By drilling into each of the above areas, you should mitigate many of potential hiccups. If you are lucky, the issues will be minimal. You will be able to rest on Sunday before going back in for more on Monday.
No comments:
Post a Comment