Case study: Redo cannot be updated

Why throw a system away if it works?

This dilemma exists not only in the post-Soviet space but throughout the world. Inevitably,  there comes a moment when a company needs to decide that “it’s time”; when the complete replacement of an obsolete mechanism or process will make a striking difference.

Understandably, not everyone is ready to take the step of completely replacing older systems, at least not all at once, because it means investing money and time. An internal rule of Itera Research is: if you can do the money/time analysis – do it. In this article, we examine the reason why we adhere to such a policy and what it tells us. 

Starting point

This case was particularly difficult, primarily because the ERP system was written using outdated Microsoft technologies. The task was to uncover missing functionalities and provide further support and development. There were two options for development: 

  1. To refine the existing system OR
  2. Transfer the functionality to a new platform and continue development on new software.

The customer company for which the system was developed has been producing prototypes for precision sheet metal components for mobile, automotive, medical and industrial products since 1995. As it turned out, the customer lacked essential functionality to meet the current needs of the industry. In addition, the code was developed so long ago that there were simply no specialists who could support the current systems in place. These are rare dinosaurs that are difficult to find, to put it mildly. It had undergone several changes and been updated and refined by different developers and, ultimately, no longer satisfied the business owner’s needs.

As stated before, the system was very old. It was developed 15 years prior, at the start of the business. We easily uncovered several issues. Not only was the system developed and maintained by different developers, but there was also no documentation of the updates. So, in this case, it was simply impossible to evaluate the project. It was also extremely challenging to evaluate the development of a new system because it was not clear what was needed and what could be eliminated.

Furthermore, the purchase of ready-made software, in addition to the high price, did not meet the needs of the company. As a result, it was decided that it would be more cost-efficient and timely to create a completely new system.

Why Business Analysis Matters

Before starting the work, it was necessary to choose an approach: Evaluate time and materials or walk through the stages of business analysis, with additional technical analysis included.

This initial evaluation found the following: a lack of documentation, tasks that were superficially constructed, and no time to clarify details. When working with someone else’s code, it is difficult to determine the weaknesses and vulnerabilities in the architecture, which in turn, can lead to latency. Upon initial analysis of the current system, it was found that the segment of missing information was too large, thus it was decided to conduct a business analysis. 

Consistent communication is crucial throughout the stages of business analysis. We conducted a number of workshops, where our business analysts communicated with different departments, collected user experience, and found out, in detail, the flow for each employee. The client and his staff came to our office to improve the process several times throughout this process.

In addition, we conducted a full analysis of the competitors’ systems in order to find out all the disadvantages and advantages of the current functionality and find ways to improve those.

As a result, the customer understood the following:

  1. The approximate level of costs
  2. The duration of possible development 
  3. They received 
    1. an understanding of the details of the system
    2. an outline of the functionality 
    3. Documentation of the plans, assuring any development company could understand what it is and how it works, regardless of who is involved in the project.

Find. Throw it away. Refresh.

Our cooperation began in July 2019. After a series of workshops, we plunged into business processes to think over the addition of old modules and the functionality of new ones. In the process of studying the technical side of the implementation, the architect found a number of technical problems that, in the case of using the old system, resulted in future business problems.

This information was a clear sign that development of a new system was necessary. After providing all the necessary documentation for the new modules and calculating the number of hours for new development, in the case of working with both the old and the new system, we transferred the data to the client.

Having jointly assessed the risks, and the pros and cons of each of the options, it turned out that the development of a new system was even more profitable than adapting the old one.

As a result, a new ERP system was created.


Thanks to timely business analysis, the client saw the positive and negative sides of the existing system, estimated the risks and costs, and made a balanced and rational choice.