Free online consultation available. Please feel free to contact us.

Legacy systems / Legacy integration

  • Glossary

"Legacy System / Legacy Integration"

This glossary explains various keywords that will help you understand the mindset necessary for data utilization and successful DX.
This time, let's think about "legacy systems" and "legacy integration," which are unavoidable elements in the practical use of IT.

What is a Legacy System?

A legacy system is a term that refers to an IT system that has been in use for a long time or that uses technology that is not the latest. It is a term that is often used to describe a situation where an IT system has not been replaced with one that uses new technology, as a negative situation.
When it comes to IT utilization, it is practically unavoidable to coexist with existing IT assets. How to deal with legacy systems is also an unavoidable theme when considering the practical use of IT.

What exactly is a legacy system?

When people talk about legacy systems, they are probably thinking of IT systems that are still running on mainframes. The most typical image is probably business systems that run on IBM i systems such as AS/400 and were developed using COBOL and other technologies from that time.

There are other situations besides mainframes that are referred to as legacy systems. For example, client-server systems using Windows, which were widely developed at the end of the 20th century, systems developed on older UNIX operating systems, and even systems developed with older versions of PHP that are still in operation are sometimes referred to as legacy systems. Tools developed in Excel and used in business are sometimes referred to as Excel legacy.

These are systems that were developed and are still in use using old technology, hardware that was introduced a long time ago that is still in use, or systems that use infrastructure and technology that is no longer supported. These are situations where you might be asked, "Why not switch to new IT?", and I think that these situations tend to be called "legacy."

Why are legacy systems considered bad?

So why do some people say that legacy systems are a problem?

First, they may not be able to respond well to the needs of the new era, which can prevent the use of IT from achieving results. For example, let's say you want to make your business systems smartphone-compatible, thinking that if your sales staff can use your business systems while on the go, it will greatly improve both work efficiency and customer response. However, if your business systems run on a mainframe, it can be difficult to meet these needs.

Older hardware also tends to have higher maintenance costs. For example, mainframes tend to have higher hardware maintenance costs. While it is necessary to consider attributes other than cost, such as high reliability, older hardware can be significantly inferior to newer IT in both performance and cost.

Legacy systems also have the problem of outdated support. For example, there are cases where client/server systems using Windows 98 are still in use, or where control systems using Windows 2000 are still in operation in factories, and the software used at the time of development is still being used, and support for the software has long since expired. This makes it more likely that security issues will arise.

When old technology is used, it can be difficult to secure engineers. For example, if you want to renovate a client-server system that was developed in the Windows 98 era and is still in use, it is not easy to find engineers who can develop properly using the programming languages used at the time (such as Visual Basic 6 or Delphi).

Common Legacy System Countermeasures and Failures

Of course, just because a system is old does not necessarily mean it is a problem. Even if a system is old, it may continue to be used in daily operations without any particular problems. However, if the problems and inconveniences described above are occurring, it will be desirable to update to a new system.

The effort to convert legacy systems into modern IT is called "legacy migration." However, legacy migration often fails when attempted.

Rewriting a system can be difficult

For example, when trying to rebuild a legacy system developed in COBOL using a new technology such as Java, it is not uncommon for the old system to be in a black box state, making it impossible to understand the current system specifications.

Even if you manage to decipher the current specifications after much effort, reimplementing them in Java will be costly, and specifications that could not be investigated may be omitted from the implementation, causing problems for the new system in business. Moreover, even if you go to the trouble of rewriting it in Java, the new system may not gain any new functions, and it may be difficult to understand the benefits of spending the money.

Automatic conversion often doesn't work well

Legacy system migrations are sometimes approached using methods such as automated conversion of COBOL to Java, but such migrations can create unmaintainable situations.

Because automatic conversion tools to Java do not decipher the design intent from COBOL source code and redesign it in a natural Java format, the output is often a cumbersome "Java source code that looks like COBOL" or simply source code that is difficult for people to read. This can result in something that is unmaintainable for anyone, as COBOL engineers cannot read it because it is Java, and Java engineers cannot read it because it is unnatural Java.

The transition to packaged products is often difficult

Sometimes packaged software is introduced to try to completely overhaul a company's business systems, or a migration to the latest cloud services is attempted to wipe out the problems, but these efforts are also known to be prone to disaster.

Legacy systems are often designed with a company's current business circumstances in mind. Packaged products and cloud services do not have this kind of advanced consideration for the company, so it is common for business operations to become unable to function after implementation.

