The main thing is the cost. Most of the time, organizations move away from Documentum due to cost. It's highly-priced, and the support costs are high. Now, SharePoint and other options. Microsoft gives free licenses, so organizations mainly look for cost-effective products.

The second thing is updates and patching. We patch very often, every six months or a year. We have SP1, SP2, and SP3, and then suddenly, it's moved out of support. That's the organization's main pain area. They don't want to keep investing from a storage perspective. The licensing model should be changed.

The product itself is out of support. They have not considered it for AI initiatives.

The new version should be on the cloud. I'm not sure if the new version of Documentum, xECM, is cloud compatible or on which cloud it is compatible, but the OpenText server itself is on a cloud, which would be beneficial to the business. And it would also be easier for migration.

The interface of OpenText Documentum could be more intuitive; sometimes it is hard to find where the information is located.

The BPM side should be improved. It would be beneficial to have more ability to customize features for specific use cases.

The main issue is the software's performance when storing around 10 million or more documents. It becomes slow and needs improvement. Perhaps it's a cloud-related issue, but it needs to be addressed. It could be due to our S3 bucket or something else. Nevertheless, this is a significant challenge we're facing.

Additionally, OpenText doesn't support certain file formats, such as .rai. Some of our analyzed documents come directly from machinery. We utilize an IoT device, and some of the analyzed document files are directly generated by the machine. We then store them in the S3 bucket. 

However, when attempting to import these documents from the S3 bucket to OpenText, they fail to open. This is the primary issue. As a result, we have to convert these files to PDF before they can be opened. 

So, I hope for improved performance, particularly with a large number of documents, in future releases of the solution. Currently, our old software stores only eight million documents. However, we have over 15 million documents in our legacy software because we've been using it for the past 15  years across the globe. We have over 50 million documents in total, but only eight million are currently stored. As a result, the performance was slow, comparatively slow.

The price is quite high as the licensing prices are significant.

The user interface can be a bit more intuitive. OpenText has made an effort to improve the UI from where it was to where it is today. However, I think it can be improved a lot more.

The documentation often leaves customers feeling somewhat frustrated, as OpenText seems to expect customers to remind them constantly about the need for better documentation, as they don't provide clear guidance on their documentation practices.

We mostly use the Life Sciences package. That package is somewhat dated. There should be enhancements to the Life Science package and additional offerings to support pharma in particular.

OpenText Documentum has a lot of scope for improvement in terms of adding some AI integrations. A lot more can be done in terms of workflows. There haven't been a lot of new features for OpenText Documentum workflows in the past few years.

I would like to see performance improvements, especially regarding slow response times. Despite upgrading hardware and software versions, users across multiple sites still experience delays, which impacts productivity.

OpenText Documentum's user interface could be improved a little bit.

I would love to see OpenText Documentum having an out-of-the-box integration with DocuSign.

OpenText Documentum needs to improve its support. 

Documentum is a very robust system. Everything can be improved, but at this time, I do not have anything in particular. If anything, they can put our software in their standard.

OpenText Documentum needs to improve the way documents are logged together. I believe running it on the cloud or containerization will bring value to it. The tool's time to market and deployment cycle need to be improved. 

Finding suitable training materials for OpenText Documentum is also a bottleneck. If we can find the training modules easily, we can bring together people, give them quick training, and start working on the deployment. It can help with quick outputs. 

OpenText Documentum is moving to the cloud, and I am concerned about the security aspect of it. 

One area for improvement in OpenText Documentum is its handling of outdated documents, especially technical ones. Currently, older files remain online and clutter storage, but a new feature to offline these files for select users has been suggested. Additionally, there is a need for better management of offline access, restricting it to only essential users to maintain security and streamline access.

The DocBroker connection could be improved because sometimes DocBroker cannot see the DocBase.

In BPM could be better. Its GUI needs the ability to build more rules. This is a crucial feature. For example, OpenText has some products that allow you to control your checks, invoices, and so on. They have exciting approaches to converting pictures to text, but the tool for business process management isn't easy to use. The GIU is not so good.

It's difficult to manage and customize Documentum. 

The user interface can be improved.

Searching for documents is complex and should be easier.

An area that needs to improve is how to reduce storage space on the AWS site. Also, scaling up is difficult and we need to look at how to scale a system. If the documents increase the application size, then we need to know how we take care of reducing the size as well as scaling up the application. 

In the next release, I would like to see more cooperating workflows, better integration with other systems, and RESTful services.

In terms of improvement, we have had bugs with version 2.2. They should develop something so that bugs don't happen in our projects. We make changes manually and bugs happen. 

I think the vertical application could be improved. The integration with business applications means that sometimes the end-user, for example, the finance person, wants to see the scanned copy from inside the SAP form, or from inside the Oracle form and although Documentum claims it, it's not simple because integration between the ERP business applications and Documentum doesn't work so well.

If I'm searching for a certain transaction in the business application form and I want to see the attachments, the original scanned copy of the invoice, or the PO without the need to have another interface to login and search for a document, I want to be able to click on some sort of customized button or something to retrieve the attachments or the related documents from inside the ERP business application interface.

When it comes to additional features, OpenText announced that they are working to develop new modern web interface that will allow integration with Documentum repository as a backend. This was a concern because other competitors have a GUI, an outstanding user experience. It's a little slow now with OpenText, but if they release this in the coming two quarters, it would be great.

The biggest issue for us is the price of the product.

It needs a better UI and it should also be cloud-ready. The UI has not changed in years. These are the two major improvements I would be expecting.

It should provide:

• More Docker based solutions.
• More support to the cloud (AWS, Azure, etc.).
• More tools to help clients upgrade solutions based on Webtop.

Documentum xCP 2.3 is still has some drawbacks such as :

1• Dependent filtration among multiple drop down lists in Result list

2• Unable to access all user tasks from all processes in user inbox (not only the processes included within the application)

3• Unable to include task link in task notification mail automatically

Performance could be better. But this is a generalization. We can achieve good performance with Documentum, but we need experience to understand several details about how Documentum works to avoid performance problems. Documentum, out of the box, could be better designed so that we wouldn't fall into these problems so easily.

Also, the permissions model could be better. For example, I don't understand why we don't have the concept of a read-only user enforced by content server. But I can understand it can be difficult to make a permissions model that can be simultaneously generic and functional.

Sub-products like RPS and Records Manager are really bad. But I wouldn't hope for improvement here. The mission here is difficult. Trying to make a product that can handle lots of records, millions usually, is a tough mission. We have to be able to apply customer rules you don't know yet, because they're the customer's rules (and exceptions).

While generally secure, some noted security issues need consideration. The installation process for on-premise setup needs improvement as well.