Let’s return to the 2000s, when you first developed a software platform that allowed your company to thrive for years. As the days went by, it grew to become an integral part of your business, so the number of operations it was needed for grew, too. As a result, the system ballooned in complexity; nearly two decades later, it is a labyrinth of tightly coupled services that needs to be modernized if you’re going to stay competitive and keep pace with technology. Thus, you are standing at the crossroads, considering various modernization options and trying to choose the most efficient. How can you save your platform’s value and make it more modern without spending all your precious resources? Let’s find out.
The process of modernization can include various options that match with different business goals. The most common of these options are rehosting, rewriting, and rebuilding. Each option varies in its speed of implementation and affordability. For example, rehosting is the fastest and the most affordable way to resolve a legacy software issue, but it can be applied only if the system was built consistently. Otherwise, you’ll have to modernize through a more complex option or even invest in full-system rebuilding.
Aiming to aid your decision-making process, we wrote this article to help you understand each of these modernization options and determine which one is right for you. First, let’s define what each of these terms means and talk about some situations where you might need them.
The Difference Between Rehosting, Rewriting and Rebuilding
OK, we’re at the crossroads now, and there are three paths we can choose from. They all lead to the same destination—your brand-new system, which is highly maintainable and ready for integration. They just get there in a different way. Now we are going to see what awaits us on each of these paths.
Legacy Software Rehosting
In simple terms, legacy software rehosting, also known as lift-and-shift, is a process of moving a legacy software application to a different platform, avoiding significant changes. This approach solves an issue of expensive maintenance by moving the system from its legacy hardware to modern hosting solutions.
However, in most cases, it is a “stop-gap” option until a new application is developed. Otherwise, it can be the first step toward application rebuilding, as developers can use some of the old parts once the app is placed on the modern platform.
An outdated software system can be rehosted both to virtual machines and new hardware. If you’re migrating the legacy software to virtual machines, the investment is low, so combined with the high success rate and immediate implementation, this option
is really attractive.
Besides, the working environment stays the same, and you don’t need to retrain the people who use it. By choosing to rehost legacy software on virtual machines, companies can decrease software maintenance budgets and gain time to prepare for further system improvements.
If for some reason your data needs to be hosted on-premises, you can move from the old mainframes to more modern hardware. This can resolve the issue of low performance as well as expensive maintenance without changing employees’ working environment.
However, in such cases, the software will remain the same, so you can apply this technique only if the system software itself is quite modern. Don’t forget that purchasing new hardware automatically increases the project budget.
Software Rehosting Process Involves
Advantages of Legacy Software Rehosting
The task here is to create an environment equivalent to the original source environment. Digging deeper into the topic, let’s see what application rehosting can bring to your business in practice:
1. No recertification or employee retraining
The system is moved unchanged to the new environment, so you can avoid additional checks and learning.
2. Higher performance plus lower maintenance costs
Rehosting speeds up the application and decreases maintenance budget by using a pay-as-you-go payment model.
3. The risk of a system disaster tends to zero
Moved to the modern platform-as-a-service (PaaS) platforms, a legacy software system is unlikely to crash, especially if it is hosted on a virtual machine provided by Microsoft or Amazon.
Disadvantages of Legacy Software Rehosting
The main disadvantage of rehosting is that this simple approach can’t resolve a complicated case. Therefore, rehosting is mostly used as one of the first steps in the modernization process, and companies subsequently move on to legacy software rewriting or rebuilding.
Legacy Software Rewriting
“Rewriting a business application is as arduous as the old process of republishing a manuscript, if not more so.”TMAXSOFT COMPANY
Legacy software rewriting is redoing the app’s code from scratch.
Rewriting legacy software is far more complex than simply rehosting it, as the development team must interpret the existing app’s logic first. Therefore, there is a need to analyze business processes properly that requires active client participation.
Trying to figure out the architecture of an existing app is not so easy, and trying to understand what is inside a legacy app is far more complicated, as it has often been changing for years without anyone documenting those changes.
As a result, we typically encounter a tangled piece of software, with no idea of the consequences we might face after changing any part of the application.
“According to both Standish Group and Gartner reports, more than 70 percent of legacy application rewrites are not successful.
The most well-known case is the rewriting of the old payroll system for Queensland Health in Australia by IBM. The project, estimated at $6 million, failed when it was rolled out, leading to absolute chaos in payments. In the end, the Queensland government spent $1.2 billion to fix the situation.”
Just think about it: 70 percent, or approximately two out of every three rewriting projects fail. Why? First, source code translation is often done by hand, as we replace or add some features.
Second, apart from code, a team also must translate databases and data. Add one more challenge with differences in hardware and operating systems and we have an answer.
Plus, enterprises usually have several applications connected with each other, so rewriting them all can take years. It sounds like a trailer to the next Mission: Impossible movie.
Well, all jokes aside, the software modernization problems are quite common. Read here to learn more: 3 Common Mistakes in Legacy Software Modernization
However, let’s remember that 30 percent of rewriting projects are successful. When it works, rewriting legacy software can transform your business. Let’s learn more about the wonders rewriting can do.
Software Rewrite Process Involves
The approach involves making changes in software specifications, so before starting rewriting, development teams should define the purpose of the business process within the organization and the application itself. Then, they identify human activities within the legacy system and operations outside it to insert them into the process (in other words, features to add). At the next stage, engineers streamline automated and human activities inside the app by user roles and validate the model we’ve got. Depending on its results, the model will be improved and verified again and again until it is ready for the implementation.
Reasons to Start a Software Rewrite Process
There are a few reasons why companies decide to take a risk and start the complex rewriting process:
1. The possibility of making changes and adding needed features
This modernization approach allows them to both save their software core value and increase it by extension of app functionality.
2. Resolving performance, high maintenance costs, and inconsistent code issues
Apart from increasing software productivity, rewriting allows you to fix so-called technical debt, while Stripe and Evans Poll research shows maintenance of legacy systems and tech debt is the biggest hindrance to developer productivity (42 percent of developer time is spent on it).
3. The opportunity to revise the business process and its efficiency
As you already know, rewriting the legacy system first entails a detailed business process analysis and definition of tasks outside the software system. In this way, you can detect some inconsistencies and make needed improvements.
The most considerable disadvantage of this approach is its complexity, when the chances of data loss, errors, cost overruns, and extensive delays are high, and one bug in code can lead to a catastrophe.
Today, the chances of a rewriting project being successful is far higher than it was even five years ago because of tangible progress in technologies, moving from monolithic web applications to microservices in the same way we are using cloud instead of on-prem. We are convinced that in this next decade, rewriting will become far easier for companies to apply.
Despite the mentioned positive improvements in rewriting outcomes, rewriting legacy software is still a risky option, as sometimes a new system can’t fully replace the old one because of gaps in the planning stage. Thus, companies are sometimes forced to run two systems in parallel, which is entirely ineffective, especially after performing an expensive modernization project. Does this mean it’s better to invest a little bit more and turn to the rebuild option? Let’s find out.
Legacy Software Rebuilding
We’ve all noticed that the number of innovations in the world is constantly increasing, so it feels like the planet is turning faster today than it was just 20 years ago. This leads to dramatic changes in the business environment, bringing both new opportunities and new threats.
If your competitors apply those new practices, legacy software can become a vulnerability even though it was a strength just a few years ago. Rehosting and rewriting simply won’t harmonize the outdated system with new requirements, but rebuilding will.
Legacy software rebuilding is reconstructing the app’s components to improve the existing solution.
First, you need to assess the gap between the tasks your application can perform versus what you need to complete now and in the future.
Depending on this gap, you may need to apply a complete or partial rebuild.
Sometimes it’s worthwhile to rebuild a software system from the ground up, though it involves a substantial upfront investment. Full rebuilding allows you to tailor the system to the new requirements, making solid improvements and yielding all benefits of custom software development.
If most of the legacy system components are still useful, you can rebuild it partially and save on the project budget. In this case, a development team saves the most valuable parts and integrates new components into them. It’s like replacing broken parts in your car — you won’t replace the whole car if you only need a new transmission, right?
Software Rebuild Process Involves
The rebuilding process means a complex process of rethinking business specifications and changing the system logic configurations. However, business requirements remain the same — if they didn’t, it would be better to replace the system with a totally new one. Thus, we have a challenge here: we must considerably change the system, but keep it in conformity with the old business requirements.
Reasons to Start a Software Rebuild Process
There are three main reasons to get a challenging rebuilding project started:
1. The ability to fully rethink your business model and adjust operations
Changes involving business specification levels lead to changes in the application logic. It gives you an excellent chance to adapt to a new business environment and gain an advantage over rivals whose main advantage is, for instance, an innovative approach.
2. You can start from the very beginning and avoid old tech pitfalls
You may have some considerable inconsistencies in your application technology that can’t be fixed by rewriting. Rebuilding allows you to reorganize the application, changing the way it processes data, its codebase, and its infrastructure as a whole.
3. Even though you rebuilt from scratch, the system value remains the same
This is the main difference between rebuilding and developing an entirely new software: the application essence stays the same. If possible, the development team even saves the previous user experience to simplify a shift to a new system for users.
Of course, there are some disadvantages to rebuilding legacy software. First, it’s expensive, and most investments should be laid down at the very beginning. Second, it is risky — the more you change, the higher the possibility it won’t work in the end as it used to. But despite these drawbacks, rebuilding can be the most suitable path, so that investment and risk are justified. The main thing here is to determine whether this option is the right fit for you or not.
How to Make a Correct Choice
When you’re standing at this crossroads with three possible paths to modernize our legacy software, it’s essential to ask yourself three key questions. Once answered, these questions will give us some guidance on which direction to move. Keep in mind, they can’t replace a professional legacy software assessment, as there are too many aspects affecting the final decision. However, they will help you to prepare for the assessment process and get an idea of what to expect.
First, will the business processes change? If the answer is yes, you need to examine your business and make changes to the business processes and system architecture. Thus, rebuilding is your option. If your answer is no, let’s move to the next question.
Second, are you aiming to improve software maintenance performance only? In case you are dissatisfied with the tech quality of your software system, legacy software rewriting (or refactoring, in some cases) is an appropriate option.
If for any reason you just have to change the way application is hosted and it was built thoroughly, you are one of the lucky ones who can easily shift programs and data to open systems. That is one more reason to pay attention to the program quality at the stage of its creation, because thorough app architecture and existing code consistency matters at the modernization step. Otherwise, you’ll have to invest much more time and resources to renew the system.
The Bottom Line
In this article, we have talked about a lot of seemingly contradictory information that just goes to show that choosing a suitable modernization type for your legacy software is extremely challenging. That’s why it’s so useful to learn more about the available options — it will simplify any future interactions with software development vendors.
It’s always better to prepare first. Think about the industry you operate in. Has it changed during the last decade? Have those changes affected your business in a way that required you to adjust? Are you aware of new developments or innovative startups blowing up the whole business vertical? The answers to these questions will help you to define your current position and the gap between it and your aim — the system being a driving force of your business again.
We are sure you have people in your company who can catalyze the system modernization process. Involve management, IT, business, and other stakeholders to define business domains, bounded contexts, entities, value objects, and so on. Engaging employees into the process helps to create a system that works for the team, rather than vice versa.
Modernizing your legacy software isn’t easy but it’s essential. Get ready to start on a complicated journey, leading to the crossroads where you can choose the path that best fits your needs. It doesn’t matter which modernization option you apply. Anything is better than standing and waiting till your innovative competitors displace you on the market.