Introduction To Legacy Systems Migration
Updated: Jan 19, 2023
Software migration in all its manifestations is a mushrooming trend. Just look at it: cloud migration services market size will grow 515.83 billion by 2027 compared to 2019. Meanwhile, the data migration market is predicted to enrich over $10.9 bn by 2025.
As seen, it's necessary to be on the same wave with partners and competitors. Here, we offer to dig deeper into the reasons, advantages, and options of migration, analyzing relevant case studies.
The Place Of Legacy Migration in IT Modernization Strategy
Legacy products are everywhere. Gartner defines them as "information systems that may be based on outdated technologies, but are critical to day-to-day operations."
But the adjective "legacy" is not just about the age of software or its tech stack. When a new application is inefficient and needs improvement/complete replacement, it's also legacy.
However, legacy is not a sentence, and you can use (and most likely already use) such apps without significant harm to your business. However, there are situations when it is impossible to do without drastic measures. For example, in the case of:
the unreasonably high total cost of ownership
time-consuming maintenance
limited software functionality
poor data protection
violation of regulations
In other words, if legacy software significantly affects the business development and/or the IT department efficiency, a business resorts to migration.
Legacy migration is a transition from a legacy product to a new one developed or supported by popular technology.
There are two main types of migration: lift-and-shift and business transformation.
In the first case, legacy migration is initiated by the IT department. Engineers conclude some software maintenance is cumbersome, and working with it is a technical bottleneck. This inconvenience does not greatly affect the business development. However, it is an obstacle to flawless operational activity.
Business transformation is initiated by management. It's a response to inefficient software operation, affecting a commercial activity. For instance, a fast-growing company uses a monolithic architecture that increasingly signals limited scalability capabilities. Management may decide to use the benefits of microservices, which can provide more agility and facilitate business expansion.
Options Of Legacy Enterprise Systems Modernization
The migration variations are directly dependent on the business requirements. When a legacy product transformation was initiated, the question "What's next?" can arise. Transition assumes two core scenarios: legacy system migration and legacy system modernization. To spot the difference, we spoke to Ievgen Chupryna, Software Architect at JEVERA.
Legacy System Migration
One-Shot Migration
M: Ievgen, there are two options for legacy system migration: one shot and parallel run. Let's begin with the first one. Could you please explain what is a one-shot migration and how it performed?
I: Sure. One-shot migration involves the transition of the entire infrastructure at one point in time. The company has to switch to a new holistic robust product, which functionality has been thought over for approx. 1.5 years before the development itself. One-shot migration requires a large, coordinated set of actions from a vendor who performs it. Cooperation usually takes place on a fixed price basis.
From an architect's point of view, the simplest picture of one-shot migration is as follows.
The company has a basic A system, a legacy B system, and a new B1 system. The task is to switch from B to B1 in one moment without negative consequences.
Sometimes making changes to A system can be costly or even impossible. Therefore, in addition to the new B1 system, a company may need a proxy. Here proxy will make B1 interfaces similar to the legacy B system's interfaces. The proxy will also be a sort of buffer, hiding from system A that it no longer works with system B. It will process requests from system A to system B, automatically directing them to system B1. The proxy presence will reduce the total cost of migration and keep system A as is.
Everything would be too simple if the migration process is limited to adding a proxy. To make the proxy work, a vendor needs to create customization modules that would make B and B1 systems the same in terms of business rules. To achieve it, a customer is obliged to "freeze" legacy system B: not to add anything new, on the contrary - to remove everything bulky. Thus, only if B = B1, a transition can take place.
The next stage of migration is new product testing. Testing process organization is one of the most time-consuming ones on a project. Often vendors create a copy of the new system B1. The proxy proceeds some requests from system A and routes them to B1. So, this way, you can check the system's strength and the validity of any component: billing or business rules, for example.
The one-shot migration process itself consists of several tasks:
to overlap flow requests to system A
to switch from legacy system B to new system B1
to turn on the traffic for further processing by proxy and B1.
М: Who uses such an approach in practice?
I: One-shot migration is the perfect case. It is used by industries like telecom, where industry protocols standardize communication between systems. In other words, one-shot migration is the right way when one system operating following standard protocols is changed to another system operating following standard protocols.
Sometimes you need to switch from a simple ready-made legacy SMS center to the new one. Here one-shot will also apply.
At last, it is possible to use this approach migrating ERP or CRM, for instance. To perform it, a vendor must have relevant expertise and create 90% of connectors for such migration itself. Consequently, the supplier will dig deeper only in 10% of the legacy product specifics. Meanwhile, in this case, we are talking about the high cost of services.
M: So, in all other cases, the business tends to parallel-run migration, am I right?
I: Absolutely. Sure, one-shot migration has undeniable advantages, like:
one moment switching
fixed price terms of cooperation
often, relatively low cost.
More about Monolith Contact Center Migration here.
However, there are reasons why management avoids using it.
It is not always business-friendly. Earlier, we talked about the need to "freeze" legacy system B. Its timing is equal to the development cycle duration. If we are talking about a 12 months project, you need to freeze the legacy but the working system for the same period. Commercial activity will suffer from it.
A one-shot migration project requires effort. It is necessary to make a leap and spend significant efforts on development & testing to further move to quiet maintenance.
Because of these issues, for a majority, the one-shot way seems unreasonable. Therefore, companies prefer parallel-run migration.
Parallel-Run Migration
M: Since the parallel run migration is a widespread option, I suggest dwelling on it. What is its peculiarity, and how is it performed?
I: The main difference between parallel run and one-shot migration is the gradual transfer of functionality. Parallel run migration project consists of several phases, the cooperation between parties conducted on time-and-material terms.
Parallel run migration provides simultaneous legacy B and new B1 systems operation. Functionality from system B migrates to B1 in a limited volume, the system A interacts simultaneously with B and B1.
Here, companies use middleware, acting as a switch. When a vendor transfers part of the functionality to B1, the middleware automatically switches the processing of the relevant A system's requests to B1. Meanwhile, the legacy system continues to process the rest of them. It happens until the vendor completely transfers the functionality to B1. After that, the middleware begins to perform the function of the above buffer.
In telecom, the parallel run migration algorithm looks like the following:
a subscribers migration strategy creation
customization of functionality required to serve a group of subscribers
testing of a new system
group of subscribers transition
monitoring of further systems' operation
You may also like: Middleware For Digital Business Transformation
M: When is it advisable to use parallel run migration?
I: Almost always. It is more thoughtful and secure. Any enterprise would prefer to move step-by-step through the minefield, always having an escape route. Specifically, this option is suitable for migrating large infrastructures that cannot be switched at once. It also applies if a business domain could be split and operate in different systems, for example, by subscription type (pre-paid, post-paid). When a company has a large audience, it should use a parallel run too. Perhaps the new functionality will not suit everyone - it is the risk of customer loss.
M: What are the pros and cons of this approach?
I: A business benefit of parallel run migration is obvious: it doesn't cause an extended downtime. In this case, a client also needs to "freeze" the legacy system. But such a period lasts a couple of months. Compared to the situation when the downtime period is equal to project duration, this perspective is more tempting.
Moreover, the parallel run migration minimizes the risks of failure. If the new B1 system does not cope with the flow, you can always return to legacy B.
There are also disadvantages to this approach:
it is usually more expensive than one-shot migration
unfortunately, a gradual transfer of functionality is never fast
it requires double operation effort for both new and legacy systems
Legacy System Modernization
M: What about legacy system modernization? What is the difference between migration and modernization?
I: Imagine a situation where part of the legacy app is efficient. But the work or appearance of some components is causing significant difficulties, for example, inconvenient interfaces. Or a company wants to keep the functionality but migrate to a new stack since the product has become difficult to maintain. In this case, it makes no sense to take drastic measures. Here, it is better to recode an app using a modern tech stack, improve an interface, remove inefficient features and add new ones making software more valuable for the business. If migration is a global process, then modernization is updating the base with new functionality.
Conclusion
Before diving headlong into migration, you should investigate the issue and define if it's an effective solution. Share your problem with us to receive advice on whether migration is an appropriate approach in your case.