Legal Issues Associated with Transitioning from Old Systems in System Development

Creating a new IT system for use in a company is a typical task for IT engineers. However, when we talk about “creating a new system”, it often also includes the process of “abolishing the system that has been used so far”. In this article, we will reinterpret the project of developing a new system from the perspective of “abolishing the old system”, and explain the various legal issues associated with it.

What Does It Mean to Transition to a New System?

The Lifespan of IT Systems is Not Eternal

IT systems used in businesses are not designed to be used indefinitely once they are created. Moreover, it is not always beneficial to continue using old systems indefinitely. While there is naturally some variation between companies and the purposes of the systems, as a rough guideline, a single system tends to be used for about 10 years before a management decision is made to replace it with something new.

In a span of 10 years, the performance of computers available on the market can change dramatically. For instance, a program that was not realistically implementable due to constraints such as the processing speed of computers 10 years ago (although it may have been a simple and excellent design from a human perspective) may now be implementable. Also, if a system has been in use for 10 years, the company’s workflow and internal rules may have changed significantly during that time. The code that has been implemented post-hoc to respond to these internal and external changes in the business environment may have become so complex and intricate that it is unrecognizable from the user interface. In such cases, even if users want additional features, it may become impossible for developers to implement them.

Older systems can gradually cause IT engineers to perform a lot of “manual” work (such as issuing queries to extract individual data). Ironically, as the system ages, it tends to “personalize” the work. When there are too many personalized tasks related to an aging system, and measures are taken to further “systematize” them, a project to develop a new system to transition from the old system is launched.

Development of New Systems Progresses Alongside the Abolition of Old Systems

As previously mentioned, many system development projects (though not all) often involve the aspect of transitioning from an old system. The system itself often switches discontinuously from one day to the next.

However, the progression of daily operations should be a continuous flow from the past to the present, and from the present to the future. While storing necessary past data, it is important to not hinder the progress of current operations and to propose superior “systematization” concepts for the future. Transitioning to a new system often comes with various challenges. These circumstances combine in complex ways, and the development of new systems and the operation and maintenance of existing systems become intricately related, creating an inseparable relationship.

What are the Steps to Transition to a New System?

When transitioning from an existing system to a new one, it is particularly important to properly migrate the data. The steps for data migration generally follow the following procedure.

1. Identify which data stored in the old system should be migrated to the new system. It is necessary to distinguish which data should be easily searchable from the new system’s interface, and which data may not need to be searchable from the interface but should be retrievable when necessary (such as during audits).
2. Export the data identified in step 1 that should be imported into the new system, in a format such as a CSV file.
3. Import the data extracted in step 2 into the new system.
4. Verify whether the data imported in step 3 is reflected in the new system, and confirm whether the migration has been done correctly. The results of the verification of whether the migration has been done correctly are usually documented as evidence through screen displays or printed reports (the so-called testing process).

Transitioning to a New System Can Be Challenging in Terms of User and Vendor Role Clarification

In the steps of data migration mentioned earlier, a common issue is determining to what extent the user side should manage this as an internal issue. Furthermore, for a general overview of the “user’s obligation to cooperate,” which is not limited to data migration but applies to system development projects as a whole, please refer to the following article.

https://monolith.law/corporate/user-obligatory-cooperation[ja]

In general, in a system development project, it is true that vendors often have superior expertise in system development (or rather, this is often the reason they are entrusted with the task). However, on the other hand, it is often the case that only the user side can discuss what their system “should be like”.

Considering these points, one possible role clarification is for the user to perform the aforementioned steps 1 and 4. To put it another way, during the entire data migration process, the “requirement definition” of the data to be migrated and the “acceptance” of whether the data has been migrated according to requirements could be organized as the user’s obligation to cooperate. Alternatively, if there is someone on the user side with extensive knowledge of the old system, it might be considered to assign step 2 to the user side as well.

If the company can handle the old system internally without outsourcing, it might be considered to outsource only the new system to the vendor. In this way, the role clarification between the user and the vendor can sometimes become ambiguous in data migration work. For a general explanation of what roles are expected of vendors and what legal obligations they will have when users outsource system development-related tasks to vendors, please also refer to the following article.

https://monolith.law/corporate/project-management-duties[ja]

Past Court Cases Related to Transitioning to a New System

In system development projects aiming to transition to a new system, there have been actual cases where troubles occurred and led to litigation. The case cited in the judgment below involved a failure in the data migration process, resulting in multiple data inconsistencies and bugs in the new system, as well as delays in the delivery date. The key issue was the obligations that the vendor and user sides each had towards the project. The conclusion was that the vendor side had violated their duty of care, which was defined as follows:

The defendant, in carrying out the data migration work under this contract, had the obligation not only to simply migrate the data from the old system to the new one, but also to operate the new system with the migrated data. Specifically, before starting the data migration work, they had to investigate and analyze the data to be migrated from the old system, understand the nature and status of the data, consider whether the data would cause operational problems after being migrated to the new system, and if so, decide when and how to correct the data. They then had to undertake the data migration work (migration design, development of migration tools, data migration), and ultimately, they had the obligation to operate the new system with the data migrated from the old system.

It is reasonable to recognize that in this case, they had the obligation to correct and resolve data inconsistencies in the data migration process.

Tokyo District Court, November 30, 2016 (Heisei 28)

This case involved a situation where the user side was supposed to take on steps 1 and 4, and the vendor side was supposed to take on steps 2 and 3. In other words, the vendor side had once taken on the extraction of data from the old system (step 2). Therefore, the court ruled that if the vendor, as a professional system developer, had taken on the extraction of data, they should have been able to consider in advance whether the data extraction process could be carried out smoothly.

However, what would have happened if the user side had initially agreed to take on step 2 (i.e., data extraction) and then failed in the extraction process? In this case, it is possible that the user side could be accused of violating their duty of cooperation if the delivery date was delayed due to their failure to conduct a preliminary investigation on whether the data extraction could be carried out smoothly.

Furthermore, such judgments are made not only based on the contract, but also on minutes of meetings that are kept in accordance with the progress of system development. The importance of meeting minutes is explained in detail in the article below.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Summary

Projects such as system development require both the user side and the vendor side to bear many obligations and proceed with meticulous communication. Therefore, in the aforementioned court case, even a slight change in the preconditions can easily reverse the party responsible, whether it be the user or the vendor.

Given the potential for a system to hold vast amounts of data and complex mechanisms that are unimaginable from the appearance of the screen, and the possibility that a slight difference in assumptions can significantly change the final judicial decision, it can be said that it is important to comprehensively manage the risks of new system development projects, including the abolition of old systems.