Over the past few years, we’ve noticed that most of the customers make the same mistakes when trying to upgrade their OpenText™ solutions to the latest version. In this post, we would like to go over the top 4 mistakes customers make during OpenText™ upgrade projects and explain how you can avoid them. Let’s get started:
Lack of Research
One of the most common reasons for failed OpenText™ upgrade projects is unawareness of changes in the new product release. A lot of times customers will not be aware of functionality changes due to a lack of research. As a result, sometimes customers will start an upgrade project without noticing that certain functionality they have been relying on for decades won’t be supported anymore. Or that functionality will be provided by a new module, which logic and configuration are different. Customers will struggle for months trying to make it work (and you can imagine how frustrating this can be), just to find out that something they’ve been trying to make work doesn’t exist anymore, or at least not in that format. So, tip #1 when preparing for an OpenText™ upgrade is: do your research!
Custom Modules
Another common reason for upgrade failures and delays are customizations. A lot of customers have created custom modules on top of their OpenText™ applications in order to meet their specific business requirements. We at Ecodocx have built tons of them ourselves. The problem with custom modules during upgrades is that a lot of times customers are not fully aware of how these modules work, because they outsourced the development of these modules to a third-party provider, and they don’t know how to adjust those customizations to the new release and make them communicate the right way. Oftentimes these customizations are not well documented and not included in the solution architecture. Therefore, tip #2: engage only with trusted vendors even during small OpenText™ development projects. This way, all project efforts are well documented, solution architecture is updated, and it’s easy to get needed assistance during the next upgrade project.
Product Version Non-Compatibility
While most of the customers follow the official guidelines for minimum software and hardware requirements for the most part (e.g. in regards to leading applications (SAP, Infor, Oracle, etc.), databases, and operating systems), a lot of them are underestimating the risk of OpenText™ software version non-compatibility. Customers often are not aware of the fact that all implemented OpenText™ solutions, such as Exstream, Content Server, Archive Center, must be in a compatible version in order to function correctly and avoid connectivity and/or performance issues.
Therefore, tip #3 is: if you run several OpenText™ products, before doing an upgrade, make sure to check the product compatibility details. Product compatibility details can be found in product documentation and in the product compatibility matrix on OpenText™ Knowledge Center. If your specific combination is not mentioned in the documentation, chances are it’s not supported. However, it makes sense to contact OpenText™ support and double-check.
One-to-One Upgrade
This one is just partially a mistake, perhaps “not best practice” is a better definition for this approach. A lot of customers are upgrading their OpenText™ solutions just in order to keep up with the product release schedule. They just want to stay on a supported product version. These customers are not looking to enhance their system with the new functionality offered by the latest release.
As a result, OpenText™ upgrade projects are performed without reconfiguring, optimizing, or updating the solution configurations. This is often successful for patch updates or minor upgrades. However, major version upgrades are almost always more effective when the system is rebuilt by adding new functionality from the latest release. After all, companies are paying yearly maintenance fees which partially cover the continuous development of the product they purchased. Let’s not forget that, in the long term, companies can’t stand out from the competition by using yesterday’s technology. Continues enhancements are key to process optimization. Tip #4: Follow the product release update schedule. Find out which new features are added with each release. Discuss internally if and how these updates can help your business users work smarter. If you don’t have the time or resources to do this yourself, hire a professional service provider to do this as part of an OpenText™ advisory assessment.
Wrap-up & Advice
There are many more mistakes that cause OpenText™ product upgrade fails, go-live delays, and which will most probably explode the overall project budget. (And nobody likes to go back to management begging for budget expansion, right?)
What can you do about that? You can hire a professional OpenText™ upgrade service provider, who will guarantee the delivery of a successful end-to-end upgrade for a fixed price. Or, if you prefer to do the project by using your in-house team, you can simply follow the above-mentioned tips. We recommend to, at least, request an upgrade assessment health check & advisory services to make sure your OpenText™ environments are ready for the upgrade, and you have someone to reach out to for useful advice and mentoring. As always, if you have any further questions make sure to contact us. We’re looking forward to hearing from you!