Or, in order to make a general-purpose product usable in your company's business, a large amount of customization may be required. As a result, even if you have made a bold move to a new system, your business may not be able to function properly, and you may be forced to revert to the old system.

Old systems aren't used for no reason

If legacy migration were not particularly difficult, then IT systems around the world would be able to be migrated to new IT as soon as it was determined that there was a problem or that new IT was needed.

It would be easy to call old IT legacy and criticize it, while praising new IT. The real reason for using the term "legacy system" is that it is difficult to judge whether there are problems, but migration efforts are likely to fail.

"Legacy" doesn't just have a negative connotation

The word "legacy" is often used in a negative sense in the IT field, but the word itself does not originally have that meaning. Legacy simply means "heritage," and simply means something that has been passed down from the past to the future.

For example, the term "Olympic legacy" was often used during the 2020 Tokyo Olympics, but it obviously did not refer to leaving trouble for the future. The term was used to mean that the facilities built for the Olympics would be "a legacy left behind by the Olympics that future generations would be able to use."

IT systems that have been in use for a long time continue to be used because they have served a purpose for a long time. If an old system is simply a negative presence, it can simply be abolished immediately.

Legacy integration: Simply combine old and new systems

Rather, it is precisely because the old systems are still useful that the legacy system problem is occurring. If a legacy system can be abolished without causing any problems, then it is fine to just abolish it and there will be no problem.

So, what we want to think about is whether we really have no choice but to discard the benefits of the old system. If we can preserve the good things in a good way, it can become a healthy legacy.

There is a way to modernize IT by preserving the good parts of the old system without forcing a transition to a new system. This option combines the good parts of the old and new systems. Specifically, this is an approach that involves "integrating" the new system with the legacy system and utilizing them.

Streamline your old system

Legacy systems have good and bad parts, parts that are easy to migrate and parts that are difficult to migrate. We organize these and consider keeping only the "good parts" and "parts that are essential for business but are not realistic to migrate" in a compact and slim form.

Introducing new IT

We will introduce IT that is in line with the current era, such as utilizing cloud services. We will transfer operations that can be completed with this to the new system, and also work on utilizing IT unique to the new system (such as utilizing mobile devices). However, the new system may lack the positive legacy of the old system, and the essence that has been accumulated over the years.

"Integrating" old and new systems

The legacy system has been streamlined, retaining only its best features, and is then "linked" with the new system. This allows the data and functions of both systems to be combined and used. This allows you to take advantage of the best parts of the old and new systems without having to incur the cost and pain of migrating to the new system all at once.

A miraculous example of combining old and new systems

The idea of combining old and new systems may seem like a necessary compromise or compromise, but in some situations it can produce great results.

The idea of "combining old and new systems" may seem like a compromise or compromise solution in an unavoidable situation, but depending on the situation, it can even be "the catalyst for producing great results."

For example, suppose you still have a mainframe (such as an AS/400 or IBM i) and have been using a system written in COBOL for many years, and your in-house engineers are all COBOL engineers. In fact, this situation is still not uncommon. If you think, "We need to abolish the old IT and completely migrate to new IT," you may find it difficult to solve the problem.

But think about it. Are other options really bad? If you can wisely leave your legacy and think, "Just work with new IT," new possibilities will open up.

For example, by linking kintone with a mainframe, you can take a leap into advanced IT applications where kintone is used effectively in your business. Linking with Salesforce may enable you to achieve a highly integrated approach to sales and production activities. This is all combined with the strength and peace of mind of the stable operation of a mainframe, which provides rock-solid support for your business.

This approach of "leaping ahead and achieving success with the latest technology" can also be seen in the phenomenon of "developing countries where even the development of fixed-line telephone lines and electricity was uncertain, but then smartphones and 4G communications suddenly became widespread." This "approach to achieving a major turnaround" has even been given the name "leapfrog phenomenon."

⇒ Leapfrogging | Glossary

The idea of "combining old and new systems" also has benefits in terms of securing personnel, which is often a challenge.

With cloud services, there is no need to operate the system in-house, and in the case of cloud services used by field users such as the example given above, the "engineers in charge of legacy systems" and "in-house IT staff" can often be fully competent in using them, and there may not even be a need to secure new personnel. Even if you ultimately want to eliminate legacy systems, I think that in many cases it is more realistic to go through these intermediate stages and then gradually phase them out.

