In Part One of our series on Application Modernization, we explored 3 common red flags that signal it’s time for legacy software modernization. Now that you know you need to modernize, let’s explore your options.
Oftentimes, clients come to us for help with their legacy applications because they need the app to do something that it can’t in its current state. They want to add new features and functionality in an attempt to modernize. But, that’s when the cracks in the solution start to show.
Rebuilding, amending or extending parts of the existing application may not always be possible. In this case, the best option might be to find a suitable off-the-shelf package to replace it, if one exists, or to rewrite the application from the ground up to get exactly what you require. Let’s dive into what goes in to making that decision.
Legacy Application Rebuild/Replace Discussions
It can be a tough pill to swallow: An application you’ve spent years of time and money developing is just not meeting your needs anymore and you’re facing the prospect of rebuilding or replacing it.
How do you know whether you’re looking at a rebuild or replacement? Like in many business situations, the answer is: It Depends.
There are no hard and fast answers to this question since the best solution for each application will be different. Your first instinct may be to rebuild what you already have. That option is more likely to be the best solution if these three factors are present:
- Architecture is solid
- Database design is well constructed
- Programming languages are up to date
In the absence of these three requirements, your next step might be to look for an off-the-shelf software solution and go down the SaaS route. But if there isn’t one that meets all your needs, the smartest and most cost-effective option becomes a complete rewrite of your legacy software.
Quality Architecture is Key
In application modernization, age is a big factor but how well the solution was originally architected and developed may be more important. You can have a 5-year old application with a solid architecture that we can rebuild or extend. You can also have a year-old application that might have a great front-end design but architecture, business layer or database development is flawed. Sadly, we see this often with clients who tried to save money by outsourcing their application development offshore. In this case you need a complete rewrite because you should never rebuild a house on an unstable foundation.
To use a car analogy, once we “look under the hood” at legacy applications, we will have a better idea of what we can do and whether we need to have the tough application rewrite discussion.
The High Cost of Maintenance
There might be business owners who think rewriting is just a developer’s way to boost budgets. But there comes a time in every software application lifecycle where it costs more to maintain than to replace it.
Continuing with the car analogy, if you’ve ever driven a car for 10 years or more there comes a point when you realize it’s costing you more money to keep the car running than it may be worth. Even though you’ve always looked after your car and maintained it in accordance with the manufacturer’s guidelines, things just start to break down because of wear and tear and age regardless of how many parts you’ve replaced. You end up throwing more and more money at the car to keep it running. But is that the best decision? You might save money in the long run by buying a new car.
When it comes to software, you can patch, extend, bolt on elements to get the features and functionality you want, but it will cost you time, money and eventually performance will suffer. Over time, the application will become slower, less stable and harder to extend.
Even if technically rebuilding is possible, it may be a better choice to rewrite your legacy software. It often boils down to deciding to pay now or pay later.
End of Life Issues
With the pace of change in technology, issues around end of life (EOL) are always a concern.
When evaluating rebuild or replacement options, it’s also important to look at all the underlying technology for potential obsolescence. For example, anyone with applications using .Net Full Framework needs to know that the 4.8 release will be the last major release. Those using .Net Core should also pay attention because .Net 5.X, scheduled for release in the fall of 2020, will be the only active .Net architecture. If you’re using any other version, EOL is nearing and you need to start planning your application modernization approach to avoid major issues, like the ones we discussed in our Windows Server 2008 EOL post.
Look to the Future
Whether you need a simple extension of existing functionality, or your application needs to be replaced for a new solution, you need to plan with the future in mind so the solution you design today can scale as needed.
We recommend our clients take a 5-year view of their business and the application before embarking on any software development project. You can’t entirely future-proof applications because technology is changing so rapidly, but you should consider what’s ahead (even if you don’t have the budget for all the future enhancements today).
Need help with deciding which application modernization approach is best for you? We’ll work with you to assess your current software solutions and see if rebuilding, rewriting or going with a SaaS product meets your business needs. Let’s chat.
