Technology stack migration for legacy systems

What are legacy systems (Legacy system)? According to Wikipedia, legacy systems are an old method, an old technology, an old computer system, or an application [1]. This definition does not, in fact, reveal the nature of the legacy system. I think the legacy system is first and foremost a software system that is still running and using, but has stepped into the software lifecycle aging period. It fits the so-called "dairy rules": Cows grow old and end up with no milk to squeeze; but at the same time, raising costs are rising. This means that legacy systems will gradually increase maintenance costs over time.

To maintain a software system, you need to understand the knowledge of the software system. If the knowledge is missing, it means that it will bring great obstacles and difficulties to the maintenance personnel. From this point of view, the so-called "legacy system" is the lack of a part of the important knowledge, so that maintenance personnel "know it but do not know why" software system.

The most radical way to rejuvenate a legacy system is to push it back and forth, but the cost is too high, and even if the system is redesigned and developed, the legacy system will still be the same. Alternatively, the legacy system can be refactored to improve the system design without modifying the system function. Only this refactoring is often the prelude to a major expansion or modification of the system, and it is not recommended to repay the "technical debt (technical debt)" approach if it is not absolutely necessary. Refactoring should be done at the same time as development, and should not be deferred to the end as a debt so as to pay high interest rates. Finally, there is a way of technology stack migration for legacy systems.

I. Factors in decision-making technology stack migration

So why the technology stack migration? is the original technology unable to meet the new business requirements? For legacy systems, there is always the need to extend the functionality of old systems to meet new business. However, this is not enough to support the decision to make a technology stack migration. Because, from the point of view of technology implementation, no matter what technology, can realize a variety of business functions, but is to pay the cost is different. Basically, this cost must be lower than the cost of the technology stack migration. In addition, today's software development often regards a software system as a complete ecosystem in which a wide range of technology platforms (including multiple languages and even multiple database paradigms) are fully permitted, provided that we can reasonably delineate the boundaries of each function (or service).

Any major decision involved in the architecture needs to be considered and weighed, and effective design decisions can be formulated only if the risk is fully identified. Personally, it is worthwhile to migrate technology stacks only when the following situations occur.

· The original technology can not guarantee the new quality requirement

In the whole life cycle of a system, the system from birth to development, aging and death, like people, is a process that can not be circumvented. The technology stack migration for legacy systems is simply a desire to inject energy into old systems through new technologies, like organ transplants, to cut and replace decaying parts. The system is aging, it will decay, because of the change in demand, resulting in the system structure becomes huge and chaotic. When we make a technical decision, we often make a reasonable decision based on the current requirements and existing technologies, and the team's technical ability is the most suitable for the scene. As a result, the technology stack migration is often due to "then WTF". The wise decisions made in the context of the time will be anachronistic. This is particularly evident in the satisfaction of quality requirements. For example, the system's requirements for scalability, performance, and security may change as new quality requirements are raised. These quality attributes are often not solved by old technology. Rackspace's case for log processing falls into this scenario [2]. Rackspace of the architecture of the log support, has undergone three major versions of the evolution, from the file server to the central database, and then to MapReduce, each technology stack migration is a quality attribute of the drive, have to.

· For strategic reasons

This is often due to the enterprise architecture factor. For an enterprise, it should be considered as a holistic ecosystem. For a growing enterprise, it will inevitably affect the IT system with the change of organization structure and business system of the whole enterprise. Generally speaking, there are two scenarios for an enterprise IT system architecture. The first is from scratch, according to the design of enterprise architects and Business architects, to plan all IT systems in strict accordance with the design blueprint. The second scenario could be a combination of different systems (perhaps because companies are merging other companies, such as mergers or acquisitions), or because different business needs have been purchased for different software systems. The first is a seemingly beautiful situation, but it is still possible that the planning blueprint does not meet the needs. The second situation is in the Long situation, which may eventually lead to the so-called "chimney system (stovepipe system) [3]", which requires great effort to integrate various systems.

In either case, once the technology stack transfer decision, it is inevitable that the enterprise strategic considerations. Of course, this strategy refers to the IT strategy, or the overall strategy of the enterprise has an impact on IT systems.

One of our clients is a large financial enterprise that offers a wide range of brand insurance and banking services. The enterprise's strategic goal is to embody the brand value, while the overall display of the platform role of the enterprise. This means that for the IT system, there is a need for consolidation and migration of a variety of business systems. The main core of the system is the management of customer data, the management of these data will affect the quality of service, marketing and product maintenance of the whole enterprise. Because of the development of the enterprise in the banking and insurance industry, it is through continuous mergers and acquisitions to promote its own development. As a result, there are many different systems in the IT system in fact. Customer information is scattered across the database of different systems. Customer data integration, not only conducive to the management of these information, to ensure the consistency of data, but also from the marketing perspective, you can through a consistent customer information to the customer's situation to make a comprehensive understanding of the development of better promotional strategies.

· The original technology provider no longer provides support

This situation is most helpless, but sometimes. One scenario is that the technology used (platform, framework) is no longer maintained by the vendor, which is more evident in open source projects. Another scenario is that the selected technology platform is upgraded without a good forward compatibility, making it difficult for the system to escalate. In architecture design, this binding concrete platform and technology approach, is actually a kind of reverse mode, namely "Supplier Lock (Vendor lock-in) [4]".

· The cost of using old technology is too high

It technology is not necessarily the cost of new technologies is higher than the old technology, in fact, with the technology innovation and Development, the new technology, the more cost can be better controlled. When the cost of old and new technology is much higher than the cost of technology stack migration, it is worthwhile to make the decision of migration. For example, one of our projects needs to deal with legacy systems that use a software company's product that must be running on a large server. This product mainly provides the processing of customer information. This is a product that exists for more than 10 years, and the subsystems that were added later did not use the product. Today, the product is not supported by a large number of customers, and the annual product licensing fees and the maintenance costs of large-scale servers are very high. Finally, we migrated the functionality provided by the product to gradually replace the product incrementally, reducing the cost of the system.

Two. Introducing a risk-driven model

The risk-driven model proposed by George Fairbanks (Risk-driven model) is very suitable for the technology stack migration of legacy systems. The so-called "risk-driven model" is to prioritize risks by identifying risks, and then to select the relevant technology based on the risk and then assess whether the risk is mitigated by an architectural approach [5]. In the technology stack migration of legacy systems, it is possible to introduce new problems to the system, reduce the quality of the system, or cause the cost of migration to be too high if the risk of the migration process is not identified in advance.

In my experience, the key risks that can be identified when a technology stack is migrated to legacy systems include:

The quality problems of the legacy system itself, such as tight coupling, lack of adequate testing, poor system maintainability;

Lack of sufficient knowledge to help us understand the entire legacy system;

The risk of cost, time and manpower;

Lack of adequate knowledge of new technologies for migration;

Lack of migration capability