Opportunities and Risks of On-Premise

On-premises or on-prem refers to a usage and licensing model for server-based computer programs (software). Until about 2010, local use or licensing for the local use of software was the norm and therefore had no special designation. It is only since local use has been increasingly replaced by Software as a Service (SaaS) or cloud computing that the term off-premises has emerged as an antonym.

In the case of commercial on-prem software, the licensee acquires or rents software and operates it on its own responsibility on its own hardware, if necessary in its own data center or on rented servers of a third-party data center, i.e. in any case on hardware that is not provided by the provider of the software. In addition to the acquisition and operating costs, additional maintenance fees are usually incurred in order to allow the customer to participate in the further development of the software by its provider or to secure further support from the manufacturer.

Users of open source software can purchase support from appropriate service providers in the open source environment. Since further development and bug fixes are in the hands of the developer community, open source software does not require software maintenance fees. Operation and customization options are similar to commercial software.

Opportunities and Risks

On-Prem offers the frequently used option of adapting software specifically to the area of application and in some cases expanding it considerably. In this case, third parties are usually involved for adaptation and operation by the licensee. This is usually seen as an advantage to cover customer-specific challenges with standard software as a central component. However, this is often accompanied not only by considerable costs for this adaptation, which often exceeds the license fees many times over, but also by the customer’s risk of being able to use subsequent further developments of the software by the provider only with further considerable effort and costs resulting from the update of the adaptation.

In this case, the buyer consciously invests in an adapted in-house development in order to achieve further advantages on the basis of the standard product. In some cases, the technical debts are considerable. In principle, these are not induced by on-premises operation, but on-premises products are characterized by typically longer update cycles (possibly years). On the one hand, this means that the version differences are considerable and lead to high risks/costs on the part of in-house development. On the other hand, the commissioning of new versions is characterized by testing effort and the additional system environments required for this. It is not uncommon for on-premises customers to delay these efforts in order to save costs, skip versions or benefit later from improvements that are already available in the meantime. This also results in a considerable disadvantage for the provider, as he has to maintain several outdated product versions over the years and in turn adapt them to evolving lower system layers (operating systems, databases, components, etc.). Furthermore, it should be noted that with the increasing networking of software development, increasingly large independent product development of “monolithic” products (until the 1990s and 2000s) was replaced by products that install and “productize” a very high number of standard and open source projects. In addition, the security risks of products due to the connection to the Internet are much higher today than before the 2000s. Although the responsibility for operation and security lies with the on-premises product on the customer’s side, the customer is still heavily dependent on the supplier or the open source community. Providers of on-premises products are economically limited in terms of their development investments, as the maintenance of old versions can be significant.

The counter-model is the purchase of software as a service (SaaS) including the provider’s operational and maintenance responsibility. Almost exclusively usage-based or time-based contracts have prevailed. The customization options are also necessary here, but are usually realized within the framework of the service itself (configuration, APIs, optional third-party modules). While with on-prem, the purchase and thus considerable burdens lie with the customer, cloud computing is dominated by an offer that covers hardware, operation, line costs, maintenance and, if necessary, usage variance at correspondingly different costs in addition to the software.

Compared to the long on-premises update cycles of sometimes years, these changes may be completely negligible in SaaS solutions. Thanks to the provider’s analysis options in its product, it is able to reproduce actual usage patterns very precisely through adapted in-house development and to tailor its innovations precisely to them. A smooth further development of its product up to an uninterrupted update in operation is the responsibility of the provider or at least in the interest of the provider. Customers benefit from greater investments in innovations and, above all, a much faster commissioning of these, often due to several much smaller and lower-risk update cycles per week. Advantageous in-house developments based on SaaS products can significantly minimize your technical debt or pay it off faster.

Every IT system usually needs to process and persist data. In the on-prem case, this data continues to be stored by the customer in his designated data center. If the software is offered as a cloud service or as software as a service, data is usually also stored on this system. This results in an important decision criterion for choosing between SaaS/cloud computing and on-prem. While outsourcing contracts are generally required for cloud services, this is not necessary in the on-prem case if the company operates its own data center. In this context, it is also crucial whether the cloud servers are located in Germany – and thus subject to the respective domestic data protection law – or abroad (e.g. in the USA). In addition, it is crucial whether the cloud servers belong to a US company (in this case, US authorities can access data even if the servers are located outside the USA; cf. CLOUD Act) or not.