Top 4 OpenText Upgrade Mistakes and How to Avoid Them

Over the past few years, we have noticed that most of our customers make the same mistake when trying to upgrade their OpenText™ solutions to the latest version. In this post, we want to review the top 4 mistakes customers make during OpenText™ upgrade projects and explain how to avoid them. Let’s start:

Lack of research

One of the most common reasons why OpenText™ upgrade projects fail is not being aware of changes in new product releases. Many times, due to a lack of research, customers are not aware of the change in functionality. As a result, sometimes customers start upgrading projects without noticing that certain features they have relied on for decades will no longer be supported. Or the functionality will be provided by a new module with different logic and configuration. Clients will struggle for months trying to make it work (you can imagine how frustrating that would be), only to find out that what they’ve been trying to make work no longer exists, or at least not in that form anymore. So tip #1 when preparing for an OpenText™ upgrade is: do your research!

Custom Module

Another common cause of upgrade failures and delays is customization. Many customers create custom modules on top of their OpenText™ applications to meet their specific business needs. We at Bentech build a lot ourselves. The problem with custom modules during an upgrade is that many times customers don’t fully understand how these modules work because they outsource the development of these modules to third-party vendors who don’t know how to adapt these customizations to the new version and make them communicate in the right way. Often these customizations are not well documented and not included in the solution architecture. Hence tip #2: Even on small OpenText™ development projects, only work with trusted vendors. This way, all project work is well documented, the solution schema is updated, and it’s easy to get the help you need on your next upgrade project.

The product version is not compatible

While most customers follow official guidelines for minimum software and hardware requirements in most cases (for example, for leading applications (SAP, Infor, Oracle, etc.), databases, and operating systems), many of them underestimate the risk of incompatible OpenText™ software versions. Customers are often unaware that all implemented OpenText™ solutions (eg Exstream, Content Server, and Archive Center) must be compatible versions to function properly and avoid connectivity and/or performance issues.

So tip #3 is: If you are running multiple OpenText™ products, make sure to check the product compatibility details before doing the upgrade. Product compatibility details can be found in the product documentation and the product compatibility matrix in the OpenText™ Knowledge Center. If your specific combination isn’t mentioned in the documentation, it might not be supported. However, it makes sense to contact OpenText™ Support and double-check.

One-to-one upgrade

This is only partially wrong, maybe “not best practice” is a better definition of this approach. Many customers upgrade their OpenText™ solutions just to keep up with product release schedules. They just want to continue using a supported version of the product. These customers do not want to enhance their systems with the new features provided by the latest release.

Therefore, OpenText™ upgrade projects can be performed without reconfiguring, optimizing, or updating the solution configuration. This is usually successful for patch updates or minor upgrades. However, major version upgrades are almost always more efficient when rebuilding a system by adding new features from the latest version. After all, part of the annual maintenance fees companies pay goes toward the ongoing development of the products they buy. Let’s not forget that in the long run, companies cannot differentiate themselves from the competition by using yesterday’s technology. Continuous improvement is the key to process optimization. Tip #4: Follow the product release update schedule. Find out what new features have been added with each release. Discuss internally whether and how these updates help your business users work smarter. If you do not have the time or resources to do this yourself, hire a professional service provider to do it as part of your OpenText™ Consulting Assessment.

Summary and Recommendations

There are many more mistakes that lead to failed upgrades of OpenText™ products and delays in going live, which is likely to cause the entire project budget to skyrocket. (Nobody likes going back to management begging for a bigger budget, right?)

What can you do you can engage a professional OpenText™ upgrade service provider who will guarantee a successful end-to-end upgrade at a fixed price. Or, if you prefer to use an in-house team for your project, just follow the tips above. We recommend at least requesting an upgrade assessment health check and consulting service to ensure that your OpenText™ environment is ready for an upgrade and that you have someone to turn to for helpful advice and guidance. As always, please be sure to reach out if you have any further questions. We look forward to hearing from you!