Vendors that have been around for 20 or 30 years carry significant technical debt and are poorly placed to service contemporary user requirements.
These vendors may offer mere window-dressing instead of relying on cloud-first solutions to offer truly distributed commodity-hardware.
They utilize deprecated technology and adopt poor software development patterns. It may not be possible to customize the user interface, which may be unintuitive and hard to use. The vendor should be able to describe in detail the software architecture, how it adheres to standards and where investment is directed.
How hard does the vendor make it to integrate to and from other applications? Could it be intentionally difficult? Enterprise vendors’ major selling point is consolidation on a single platform. It is a worthy objective, and a message reinforced when their API and data model makes it very difficult to interface.
The software release cycle is not a topic to which many pay attention. How often is a new version of the application released? How are new releases handled when a client needs high priority bug fixes or enhancements, do the changes go into a new release that includes hundreds or thousands of other changes? How difficult is it to get bug fixes from the vendor, and how difficult is it then to get the version that includes the fixes into production? For how long will the vendor support old version before they are no longer supported. This drives the frequency of upgrades and has an associated cost.
A key indicator regarding the use of advanced development patterns is how hard it is to add features. If a new feature takes a long time to build, if it is expensive to license or if it breaks existing functionality, the vendor has, at least in parts, a fragile, poorly designed solution. Problems like these metastasize.