Legacy Migration - Preferably Avoiding Any Shortcuts

Introduction

Lately, I have been pondering something. I have come across projects like "legacy migration" and "host migration" for quite some time, but I feel like many of them are a bit too showy or gimmicky.

There could be several reasons for this, but this time around, I want to explore what kind of migration would be truly ideal, incorporating some wishful thinking and an idealistic view.

What is Legacy Migration?

Legacy migration involves moving a dated computer system to a modern and up-to-date system.

The majority of legacy systems were created in the early days of computers, like "general-purpose machines" and "mainframes". Nowadays, only a handful of companies, such as IBM and Fujitsu, provide these systems. Recently, there have been announcements that Fujitsu plans to withdraw from these systems in 2022 and 2030.

The METI DX report describes legacy systems as aging, bloated, complex, and black box systems - and this is the key reason for considering migration.

What is "Shortcut" Migration?

As mentioned earlier, the goal of legacy migration is to address the lack of support due to vendor withdrawal or other reasons, and to get rid of the complications, complexity, and hidden issues that have built up from numerous modifications since the early days of computer systems.

However, many of the migration projects I have come across often involve:

1. Migration from a legacy mainframe (which is no longer supported) to another mainframe (which is still supported for now)
2. Migrating COBOL programs within a legacy system to a new system using automated conversion tools

But do these really address the core problem of legacy systems, which is the reason for undertaking these migration projects?

Regarding the first point, there is a global trend suggesting that legacy systems will gradually fade away over several decades. While they have not vanished completely, their prominence is decreasing. It is unlikely that general-purpose machines will regain their position as the main platform in the future. I believe the first point is just a temporary fix until the next round of support expires.

As for the second point, issues like bloat, complexity, and black-boxing will not be resolved at all. In fact, using tools to automatically convert data might even intensify the problem of black-boxing.

In my view, this approach contradicts the initial purpose of legacy migration.

What is an Ideal Migration?

In simpler terms, it is a move that tackles the main issue of the legacy system—the very reason behind initiating the migration project.

However, in practical terms, we think that merely carrying out a comprehensive system migration may not completely fix the problem. We believe it is essential to complement it with a business-level migration, incorporating the use of that system.

Why Can't Systemic Migration Alone Solve the Problem?

For an ideally systematic migration, the following are essential for it to be successful:

1. Analyze the legacy system to be migrated, which has become bloated, complex, and a black box.
2. Build the target system optimized for a modern environment.

Those engineers who can tackle task (1) are aging or retiring, and it is not very appealing for younger individuals to willingly learn this field. So, finding people to handle it is challenging. Additionally, when combined with the additional requirement of being able to build a modernized system aligned with current technologies (2), securing qualified personnel becomes even more challenging.

Migration at the Business Process Level

From here on, the content will include some idealistic views and aspirations.

Migration at the business process level, from a system perspective, is no longer really "migration" but is closer to "modernization" or "replacement."

This approach involves building business requirements and systems together from scratch, using new technologies and packages that did not exist when the legacy system was originally developed.

Since the system is newly built in this method, the legacy system does not appear as a migration source, and knowledge of the legacy system is not required.

To initiate a project based on this approach, it is necessary to develop team members capable of defining business requirements from scratch, which is expected to require considerable time and cost.

However, if this can be achieved, it would allow the business to operate on a modern system with excellent scalability and flexibility, free from the constraints of legacy systems.

As a consultant, I hope to eventually share this grand ideal with businesses and work alongside them toward making it a reality.