"Connecting" technology that freely realizes legacy integration

You may have realized that "legacy integration," which links old and new systems, is a powerful trump card in dealing with legacy systems. However, you may be wondering how to achieve this integration process. You may also be wondering whether your company is capable of developing integration processes that require full-scale programming, especially since you don't have the engineers to back them up.

However, there are methods that allow you to efficiently develop these various "integration processes" using only a GUI. These are "connecting" technologies such as "DataSpider" and "HULFT Square," also known as "EAI," "ETL," and "iPaaS." By utilizing these, you can smoothly and efficiently integrate old and new systems.

Can be used with GUI only

Unlike regular programming, there is no need to write code. By placing and configuring icons on the GUI, you can achieve integration with a wide variety of systems, data, and cloud services.

Being able to develop using a GUI is also an advantage

​No-code development using only a GUI may seem like a simple compromise compared to full-scale programming. However, being able to develop using only a GUI allows on-site personnel to proactively work on cloud integration themselves.

The people who understand the business best are the people on the front lines. It can be said that having these "people who know best" themselves be able to steadily create what needs to be realized, such as introducing and utilizing the cloud, utilizing data, and automating business processes, is superior to a situation where development cannot be carried out without explaining things to engineers and asking them for help every time something comes up.

Full-scale processing can be implemented

There are many products that claim to allow development using only a GUI, but some people may have a negative impression of such products as being too simple.

It is true that things like "it's easy to make, but it can only do simple things," "when I tried to execute a full-scale process it couldn't process and crashed," or "it didn't have the high reliability or stable operating capacity to support business operations, which caused problems" tend to occur.

"DataSpider" and "HULFT Square" are easy to use, but also allow you to create processes at the same level as full-scale programming. They have the same high processing power as full-scale programming, as they are internally converted to Java and executed, and have a long history of supporting corporate IT. They combine the benefits of "GUI only" with full-scale capabilities.

No need to operate in-house as it is iPaaS

DataSpider can be operated securely on a system under your own management. With HULFT Square, a cloud service (iPaaS), this "connecting" technology itself can be used as a cloud service without the need for in-house operation, eliminating the hassle of in-house implementation and system operation.

Related keywords (for further understanding)

  • EAI
    • It is a concept of "connecting" systems by data integration, and is a means of freely connecting various data and systems. It is a concept that has been used since long before the cloud era as a way to effectively utilize IT.
  • ETL
    • In the recent trend of actively working on data utilization, the majority of the work is not the data analysis itself, but rather the collection and preprocessing of data scattered around, from on-premise to cloud. This is a means to carry out such processing efficiently.
  • iPaaS
    • A cloud service that "connects" various clouds with external systems and data simply by operating on a GUI is called iPaaS.

Are you interested in "iPaaS" and "connecting" technologies?

Try out our products that allow you to freely connect various data and systems, from on-premise IT systems to cloud services, and make successful use of IT.

The ultimate "connecting" tool: data integration software "DataSpider" and data integration platform "HULFT Square"

"DataSpider," data integration tool developed and sold by our company, is a "connecting" tool with a long history of success. "HULFT Square," a data integration platform, is a "connecting" cloud service developed using DataSpider technology.

Another feature is that development can be done using only the GUI (no code) without writing code like in regular programming, so business staff who have a good understanding of their company's business can take the initiative to use it.

Try out DataSpider/ HULFT Square 's "connecting" technology:

There are many simple collaboration tools on the market, but this tool can be used with just a GUI, is easy enough for even non-programmers to use, and has "high development productivity" and "full-fledged performance that can serve as the foundation for business (professional use)."

It can smoothly solve the problem of "connecting disparate systems and data" that hinders successful IT utilization. We regularly hold free trial versions and hands-on sessions where you can try it out for free, so we hope you will give it a try.


Why not try a PoC to see if "HULFT Square" can transform your business?

Why not try verifying how "connecting" can be utilized in your business, the feasibility of solving problems using data integration, and the benefits that can be obtained?

  • I want to automate data integration with SaaS, but I want to confirm the feasibility of doing so.
  • We want to move forward with data utilization, but we have issues with system integration
  • I want to consider data integration platform to achieve DX.

Glossary Column List

Alphanumeric characters and symbols

A row

Ka row

Sa row

Ta row

Na row

Ha row

Ma row

Ya row

Ra row

Wa row

»Data Utilization Column List

Recommended Content

Related Content

Return to column list