Upgrade of the ERP system – how, when, why?
Upgrade of the ERP system – how, when, why?
When one hears the phrase “system upgrade” they often get reluctant. It is associated with a time-consuming process, disorganizing the present work with the system and requiring financial outlays, and in fact, not very effective. Is it so? Should we treat every version update as an “upgrade” and what are the premises to run it? We’ll answer!
Is every update an upgrade?
The above concepts are often confused, which can cause misunderstandings and misinterpretation. An update is a minor technological change, most often in the form of uploaded patches provided by the software manufacturer or the system maintenance service provider. Their job is to fix bugs or add new functionalities without having to run full tests. We start talking about an upgrade starting from a certain (not rigidly defined) scale of uploaded improvements. Due to the lack of a universal definition of an upgrade for the purposes of this article, these will be the activities that change the operation of the system to such an extent that they require full testing.
What is the difference between technological upgrade and reimplementation?
We have already distinguished an upgrade from an update, now we are going to describe the division of upgrades according to the purpose and method of their implementation.
Technology (technical) upgrade can be specified as simultaneous upload of a large number of patches received as a ready-made patch package from the software manufacturer to your environment. The scale of changes is so large that it is necessary to test the system. Often, it will also be necessary to adapt to the new version of modifications or interfaces built for the previous version. With this approach, however, we do not assume redefining key processes, changing data structure, migration of data.
Reimplementation means implementation of a new version in a manner that assumes a change in key processes, a change in the data structure and therefore the project will require both the analysis phase and the data migration phase. Sometimes we will also have to schedule user trainings which will take place in a situation the processes or the system change to the extent the users may not be able to cope on their own with.
Why do we sometimes run only the technology upgrade and not the full reimplementation?
The rationale for reimplementation may be: new functionalities available in the standard of the new version which can replace the previously used customizations, new business needs (e.g. the need to change the chart of accounts, opening a new branch) or the quantity or quality of data caused by long period of use of the system. In a situation the rationale for the software update is purely technical (e.g. lack of the manufacturer’s support in the maintenance of a given version or lack of technological compatibility between all infrastructure components) technology upgrade is a sufficient solution.
Below we answer some frequently asked questions or ambiguities related to updating of the ERP class systems.
- Regular uploading minor updates or less frequent running complex upgrades. Which solution is more advantageous?
Regular upgrading the system ensures no accumulation of technical debt and regular running of tests of the introduced changes. One should also remember that some of the uploaded patches do not change anything in the daily operation of the system but are responsible for, for example, data security which should be a priority at every stage of its operation. From the financial point of view it is difficult to estimate which solution is more beneficial. However, it can most certainly be said that large upgrades are a big challenge from the perspective of competences and handling a large number of changes at the same time, which translates into obstructions in technical support for users.
- Which version of the system to choose at the moment of production launch?
We have discussed with our clients on numerous occasions the issue which version of the software they should choose for the go – live. We always emphasize that the latest available version, although it provides a longer service life without having to make updates, is also the least tested and least stable version. We encourage our customers to use the latest available version when they enter the testing phase and then use it during the start-up.
- What happens to the data during reimplementation?
There are two paths to choose from during reimplementation. The first is data migration, i.e. transferring it from the old system to the new one. However, change of the system is often a good excuse to organize the accumulated data, so the other path to choose at this stage is its migration combined with cleansing. For this purpose we create scripts that catch errors (e.g. duplicated tax identification number or contractor, incorrect zip code) which then must be automatically or manually verified and supplemented.