When Is It Worth Rewriting a Legacy App?

Our team has done rewriting and refactoring projects for our clients, and we know how difficult and expensive technology migration is. We also know how switching to the right tech stack may skyrocket the growth of an app.

The key is to rewrite the legacy app when it's necessary (the old tech is truly obsolete) and beneficial (the new tech will bring some tangible return on the investment in the long run).

Suppose that you are developing a digital product that's built using an outdated technology.

Everywhere around you see these new smart solutions that work so fast and scale up effortlessly, while supporting your application is getting more and more difficult with no updates and a frustrated dev team who have to work with ancient tools.

At the same time, changing it is not easy — especially when you already have a product with real users and paying customers.

You need to plan the transition carefully. Sometimes it's better to let it be. Sometimes changing your stack can skyrocket your growth. However, to make the right choice, you need the advice of an experienced teamwho has seen it all.

When is it worth rewriting your app to a new technology? Let's start with a handy legacy modernization checklist prepared by our team.

Try answering these questions:

1. Is rewriting your legacy code in bulk the only solution?
2. Are there no parts of your project that could stay the old way?
3. What business objectives will the code rewrite help you achieve?
4. Can you see a clear ROI of the migration?
5. Is the technology you’d like to migrate to trending up?
6. Is there a large community of talented and ambitious developers gathered around the technology?
7. Is it used and supported by any of the biggest tech giants or has a large community?

Only if the answer to any of these is "yes," you should consider migrating to a new tech stack, but it still does not mean you should rewrite the code. It's just the beginning of the decision-making process you should go through very carefully. It's also best to get an experienced tech partner involved in consulting.

When do businesses rewrite their products to new technologies?

There are many reasons for changing your tech stack. Here's the list of the most popular.

1. When app maintenance becomes way too expensive - that means that the cost of infrastructure of resource-consuming apps is much much higher than in another, more efficient technology.
2. When the other technology is so popular that "everybody has to have an app in React." This is a coin toss. Following the hype can be the right choice if you pick a technology that will be used for years to come. But you may also jump on the wrong bandwagon and waste time and resources on migrating to a solution that won't stick.
3. When the code is messy, hard to maintain, and makes it impossible to add new features - this is another good reason to do it. However, you need an opinion from somebody you can trust. Sometimes it's not a question of the right technology, but the right people. Unprofessional developers have sabotaged many projects.
4. When you lack the talent to scale your business in a given technology. If there are no quality engineers available, it's either because the demand for this specific skill is rising, or the technology is dying and nobody wants to learn and use it anymore.
5. When some new features cannot be implemented with the current technology. However, you should remember that contemporary software is all about independent modules and services. You have to check out whether you can connect modules performing new functionalities to your old core, instead of rewriting everything from scratch.

When is rewriting a legacy app worth the effort?

You should go for a full technology stack transformation only when you know for sure that it's necessary. Here's the decision-making framework we use with our clients.

1. You need to define the problem you want to solve by the migration. If there is any other way to achieve your goals without switching the technology, you should go for the easy solution.
2. If there are no people able to support and develop your product, you should go for the migration. It's just a question of time until you hit the wall.
3. If you are unable to scale up your product any more with the current technology, you should also consider ditching the legacy software very seriously. Let me give you an example. You have an application that runs slowly and consumes a lot of resources on 50 instances on Amazon Web Services. You have to pay for AWS forever or rewrite the app in a new language and run it on just five instances. Such savings may justify the investment in the development needed for the transformation. You need to create a simple but realistic business plan and calculate the ROI.
4. If your app is unable to provide real-time functionalities and you need those. This is a tricky situation as in many cases you will be able to add this feature through an external service. If you need a real-time messenger to talk with your clients, you can do it by plugging in an external module without wasting time and resources on transferring the core of the app to a new stack.
5. If the tech blocks your growth plans. This is the case of the biggest tech companies. Facebook and Google decided to move to React, Angular, and Flutte because they needed to gather momentum to grow faster. A leap in their product's performance was the strategic goal of these companies.

Which technologies are outdated? What are their replacements?

The risks of migrating to a new tech stack

From the outside, it may look easy. You need to copy every functionality and every view and replace the old engine with a new one - written with a language and framework that's much handier.

You need to know that fitting the codebase to the output obtained in a different technology is often much more complicated than creating a new product from scratch.

Your dev team will have to write a new codebase and then adjust it to your infrastructure. Here just a few examples of the challenges you will face when running a code rewrite project.

1. Most of the fads are false. Don't fall for them unless you consult an experienced partner. You definitely shouldn't bet on Google Glasses or Segways.
2. Always try or at least consider alternative solutions to moving everything to a new technology.
3. Transferring to a new stack is risky. Old code is usually unclear in many places. The working app and its users make up a complex system. At times nobody knows how it works. Understanding the old code is a bumpy process and often exceeds the planned budget and deadlines.
4. Old apps are often not tested. You have to do the process top-down - rationalizing without experimenting and gathering feedback. At the same time, there's very little room for mistakes as your app's users cannot get a "slightly worse" version of the product even for a day. This will make them mad at you.
5. You can never be sure that replicating the logic and functionalities of the old application with the new technology will solve your problem. There will be new challenges that new technology will bring to the table. Sometimes you can replace old technology with a new one, but the old problems will stay.
6. In modular software development, integration tests are essential. It's great that you can add, remove, and replace any component of your application at will. This is very handy, but causes new challenges. Each module needs to be tested in the ecosystem it's going to work in. Unless you run integration tests, you cannot be sure that the new solution works properly. This is especially needed when you replace the whole code with a new programming language.

You need a rigorous analysis and perfect planning

Moving to a new tech stack is expensive. You need to realize this.

The only reason to do it is to move to a more modern programming language and framework that is trending. This means that talent is available, but it's not cheap.

Rewriting can be done in many different ways, and there is a lot of room for optimization, but it will be expensive. There's no other way.

You should treat the migration to a new tech stack as a long term investment.

You need to see more than one business objective that will with high probability be realized thanks to the latest solutions you and your team are going to implement.

It's not only about writing a new codebase, but also launching your app once again, only this time your user base will be using it and judging the new solution very harshly.

This is why modernizing a legacy app needs perfect planning - the time and budget estimations are extremely difficult.

If you are considering a codebase rewrite project, please run through the questionnaire above once again. If the answer is "yes", please contact us and let our team help you with this difficult project.

If you'd like to discuss your product in detail or have any questions, contact us and Netguru's experts will lend you a hand. Get in touch with us or estimate project.