the risks of classic systems

Anyone getting involved with classic software systems should be aware of the risks involved. These include:

1) Right of use

The most significant risk is probably the right of use of many mainstream services, further exacerbated by the dismantling of local infrastructures in favor of cloud solutions. This has naturally attracted many manufacturers to make their systems available as cloud solutions. The risk of in-house operation has transferred to the manufacturer, who – after all – should know his system best and should be able to operate it more securely. Moreover, this solution has the added advantage that there is no need to finance a license package. Instead, the user may switch to a subscription model usually associated with such a license deal, which is also – if looked at by month – much cheaper.

Patches and Updates are usually also included in the manufacturer’s offer.

So much for the win-win-situation, which is obviously attractive for both sides; otherwise, the subscription model would not have established itself almost everywhere.

However, there is a price to be paid for this kind of model – the temporary right of use. In other words, you do not buy the right of use once and for all, but only for the period you pay for. What is more, the system sovereignty lies with the manufacturer, on explicit request.

To paraphrase, your own data lie with the manufacturer, and you can only purchase a temporarily limited right of use to work with the system and thus with your own data.

There may be some commercial sense in that, and the definition of the term „reason“ may be very flexible, but on closer consideration, one cannot deny that there is a certain amount of risk involved.

2) Data

As discussed in the previous paragraph (and indeed in the last blog), data are integrated into the cloud solution described above. At the time of purchase, the future user will seldom consider if, and how, a potential export from the ecosystem might be accomplished, and, above all, how extensive it would be.

Reports or exports are usually provided, but they are typically intended to be part of the work process and not for a scenario where you plan to abandon ship. Since nothing is built for eternity, much less in IT, it is advisable to look for an emergency exit before entering a room.

We often find that exports are not a matter of course, after all, especially with migrations. The database images or complete backups usually offered are not really helpful since the data structure does not provide any transparency at all. The reason behind this is that the database structure is often complicated and difficult to understand for outsiders. Still, this is a relatively easy problem; it becomes almost impossible to find and interpret in-process fields and values or their inter-dependencies.

A comprehensive export function is, therefore, not a bad thing, at least in principle. Reports do not really help here; they rather resemble the windows of a house; you can only see a limited area when you look out of it.

3) When does it get unpleasant?

So when does all that become a problem? After all, the classic solution in IT is one of two traditional models. The alternative, i.e., open source, has only established itself in recent years. How can there be an issue with a “tried and tested“ model?

The usual

The most critical point is to get software to production. Once this step has been taken, the most challenging part has been done. But it becomes difficult if you start having problems. There are many and varied reasons for that. To name only a few:

  • The software manufacturer has been taken over, and the software is discontinued.
  • The manufacturer himself is discontinuing the product.
  • Your own company has grown; a new client has to be created, but the solution is not multi-client capable.
  • Although your company’s growth requires an international set-up, your system is not multilingual.
  • Processes have changed, and the software does not fit anymore.
  • The solution did not cover all areas to begin with (maybe because it started out as a specialized solution), and the workarounds are no longer feasible.

Out-dated technologies

Many of these classic solutions are not web-based at all or only in part, since they have their origins in the pre- or post-dot.com era. In the current times, however, when growth sometimes goes beyond our own limits, client-server-architectures pose a problem since they do not include customers or suppliers via a portal solution.


However, problems may also arise from a completely different direction, e.g., if a company tries to save costs on upgrades. IT is fast-living, and software becomes obsolete quite rapidly, mostly due to web technologies and particularly to the process of Continuous Integration (https://en.wikipedia.org/wiki/Continuous_integration or https://de.wikipedia.org/wiki/Kontinuierliche_Integration ).

Here, versioning is a clear indicator: Firefox is available in a version higher than 80, as is Google Chrome. The intervals between the releases of new versions have become very short, going from years to mere months. This way, new functions are quickly brought to the users, and the changes remain small. The providers have refrained from sub-versioning, as the increasing number of new versions and plans would be too extensive. Today, the providers simply collect the users‘ requirements, evaluating and implementing them according to priority.

This development has further accelerated the aging process of software.

If you cannot keep up, you’ll quickly find yourself facing an old piece of software. And then there is only one thing left to do: Start over.

It gets even worse if you are put under pressure by unforeseeable external circumstances. No system runs on its own; there is at least an operating system, which in turn consists of different components. If a severe problem is discovered here, the system may certainly be sealed off from the outside. But if the hardware fails, and the old operating system can no longer be run on the new hardware, you are in an even tighter spot. Virtualization may be an option, but even that will, at some point, stop supporting older systems. That will be the definitive end of the journey, and it will come unplanned and usually quite fast. Action is needed; a solution has to be found quickly. Easier said than done, though.

4) What then can be done?

Unfortunately, this question is very challenging to answer because only three things are certain: everyone puts on their pants one leg at a time, there are no miracles, and the guy in slippers does not have any experience with IT.

Upgrade? – If that is still possible (which is rarely the case), it will undoubtedly be costly. Any other solution will end up with a new implementation anyway. Then you have the time to take a good look at all potential candidates since a new approach will certainly take time.

Odoo, with its modular structure, may be an alternative. An integrated system, of course, has the advantage that the information you enter in front is passed slowly through the system, there is no break in between, and you do not have to enter anything manually. But if you do not have the luxury to wait for a new implementation, you probably don’t have a choice either. In other words, for the most critical areas, the system is used in standard mode and limited to a lean set-up. It also means that there is no smooth transition. Therefore, at the beginning (wherever it may be located), data from the old system has to be entered manually into Odoo. It may not be practical and undoubtedly uncomfortable for a time, but at least it is digital. But this way, at least you have a reliable base and can roll out further modules from there.

Other than that, you can only say one thing: no system is better than a bad one. In other words, if you can afford it, rely on Excel lists and a reliable organization of your internal process. This may even be an option for bridging the gap.

19 October, 2020
share article
Sign in to leave a comment
intuitive user interface