When you are faced with a choice of software solutions, you should know what precisely you are deciding on. In this blog, we would like to draw your attention to a few parameters that we think are important for such a decision.

In the following, we present comparisons mostly between SAP, Navision, and Odoo. Not just because customers usually include Odoo in their shortlists together with these respective vendors, but also because we are in a position to assess these products based on past migration assignments from these solutions to Odoo. And because they all have a very similar, i.e., integrated, international, and generalized approach. None of these systems focusses on a specific industry sector, area, country, or company size.

Right-to-use vs. Community

One essential difference between Odoo and the „classic“ systems are their respective licensing models. Although you have to pay for licenses in Odoo as well, they are linked to the maintenance contract and the Enterprise package. In other words, if a customer no longer sees an added value in these products, he may either cancel the Enterprise contract or cease to extend it. As a consequence, the warranty expires, and Odoo is no longer obliged to fix programming bugs. The migration of the database has to be done by the customer himself (there are various approaches to solving this issue; they may not be convenient, but there are alternatives!), and the Enterprise modules have to be removed from the server. But the system itself and all its customizations can still be accessed and used.

The classic licensing model of closed systems (such as SAP and Navision) is an entirely different kettle of fish. You only purchase the right of use from these providers with your licenses, and once you stop paying for them, further access is no longer possible.

Migration and Data

Today, IT systems evolve considerably faster than 10 years ago due to the agile approaches in software development. Consequently, the question of updates has become an essential issue in the decision-making process. It is no accident, i.e., that Microsoft has switched Windows to a so-called „rolling release,” where versions have become an extinct species (which is, by the way, a feature taken from the Open Source world).

But new versions do not only have problems with changes in the front-end, but data also have to be migrated. It is, of course, easiest to have your provider operate your solution through a Cloud, which takes care of the whole problem, including the data issue.

However, relinquishing the sovereignty over your data while only being able to buy rights of use creates an unholy alliance, at least in our opinion. This will, after all, lead to a total dependency on the system provider in every respect.

In-house operation, whether on your hardware or in your cloud, would be the counter concept to the above. Here, the possibility to migrate data within the scope of a service contract is incomparable and hard to beat. Until now, we have always talked about a “migration project,” after all. As the term already implies, a project requires effort and timeframe.

Source Code  – future-proof security

Besides the rather obscure licensing models of many providers and the patent situation, there is another important reason why Open Source has become a worldwide success story in recent years: The source code becomes available with the installation. This is not about transparency, but about two aspects made possible by this fact:

1) Independence

Since the source code is made available with the installation, customers are independent of the provider. As long as the respective software is not a niche solution but finds a broad acceptance (as is the case with Odoo), there are other experts able to provide support and customized solutions – the 1,000 certified Odoo partners worldwide.

2) Future-proof security

Since the source is not only available for the adaptations but for the complete system, the community of platform users as a whole becomes independent of the provider. If there are developments not acceptable to the community or if the provider has financial difficulties, the project will continue under a different name as a so-called Fork, as past examples have shown.