Business applications become obsolete, the technology used is outdated, superseded and replaced by new technology. This happens time and again, in businesses of all industries. However, the change to a new system is usually very complex, as existing data from the old technology, such as mainframe systems, must also be migrated to the new software system.
Once a new replacement software has been selected, generated or developed in-house, the real challenge begins: data migration. Without sensible data migration, even the best software cannot be used for its intended purpose.
The first important step is to find out how the existing data is connected and how it can be transferred to the new software in the most sensible and efficient way. Often it is not just simple data sets, but a complex network of data and objects that are technically related to each other. In the case of insurance companies, this would be life insurance or health insurance contracts, for example. In the case of banks, these may be networks of customer data, credit contracts and real estate data. The structure of these objects is practically always represented differently in the new software. In addition, the objects are usually heterogeneous. In the case of insurance contracts, for example, there are numerous products at different rates — so not all contracts are the same.
Furthermore, there are no standard formats used by all systems. For example, if source data is available in flat files (data that contains various data records without structured relationships), but the target system needs Java objects to receive the data, a transformation is necessary for technical reasons alone.
Frequently, another challenge is that the software to be replaced has often been in use for many years. The costs of software to be replaced are constantly rising as licenses, server rentals and the associated overall operation get more and more expensive. This increases the pressure on the data migration project. With many years of use, historically accumulated special features have also crept in. These include, for example:
- Multiple use of fields that occur depending on time periods or different object types
- Storage of supposedly structured data in free text fields
- Systematic software operating errors
These peculiarities increase the complexity of the transformation rules that have to be defined by the company because they must first be recognized in order to be correctly transferred to the new system.
Another critical point is the dwindling know-how about the technologies to be replaced. At universities, many technologies are only mentioned, but no longer fully taught. This means that no new developers of these technologies enter the skilled labor market and the “old” specialists have often already retired or will do so in the coming years. In order not to face the difficulty of no longer having any skilled personnel, it is important to deal with the topic of “replacement projects” at an early stage.
Which systems does my company use? How future-proof and sustainable is this system? If you address these questions early on, you have excellent opportunities to ensure the smooth running of your company in the long term.
You can find more information about data migration here.
