The last article in our series answered “Why modernize your legacy systems?” and now you may be wondering, what’s next?
Once you’ve decided that it’s time to modernize your application, the next step is figuring out how you should approach modernization. Is it better to rewrite your application from scratch, progressively rewrite, or partially modernize it?
While the best approach to modernizing legacy systems varies from company to company, there are some approaches we frequently suggest, and one that we highly recommend you stay away from, except in extremely rare scenarios.
This article will help guide you toward the best approach for modernizing your legacy application efficiently, affordably, and securely.
TL;DR:
Let’s get straight to it; rewriting a legacy code base from scratch may seem like the solution to your problems, but it’s not something we recommend. Rewriting code takes a significant amount of time and effort, and often quickly becomes outdated, leaving you back to square one.
A better solution in nearly all scenarios is to rewrite or refactor code piece by piece, gradually making it cleaner and more efficient with each update. This approach is more cost-effective and it allows for a better return on investment while giving you the opportunity to focus on the parts of the code that are most important to update and may need to be frequently changed.
Why is a full rewrite from scratch almost never recommended? Because legacy code has been developed and tested over a long period of time by real users, providing valuable information that cannot be replicated by starting from scratch.
In short, don’t rewrite your app unless you absolutely have to! But don’t just take our word for it… Read on to learn more about the common approaches to modernization, and the use cases of each approach, as well as the very rare instances when a full rewrite may actually be the right path to modernization!
What are the Approaches to Modernizing a Legacy Application?
Whether it be a complete rewrite or just partial modernization, the approach can look vastly different depending on the needs of your company. We’ll lay out the methods commonly used for modernizing legacy systems, along with use cases, and the advantages and drawbacks that may be associated with each approach.
1. Complete Rewrite
A complete software modernization entails abandoning the old system and starting fresh with a completely new system. This can be done by either rebuilding or rewriting the application component to preserve its scope and specifications or replacing it entirely to meet new requirements and needs.
This process involves a complete upgrade of all software aspects, including the structure and business logic, resulting in a completely different solution with new scope, structure, and system components. However, there are two distinct approaches to this approach: a complete rewrite from scratch and a progressive rewrite process.
A Complete Rewrite From Scratch
A complete rewrite from scratch is the process of completely rebuilding an existing system or application and starting anew with a completely new application. This approach is often done with the intention to improve efficiency, performance, security, and functionality, and to address major problems or limitations in the original version.
Why Avoid a Full Rewrite From Scratch?
It may seem appealing to address a problematic application by starting fresh; hoping to replicate the positive aspects while avoiding past mistakes. However, this approach is often ineffective for the following reasons:
- Bugs will not necessarily disappear when you completely rewrite your legacy code, and the amount and severity of new bugs may be higher after the launch.
- Users may react negatively to a complete software rewrite and the probable downtime that comes with redeployment.
- The high cost of a total rewrite.
- The predicted (and unpredictable!) time needed for a complete rewrite.
- Different specifications between old and new features.
- Team needs additional training to work in a completely new environment.
- A risk of legacy system data loss.
- If the rewrite process takes a lot of time, users may see a lack of improvements and switch to competitors, before the new version is launched.
When to Consider a Full Rewrite From Scratch?
Our experts consider this approach risky, complicated, and time-consuming, there are a few occasions when a total rewrite might be suitable, such as:
When a legacy system can’t perform its tasks anymore or is fully broken: In this case, it is almost impossible to perform progressive updates, and a new environment may be the only solution.
For a very small application: If a rewrite can be done in a super short time period without much effort, then it might be a worthwhile endeavor (although to refactor code would still work well too!)
Your software is nearly impossible to maintain: If you are spending a lot of time and money attempting to maintain a legacy system, it may be worth seeking an expert consultation to see if a rewrite from scratch would be a more efficient use of time and money.
A massive change of scope: If the vast majority of code (like 90%) is no longer needed due to changes in requirements you may end up doing a complete rewrite from scratch.
If you’ve tried other approaches and they’ve failed: When no other approach, including progressive rewriting and refactoring, has succeeded to fix what is broken, then a complete rewrite from scratch can be considered.
Expert Tip: Bad code quality should almost never be the reason to perform a full rewrite from scratch. Instead, align the team on code quality practices and improve gradually while continuing to release new versions to end-users.
Use Case: Snapchat Experienced a Rare Need for a Full Rewrite
But does a full rewrite ever work? In Snapchat’s well-named article, “Don't Rewrite Your App, Unless You Have To”, they detailed the strategy they used for the challenging scenario of rewriting their application.
The Snapchat Engineering team launched a new version of the Android app a little over a year ago, rewriting it from scratch to improve performance and reduce bugs. The main motivation for the rewrite was to improve app performance as the app had grown in complexity and the features were tightly coupled, hurting flexibility.
In the past, they had tried streamlining the existing codebase but progress was slow and caused unintended side effects They believed a rewrite would be faster and less risky than an incremental refactor since their existing app was complex and interconnected, and issues introduced by the rewrite would be easier to find and fix.
They thoroughly researched app performance before starting and used coordination and support to keep the project on track. Additionally, they adopted strategies such as having ground rules, focusing on a specific scope, and adopting an MVP strategy to address the challenges.
The team at Snapchat tested their rewritten app on new users, gathering feedback and adjusting their plan as needed. In the end, they found that their new app was more performant, and their work helped establish better engineering practices.
Snapchat ended the article by saying that they “take the incremental approach for their initiatives whenever possible, but [in this specific instance] a rewrite was the best solution.”
Use Case: Netscape Navigator Dug Their Own Grave By Rewriting
At its peak, Netscape Navigator held a 90% market share in the Internet browser market. However, due to technical debt and other reasons, it eventually lost its position on Internet Explorer.
In an attempt to regain its market share, Netscape attempted to introduce new features that Internet Explorer offered, but the codebase was too complex and difficult to work with. As a result, Netscape decided to rewrite the browser from scratch.
However, this decision ended up backfiring as the focus on the new version meant that the old version did not receive enough attention and improvements. The rewrite took too long, causing users to switch to Internet Explorer while they waited.
When the new version of Netscape Navigator was finally released, it was plagued with bugs and lacked performance, further diminishing its market share.
When it comes to Netscape Navigator, Joel Spolsky, the former CEO of Stack Overflow sums it up well: “The single worst strategic mistake that any software company can make is deciding to rewrite the code from scratch.”
Our Expert’s Opinion: Complete Rewriting From Scratch
To conclude this section on rewriting from scratch, it’s clear that when even major tech players – like Netscape – with huge budgets and enormous teams that may fail, it is a telling sign that full rewrites are something any company should avoid doing. If you do feel a complete rewrite from scratch is the best decision, we recommend you have a code audit first and create a compelling argument why it will be best for your company to rewrite from scratch.
Do keep in mind that a full rewrite doesn't need to replace your old system, instead, it can be 'in addition to' your legacy system. One of our ticketing clients created a completely new application that would work in parallel to their old system, without depending on their legacy system.
Their new application is a more simple version of their legacy ticketing platform, but users do not need to choose one of the other. Rather, they are allowing their users to decide whether they’d like to migrate to the new simpler version or stay with the old system.
In this way, our client opted for a full code rewrite without replacing their legacy system, meaning their data will remain untouched and their users won’t react negatively to a change in systems.
Similarly, a fintech client of ours created a new 2.0 system that would eventually replace their 1.0 system. While building a new system from scratch is costly, the client felt it was worth it and had the resources to do so.
Since they didn’t want downtime for their users, the client kept version 1.0 maintained and functioning until version 2.0 was completely ready. This client was able to build a new system from scratch without disturbing their users during the building process, however, they will still need to migrate data from their 1.0 version to 2.0 and onboard users.
The most challenging aspect of rewriting while maintaining the old system in parallel is the high resource costs. Fortunately, Softjourn helped to extend the client’s in-house teams so they’d have the support to maintain version 1.0 while building version 2.0.
If you are curious about a complete rewrite from scratch, contact us if you’d like to see which approach would work best for your company.
A Complete Progressive Rewrite
We define progressive rewrites, also known as incremental rewrites, as a complete rewrite because eventually, the system will be completely changed. However, the big difference from the ‘from scratch’ rewrite approach is that rewriting is spread over time and consists of a set of isolated partial rewrites.
The progressive rewrite approach works perfectly for those who’ve decided to move to a more convenient, up-to-date environment while keeping the business logic of the previous system, so employees don’t need to adapt to new software.
Why Consider a Progressive Rewrite?
The nice part about this approach is that each small rewrite can be completed faster, delivered to production, and tested. This approach will introduce fewer potential problems compared to a full rewrite from scratch.
Progressive rewrites tend to be more agile than other approaches because they involve breaking down a large, complex project into smaller, manageable chunks. This allows for a more flexible and adaptive approach to the development process, rather than trying to tackle the entire project all at once. Other benefits of a progressive rewrite are that:
- It causes little disturbance to the end-users.
- It works well for large and frequently updated applications.
- It allows developers to test each component.
- It reduces the risk of human error.
When to Consider a Progressive Rewrite?
Progressive rewrites involve making incremental changes and improvements to an existing codebase over time, with the goal of eventually completely modernizing the entire system. This approach is well suited for systems that have fundamental limitations or issues that can only be addressed by a complete rewrite. Additionally, these are specific instances where we would potentially recommend progressive rewriting:
- A change of the base technology: If the legacy code is written in an obsolete language or unsupported tech stack, there may be a reason to conduct a complete rewrite progressively.
- A change of scope: If the majority of code is no longer needed due to changes in requirements, or if you are implementing a lot of new features, it might make the most sense to progressively rewrite and clean up the code.
- Your business goals have changed: If your plans have greatly shifted and your legacy application components do not meet your current needs, you will likely be progressively rewriting your system.
- When a legacy system doesn’t perform its tasks well: A new environment may better correspond to the changed requirements - these are rewrites you can make progressively.
Use Case: Progressive Migration Worked Like a Charm for Shifting from AngularJS to React
The popular framework, AngularJS, announced that it would no longer be supported by the end of 2021. When it was introduced ten years ago, the framework was adopted by numerous companies – including our client – as a target web framework for new web apps. Now, these companies must pivot to a new tech stack.
Our client is a big name in the expense management industry and constantly strives to offer its customers a chance to save time and money by automating corporate expenses. The client wanted to migrate from AngularJS to React, and sought the help of our experts to ensure the migration would go smoothly.
Our team recommended the client go with progressive migration as this would ensure the client’s system would be able to continue normally issuing cards and managing transactions during the migration. Progressive migration would also allow our client to keep the exceptional performance of their application for their thousands of users during the process.
Softjourn’s developers did due diligence to ensure that the parts of the application still in Angular wouldn’t cause any unanticipated problems. Since the client did not have a detailed migration process, our experts developed the process to migrate the code to React faster and more efficiently.
Both during and after the migration process, our client noticed that their pages were loading much faster, bugs were removed, and their platform was much more efficient overall than it was prior to the migration. Plus, updating the application and creating new features in the future will be much easier due to the flexibility of React framework.
Our Expert’s Opinion: Progressive Rewriting
Our experts consider progressive rewriting to be a better approach than a complete rewrite from scratch in nearly all cases. In particular, progressive rewriting benefits companies in several ways:
Reduced Risk: Progressive rewriting reduces the risk of the project as it allows developers to make gradual changes and improvements to the existing codebase, instead of starting anew, which can lead to unforeseen challenges and delays.
Better Quality: Progressive rewriting allows developers to continuously test and refine new changes and improvements, ensuring a higher quality end product.
More Agile: By working on smaller, incremental updates, teams can quickly test and implement changes, and gather feedback from users and stakeholders. This allows for a more iterative and agile development process, where teams can make adjustments and improvements as they go, rather than waiting until the end of the project to make changes
Faster Delivery: Progressive rewriting enables faster delivery of new features and improvements as the existing codebase can be used as a foundation, reducing the time required to build the entire system from scratch.
Improved User Experience: Progressive rewriting allows for a seamless transition for end-users, minimizing disruptions to their experience as changes are made incrementally over time.
Ability to Prioritize: Progressive rewrites also allow teams to prioritize and focus on the most important or critical features and components first and then move on to less critical features as the project progresses. This allows teams to deliver value to users and stakeholders more quickly, rather than waiting for the entire project to be completed.
Overall, we recommend progressive rewriting over rewrites from scratch because it balances the benefits of a complete rewrite with the practical considerations of cost, time, and risk, making it a more efficient and effective approach for many organizations. If you are considering progressive rewriting, we advise you to plan ahead and make sure you have the right resources and knowledge to ensure it’ll be successful.
2. Partial Modernization
When modernizing a legacy system, one approach is to isolate a specific feature, component, or service that is causing issues and then either rewrite or refactor it. Partial modernization is a term that covers the various methods of updating or improving specific parts of a software system, including partial rewrites, refactoring, and re-architecting.
Why Consider Partial Modernization?
In most cases, organizations and businesses opt for partial modernization over a complete rebuild or replacement of their legacy system, as compared to complete rewrites, since it is considered to be a less risky, challenging, costly, and time-consuming approach.
When the required changes are not significant, partial modernization is the preferred choice. Here are some reasons why organizations might choose to undertake a partial modernization of their legacy systems:
- The legacy systems perform tasks well, yet certain aspects require improvements.
- New features require external integrations using newer technologies, and the existing solution limitations don't allow it.
- When the systems’ security has become vulnerable.
- Software solutions are not able to handle or scale for the growing amount of work.
The Types of Partial Modernization:
1. Partial Rewriting
A partial rewrite refers to the process of rewriting or updating specific portions or components of the software application, rather than rewriting the entire application from scratch. This approach is often used when certain parts of the codebase are causing issues or are in need of significant updates, but the rest of the application is still functional and does not need to be completely rewritten.
A partial rewrite allows organizations to address specific problems in their software while preserving the existing functionality and minimizing the risk, cost, and time associated with a full rewrite.
2. Refactoring
What is refactoring and how is refactoring different from rewriting the code? Refactoring refers to the process of making small changes and improvements to specific portions or components of a software application, rather than changing the entire codebase through rewriting.
This approach is often used when certain parts of the codebase are causing issues, are difficult to maintain, or are in need of updates, but the rest of the application is still functional and does not need to be completely refactored.
Why is refactoring your code important? The goal of a refactor is to improve the internal structure of the code without changing its external behavior, making it more maintainable, readable, and efficient. It is like making repairs to a house, rather than moving to a new one: the changes improve maintenance efficiency without significant modifications.
This solution is great for organizations that are generally satisfied with their legacy software but have some issues with software maintenance or onboarding new developers.
3. Rearchitecting
Rearchitecting refers to the process of redesigning the overall structural organization of a software system to improve its quality attributes overall (e.g. performance, scalability, maintainability, security). It may involve changes to the system's architecture, infrastructure, technology stack, and design patterns.
Unlike a simple refactor, a rearchitect project is typically a more significant undertaking that involves changes to the system's fundamental design. It is usually done when the existing architecture is no longer able to support the changing needs of the business or when the system needs to be adapted to new technologies.
Rearchitecting can be complex and time-consuming and requires a deep understanding of the system's requirements, goals, and constraints.
4. Lift and Shift
What is lift and shift? An aspect of re-architecting, lift-and-shift (also known as legacy software rehosting), is the process of transferring a legacy software application to a cloud platform without making significant changes to the code.
This approach addresses the issue of high maintenance costs by migrating the system from its original hardware to modern hosting solutions - for example from on-premise storage to the cloud.
Lift and shift allows companies to keep their legacy system running while avoiding the complexity and cost of a complete re-architecture or re-write.
Lift and shift migration is one of the most common modernization practices we help clients with at Softjourn - in particular, moving our clients’ applications to the cloud.
Partial Modernization: Where to Start?
Refactoring, re-architecting, and rewriting are all different methods for modernizing legacy applications, and they are not mutually exclusive. They can be seen as points along a continuum in the process of improving an application.
It is often recommended to start with an audit and identify what is actually needed for the particular modernization project. This will help you figure out what parts of the application to prioritize modernization efforts, without jumping into something too big to handle.
For example, if the application requires new functionality or performance levels that cannot be achieved with its current structure, rearchitecting may be needed. However, if the complexity or risk of re-architecting is too high, a complete rewrite of the app may be the best option.
Regardless of the chosen approach, it is important to begin with code refactoring as it improves the codebase's understandability and maintainability. Furthermore, refactoring code can reveal hidden dependencies and business process workflows that may be missed if a development team goes straight to re-architecting or rewriting.
It is important to note that all of these options require a significant investment of time and expertise, particularly when using manual processes and tools that were not specifically designed for application modernization.
Use Case: A Code Review & Partial Rewrite Reaped Enormous Benefits for Superstar
Our ticketing client, Superstar, initially requested that our team assist them in adding some internal features and adjustments to their commission portal. However, after a brief code review, we recommended making some improvements to their code before adding new features.
The results of our code review showed that while there was no need for Superstar to rewrite their code from scratch, there was a need for them to modernize their framework.
We also recommended that they reorganize and restructure their source code before making changes and adding functionality to their current platform – doing this would save them time, money, and effort in maintaining their system in the long run.
The code review and the partial rewriting that Softjourn helped with gave Superstar the confidence to add new features without worrying about the unintended consequences they might have for other parts of their application. A modern framework will help Superstar continue to improve and scale up its product while adding innovative features going forward.
Expert Recommendation: The Best Application Modernization Practices for Your Business
Whether partial modernization is right for your business depends greatly on the specific needs and goals of the project. In general, we do recommend this approach as a way to improve the performance, functionality, and security of an application, without completely rewriting the entire system.
A partial modernization may be a quicker and less expensive solution for resolving specific problems, but may not address underlying issues with the codebase. We often suggest partial modernization for systems that have functional parts that can be improved or upgraded without affecting the overall system.
Compared to a complete or progressive rewrite, partial modernization may be less of a comprehensive solution but can be done quicker and require significantly fewer resources.
We’ve helped many of our clients analyze their systems and figure out how to boost their performance and functionality, without downtime for their users.
We strongly recommend against rewriting fully from scratch as it is not the most efficient or cost-effective approach. Instead, we advise most of our clients to perform either progressive rewriting or refactoring in stages, depending on the needs of the project. These methods allow for a more focused, efficient, and cost-effective approach, and also allow for easier testing and quality assurance.
Both partial modernization and progressive rewrites have their advantages and disadvantages, and the best approach will depend on the specific needs and goals of the project.
If you are still uncertain about the best approach, please reach out to us and we will be happy to assist you in making a decision that best suits your organization's needs.
Get Started on Modernizing Your Legacy Application
Proper preparation is key in any major project, and modernizing your legacy software is no exception. Before embarking on this journey, it is important to consider the current state of your industry and how it has evolved over the past decade. Reflect on how these changes have impacted your business and whether there are any new developments or disruptive startups that are reshaping your industry.
Understanding your current position and the gap between it and your goal of having a modern system that is a driving force for your business will help inform your decision-making process. Not sure if it’s time to modernize your legacy systems? Check out our handy guide.
At Softjourn, we provide comprehensive support throughout the entire modernization process, including the discovery phase, code audit, and implementation. Our team is highly experienced and proficient in various technologies, ensuring that we can provide expert guidance and support for your project.
Before initiating any updates to legacy software, our team conducts a thorough discovery phase of the current and required technology stack, performance, and business processes of the project. Each situation is unique and requires a personalized approach. Determining the most appropriate type of modernization for your legacy software can be difficult, which is why gaining knowledge about the different options available is essential.
Ready to take the next step towards modernizing your legacy application? Don’t hesitate to contact us to get started!
