Migrating, refactoring, or rebuilding a legacy application? A decision framework for IT executives

You already know that the digital applications and tools you use every day are not eternal. Every so often, and increasingly frequently, they require updates that improve data security aspects, or they are optimized for operating system updates, patched, new features added… and thus you keep going for as long as possible to maximize your investment. And beyond the pure economic cost, the learning time for the new tool is also important, or the configuration and customization, overcoming resistance to change… there are many reasons why the maxim of “if it works, don’t touch it” is often the most considered by many companies. And they are right. 

However, there comes a time when those applications or systems can no longer do more, they have become obsolete for your day-to-day or, there is no option here, the developer withdraws it from the market and leaves it without support. It is time to take the leap and migrate. The problem is how to do it without production breaks and without hidden costs arising with the new solution.

It is a justified fear, because many of those applications you use every day are strategic and fundamental for your operations, and modernizing software can lead to serious incidents such as production line stoppages or billing failures. Today, with almost all processes digitized, systems are a critical infrastructure for almost any business model or organization. Halting a billing or warehouse logistics program can entail economic or reputational costs that are difficult to recover from. So, as with so many important decisions for your production, migrating from platform or application should be done like a leap with a net, and assume the least possible risks. In that sense, preserving as much as possible of the current system, respecting the legacy, is a good strategy.

Preserve, fix, or start from scratch

When systems start to become outdated and show signs that they need a deep update, many developers make the drastic decision to start from scratch by changing all the code from top to bottom, which they consider useless.

The same happens when a new developer is hired who did not create that code. They start digging and do not understand many of the things they find there, or they discover so many patches that it is almost impossible to recognize the original source. Others simply use it as an excuse to inflate the budget, which happens.

But in contrast to that instinctive reaction, and while it is true that sometimes it is the most advisable or the only option, there are studies by specialists that agree that about 70% of complete rewrites from scratch (Big Bang rewrites) fail, are canceled, or suffer massive deviations in costs and timelines.

We already said it was not an easy decision nor free of risks. Therefore, the most important thing is to know exactly what is failing in your current system, what needs are not being met, and where its shortcomings lie. From there, decide what to do with the current Legacy application, whether to maintain it, redesign it, or replace it with a new one. Let’s look at some guidelines on how to choose between these three paths.

What to do with the legacy application? Three paths for migration

Let’s get to the point. There are numerous proposals for analyzing the suitability of migration defended by large companies like AWS or consulting firms like Gartner. Sometimes, those guides are more of a complication than a clear map. We have reduced the roadmap to three steps: Migrate, Refactor, and Rebuild.

A. Migrate

This would be when you need to move a current application to a new platform, for example, another cloud provider, or a new server. This process, technically called Rehost or Replatform, should be simple and require minimal, if any, adjustments to the source code of that application.

• When it responds well: When the main problem is not your application but the infrastructure, such as hardware scalability or hosting costs, but your   application continues to function well.
• The limit: If the problem is not just with the platform on which your application runs, or if the code has become obsolete for the new platform, it will not be enough to just move it from one place to another.

B. Refactor 

We can consider it almost as a maintenance task. An update that is more or less deep that modifies the internal structure of the application and its architecture but does not alter its operation or interrupt the service. This is called Re-architect or Incremental Modernization.

One explanation of one of the most common strategies is the well-known Strangler Fig Pattern or Strangler Fig Pattern. This concept was introduced by Martin Fowler inspired by a plant that grows around a host tree until it gradually replaces it. For example, applied to your systems, placing a proxy or API Gateway at the perimeter of the old system. From there, new functionalities or refactored modules are developed as independent services, gradually diverting traffic from the legacy code to the new until the original monolith can be shut down without impact.

• When it responds well: When the accumulated experience, the updates already made, and its performance in the current business model is valuable and complex, but the system needs to modernize its internals, improve performance, or integrate new components that were not there before, such as Artificial Intelligence.
• The benefit: Since it involves tweaks to what already works and you know, it drastically reduces the risk of operational stoppages, allows for code validation in parallel to production for each module, and ultimately keeps the business running.

C. Rebuild

Here, the term in English is much more explicit: Rebuild or Full Rewrite. When there is nothing to leverage or doing so does not guarantee that it will resolve the problems that have arisen with the legacy code, the most practical thing is to write the code from scratch and develop a completely new product, discarding the previous one.

• When it responds well: When your software is absolutely obsolete or discontinued, the programming language is no longer supported in the industry, or the business model has changed so much that the original system is useless.
• The risk: As it is the most drastic and profound solution, it is not without risks. The most common is what we call The Parity Trap. It consists of that m while the team works on the new system (which can take between 12 and 24 months), the old system remains alive and accumulating changes, and the new development tries to achieve “feature parity” (feature parity), causing frustration, if not budget exhaustion. That is, it must be done agilely or the work and migration time will double.

If you have already decided to migrate your system, here are the basic precautions you should take

If you think the decision can still wait, then it probably can, and you can study everything calmly with the help of an expert who analyzes your real situation and indicates the best path to follow. But, if your operational continuity is at stake and you know you cannot continue as before, we can give you three tips as a lifeline:

1. Use Sandboxes or Digital Twins. These types of solutions allow you to test new developments under real usage conditions before it’s too late. Don’t change your application to see what happens, but test what could happen before changing it.
2. Study Open Standards. Anticipate the next time you need to migrate or update by trying to choose developments that guarantee you will retain governance, access to codes and data, and their usage license without legal restrictions or being tied to your provider (Vendor Lock).
3. Consider hiring In-Sourcing. If you need external help, there is the option of hiring teams that integrate into your organization as one more and share their knowledge, leaving the ownership of the code and its secrets in your hands. And it can be a golden opportunity to transfer senior knowledge to your team.

There are many more issues to consider, but here we aim to resolve the main doubts. In our day-to-day, we have seen all kinds of particular cases, and that is why we like to see ourselves as an internist doctor who analyzes the organism of an organization as a whole and not just as a specialist in certain technologies. Identifying what the pain is, where it comes from, and seeing where to put the remedy. If you share that vision, talk to us.