Reengineering Legacy Software: What to Expect From Your Software Development Team
Table of Contents
In addition to guest posting on the UpCity blog, Mind Studios is featured as one of the Top Software Development Agencies in the United States. Check out their profile!
Legacy software reengineering is a pain in the neck for many a developer, though some find this work fascinating. It’s a tricky task with a lot of underlying potential problems, but for a business that’s been on the market for a while, has an existing app, and established business processes, updating that software to perform better is often a more sensible solution compared to building a new app from scratch. Hence, many companies go this route.
Let’s take a look at the process of reengineering, review some of the legacy system modernization strategies, and briefly acquaint you with the developer side of this process so that you don’t go in blind.
First things first: What is software modernization and when do you need it?
When do you need to update your software?
There are several reasons why you might need to update your mobile application or website at some point:
Performance issues
Cost of maintenance
Availability of qualified maintenance personnel
Security issues
Legislation compliance
Back in 2019, the US Government Accountability Office issued a report stating that most of the $90 billion allocated for information technology budgets was to be spent on supporting existing software; quite a few pieces of that software were heavily outdated.
That is to say, the older your hardware and software get, the fewer specialists with relevant experience are available to maintain it, and the more expensive such maintenance will become.
Software built twenty years ago will also most likely lack proper security, which both endangers users (if any sensitive information is involved) and might not comply with the latest data safety legislation.
Finally, the application might simply be slow to process data, which, if it is your customer-facing software, will result in poor user experience and the loss of end-users.
So what do you do with aging software?
Multiple approaches exist for software modernization, and reengineering is only one of them. To choose the right approach to modernize your legacy software systems, you need to identify clearly what problem you’re facing, and then choose the solution that best fits your use case:
Rehosting is for when your software is well-functioning but its hardware is outdated or too expensive to maintain.
Platform migration has the same considerations as rehosting but for platforms.
Refactoring is changing only some parts of the code without a complete overhaul; it’s used when a partial update is enough.
Rearchitecting is making changes to elements within architecture at module/component levels while keeping the overall structure intact. If we’re talking about server-based apps, the common approach is to split your application into microservices, small independent services which are loosely coupled by business logic. They can be responsible for sending emails, push notifications, chatting with customers, etc.
Reengineering software is rewriting most or all of the code; it closely resembles building new software. However, there are significant differences. It can be the case when programming languages are not maintained anymore (Perl, for example) or it is hard to find developers on the market that can support your current infrastructure. Performance limitations of programming language can also be the case: Twitter rewrote their backend from Ruby to Java for these reasons.
Hear From Industry Experts
Read the latest tips, research, best practices, and insights from our community of expert B2B service providers.
Software reengineering explained
The difference between reengineering and building new software is that to reengineer, developers will first need to reverse-engineer the legacy code. In plain speak, it means going through the source code of your outdated software in all its details by either examining or executing it. Only after completing the reverse engineering can developers start rebuilding and modernizing the code.
The logical outcome of this is that software rebuild through reengineering might take longer and cost more than building new software from scratch. So why do companies choose to reengineer anyway?
The biggest issue with true legacy software (i.e. software that’s been around for a while) is that oftentimes, it lacks complete documentation, and the personnel that built it is either not available anymore or can’t remember all the details.
At the same time, not all important functionality in software is always visible from outside the code. Simply put, in legacy software, there might be an element in code that is essential for business but is invisible to users. If the documentation from the software’s development is lacking or incomplete, such an element might be omitted from the new software, affecting the business in some way.
During reverse engineering, all the software code is carefully reviewed and documented for future application reengineering. This is the surest way to pinpoint every detail and ensure nothing is lost in the modernized software. If you’ve invested in systems of automation for testing purposes, it could sufficiently save the situation: you can recheck if your reengineering goes the right way by executing them on a new codebase.
However, it is important to note that reengineering existing systems does not include changing software architecture at the highest level, and neither does it include adding new functionality or new features. Some minor rearchitecting might be done where necessary but essentially, the code is modernized within the scope of the existing architecture. That is one of the reasons companies go for reengineering instead of building new software: on the highest levels, the application stays the same while performing better.
As for new functionality, reengineering does not include it, but it makes it possible in the future — by creating detailed documentation and updating the code to enable modern integrations.
Software reengineering process
There are three main stages to legacy systems reengineering: reverse engineering, code restructuring, and forward engineering.
Reverse engineering
As I’ve mentioned above, reverse engineering is the process of examining the source code of the legacy software in order to rebuild it without missing important details. Developers can do static or dynamic reverse engineering of code. Static is the literal code examination, while dynamic is the execution of code under close monitoring.
After analyzing the legacy code, developers will be able to decide what needs to be done as a legacy modernization strategy: whether rehosting or platform migration would be enough to fix the problem or if more substantial work is necessary.
(In some cases, the verdict might be to discard the original code altogether and build a new application based on requirements recovered from old software and from current business needs. But this will not be reengineering anymore.)
Code restructuring
Upon completion of reverse engineering documentation, it’s time to start making changes.
Restructuring can be further broken down into substages depending on the results of reverse engineering. Sometimes, developers will include refactoring and rearchitecting here. Other times, you’ll hear terms like code modularization and code covering.
Code modularization is used to improve software performance and it entails combining code parts into modules to decrease the number of calls in code. The elimination of redundant code calls results in faster processing and increased performance.
Code covering is the process of adding APIs to legacy software. This makes it possible to integrate the software with other systems in the future.
Forward engineering
Finally, forward engineering is the process of recreating the initial application but with new code. Basically, it means that outside, everything is the same as it was or close to that; on the inside, however, the new systems and code enhance the performance, fixing everything that was outdated.
Forward engineering is the part of legacy reengineering process that’s the same as developing new software. It uses requirements compiled during reverse engineering for software rebuild in order to build a replica of the legacy application with the new code. The replica then replaces the old application.
Final thoughts
As far as legacy software modernization strategies go, reengineering is the most complex and resource intensive. It consumes a substantial amount of time and money. However, the older the software a business uses/offers, the more sensible it is to employ a software reengineering solution instead of building a new application without first reverse engineering the legacy code. A business might lose important data by disregarding the legacy code without much thought.
Finally, for an outdated yet well-built application, software reengineering & migration might end up being cheaper and faster compared to creating a new application. It will also preserve the legacy code’s documentation for future use.
The key here is to analyze legacy applications in detail and consult experienced developers before making a decision to either build new software or reengineer legacy code.
About the author
Svitlana Varaksina
A researcher at heart, Svitlana has spent the last four years covering all things software development, from tech side to business side. She believes the best writing happens when a writer works to, first and foremost, help readers gain new insights and knowledge; marketing comes as important yet secondary goal to offering valuable content.
Table of Contents
In addition to guest posting on the UpCity blog, Mind Studios is featured as one of the Top Software Development Agencies in the United States. Check out their profile!
Legacy software reengineering is a pain in the neck for many a developer, though some find this work fascinating. It’s a tricky task with a lot of underlying potential problems, but for a business that’s been on the market for a while, has an existing app, and established business processes, updating that software to perform better is often a more sensible solution compared to building a new app from scratch. Hence, many companies go this route.
Let’s take a look at the process of reengineering, review some of the legacy system modernization strategies, and briefly acquaint you with the developer side of this process so that you don’t go in blind.
First things first: What is software modernization and when do you need it?
When do you need to update your software?
There are several reasons why you might need to update your mobile application or website at some point:
Performance issues
Cost of maintenance
Availability of qualified maintenance personnel
Security issues
Legislation compliance
Back in 2019, the US Government Accountability Office issued a report stating that most of the $90 billion allocated for information technology budgets was to be spent on supporting existing software; quite a few pieces of that software were heavily outdated.
That is to say, the older your hardware and software get, the fewer specialists with relevant experience are available to maintain it, and the more expensive such maintenance will become.
Software built twenty years ago will also most likely lack proper security, which both endangers users (if any sensitive information is involved) and might not comply with the latest data safety legislation.
Finally, the application might simply be slow to process data, which, if it is your customer-facing software, will result in poor user experience and the loss of end-users.
So what do you do with aging software?
Multiple approaches exist for software modernization, and reengineering is only one of them. To choose the right approach to modernize your legacy software systems, you need to identify clearly what problem you’re facing, and then choose the solution that best fits your use case:
Rehosting is for when your software is well-functioning but its hardware is outdated or too expensive to maintain.
Platform migration has the same considerations as rehosting but for platforms.
Refactoring is changing only some parts of the code without a complete overhaul; it’s used when a partial update is enough.
Rearchitecting is making changes to elements within architecture at module/component levels while keeping the overall structure intact. If we’re talking about server-based apps, the common approach is to split your application into microservices, small independent services which are loosely coupled by business logic. They can be responsible for sending emails, push notifications, chatting with customers, etc.
Reengineering software is rewriting most or all of the code; it closely resembles building new software. However, there are significant differences. It can be the case when programming languages are not maintained anymore (Perl, for example) or it is hard to find developers on the market that can support your current infrastructure. Performance limitations of programming language can also be the case: Twitter rewrote their backend from Ruby to Java for these reasons.
Hear From Industry Experts
Read the latest tips, research, best practices, and insights from our community of expert B2B service providers.
Software reengineering explained
The difference between reengineering and building new software is that to reengineer, developers will first need to reverse-engineer the legacy code. In plain speak, it means going through the source code of your outdated software in all its details by either examining or executing it. Only after completing the reverse engineering can developers start rebuilding and modernizing the code.
The logical outcome of this is that software rebuild through reengineering might take longer and cost more than building new software from scratch. So why do companies choose to reengineer anyway?
The biggest issue with true legacy software (i.e. software that’s been around for a while) is that oftentimes, it lacks complete documentation, and the personnel that built it is either not available anymore or can’t remember all the details.
At the same time, not all important functionality in software is always visible from outside the code. Simply put, in legacy software, there might be an element in code that is essential for business but is invisible to users. If the documentation from the software’s development is lacking or incomplete, such an element might be omitted from the new software, affecting the business in some way.
During reverse engineering, all the software code is carefully reviewed and documented for future application reengineering. This is the surest way to pinpoint every detail and ensure nothing is lost in the modernized software. If you’ve invested in systems of automation for testing purposes, it could sufficiently save the situation: you can recheck if your reengineering goes the right way by executing them on a new codebase.
However, it is important to note that reengineering existing systems does not include changing software architecture at the highest level, and neither does it include adding new functionality or new features. Some minor rearchitecting might be done where necessary but essentially, the code is modernized within the scope of the existing architecture. That is one of the reasons companies go for reengineering instead of building new software: on the highest levels, the application stays the same while performing better.
As for new functionality, reengineering does not include it, but it makes it possible in the future — by creating detailed documentation and updating the code to enable modern integrations.
Software reengineering process
There are three main stages to legacy systems reengineering: reverse engineering, code restructuring, and forward engineering.
Reverse engineering
As I’ve mentioned above, reverse engineering is the process of examining the source code of the legacy software in order to rebuild it without missing important details. Developers can do static or dynamic reverse engineering of code. Static is the literal code examination, while dynamic is the execution of code under close monitoring.
After analyzing the legacy code, developers will be able to decide what needs to be done as a legacy modernization strategy: whether rehosting or platform migration would be enough to fix the problem or if more substantial work is necessary.
(In some cases, the verdict might be to discard the original code altogether and build a new application based on requirements recovered from old software and from current business needs. But this will not be reengineering anymore.)
Code restructuring
Upon completion of reverse engineering documentation, it’s time to start making changes.
Restructuring can be further broken down into substages depending on the results of reverse engineering. Sometimes, developers will include refactoring and rearchitecting here. Other times, you’ll hear terms like code modularization and code covering.
Code modularization is used to improve software performance and it entails combining code parts into modules to decrease the number of calls in code. The elimination of redundant code calls results in faster processing and increased performance.
Code covering is the process of adding APIs to legacy software. This makes it possible to integrate the software with other systems in the future.
Forward engineering
Finally, forward engineering is the process of recreating the initial application but with new code. Basically, it means that outside, everything is the same as it was or close to that; on the inside, however, the new systems and code enhance the performance, fixing everything that was outdated.
Forward engineering is the part of legacy reengineering process that’s the same as developing new software. It uses requirements compiled during reverse engineering for software rebuild in order to build a replica of the legacy application with the new code. The replica then replaces the old application.
Final thoughts
As far as legacy software modernization strategies go, reengineering is the most complex and resource intensive. It consumes a substantial amount of time and money. However, the older the software a business uses/offers, the more sensible it is to employ a software reengineering solution instead of building a new application without first reverse engineering the legacy code. A business might lose important data by disregarding the legacy code without much thought.
Finally, for an outdated yet well-built application, software reengineering & migration might end up being cheaper and faster compared to creating a new application. It will also preserve the legacy code’s documentation for future use.
The key here is to analyze legacy applications in detail and consult experienced developers before making a decision to either build new software or reengineer legacy code.
About the author
Svitlana Varaksina
A researcher at heart, Svitlana has spent the last four years covering all things software development, from tech side to business side. She believes the best writing happens when a writer works to, first and foremost, help readers gain new insights and knowledge; marketing comes as important yet secondary goal to offering valuable content.
