When you work in the tech industry long enough, you often find hidden secrets that people don't like to talk about. No one wants to admit they are running applications that are critical to their business on old legacy systems. This could be anything from geriatric hardware infrastructure to archaic software that hasn't been patched in the last decade.
Many still run their core business on Windows Server 2003 and or Windows Server 2008, which are 'end of life' when it comes to support and security patches. Not to mention, the quality of software that is running on top of those machines, and keeping the websites chugging along, is ancient and pose major security risks. Luckily internet browser vendors have caught on and stopped supporting older versions of TLS and will flag websites when they are not secure.
Check out our previous article Simple Ways to Secure Legacy Web Servers and Applications.
Ok, Justin, we get it, there are old servers still running today, but whatever are we to do about it?
Just upgrade, easy enough...right?
Well, yes, but it isn't always that easy. Most old legacy systems, who's original developers are long gone, are poorly understood and difficult to maintain.
Let's go over a few strategies you can use to modernize your legacy system and things you should consider before making any moves.
Lift and Shift
As the name suggests, with 'Lift and Shift', you essentially pick up the old system, its applications, and shove it on a new cloud server.
Sounds easy enough, right?
Not so fast. You can't just take any old server and shift it to the cloud. If you are running on legacy hardware then you simply can't spin up instances of those older versions. Azure, AWS and GCP only allow you to spin up the last few versions of any operating system.
If you are using third-party products or server side frameworks like PHP, ColdFusion, Java, Ruby on Rails, etc. you'll likely end up having no choice but to install newer versions of these software pieces on your cloud server.
While this isn't necessarily a deal breaker, it can present all sorts of issues.
What if a feature was deprecated in the newer version of the software that your application uses?
What if the database software you were using is so old it has to be upgraded just to even install it?
These are just a couple of scenarios you need to thoroughly test for. So while the 'Lift and Shift' approach is usually the safest and cheapest option. It isn't without downsides.
Reasons to 'Lift and Shift'
- It's the lowest price – in terms of money, time and effort
- Existing system isn't being actively developed and development changes are rare
- You only care about the underlying server being up to date
- Cost of maintaining it is low
Potential downsides
- You are running on a new server but the same underlying software
- Missing out on easier ways to solve the same problems
- Harder to optimize without software modifications
- The software could still contain security holes and/or bugs
Completely Rewrite Software
Some call it the single worst strategic mistake that any software company can make, but sometimes your only choice is to completely rewrite your legacy code from scratch.
Many times it's for security reasons. If you are running on insecure hardware or software then maybe its time to bulldoze it down and start fresh.
If the framework chosen by the original developers is now deprecated and you can't find anyone left who wants to touch it, it might be time to dump it.
Any time you rewrite something, not matter how simple, it always ends up taking longer than you anticipate. Unless you have great design documents still hanging around, the domain knowledge that went into building it the first time is never magically available. So you end up digging into unfamiliar code and having to decipher why someone had so many weird edge-cases built into their design.
You can implement cloud or no-code/low-code platforms, but be cautious and ask yourself, is the end-product going to be better because of it. If you aren't rewriting to improve the speed at which you release features or to improve the product, then the 'Lift and Shift' approach might be more ideal.
Reasons to do a complete rewrite
- Framework or language has been deprecated.
- Can't find willing developers to work on the software.
- So complex, no one can or wants to figure out how it works.
- Cost of maintaining the existing application is too high.
Potential downsides
- Cost. You have to weigh the cost of a rewrite vs cost to maintain the existing application.
- Time, it always takes longer than you think.
- If you aren't improving the product, then why rewrite it?
Refactor Approach
If you can't afford a complete rewrite or don't have the time and programmers willing to tackle such a task, refactoring will allow you to slowly replace bits and pieces of software over time.
Let's say you decide that new feature development will be done starting with a new project or using a microservices type architecture. In this way, you migrate the application slowly over time. This can work well in many situations.
Another method might be splitting your legacy application into separate pieces. For example, if you store customer information in your legacy application and also store it in your accounting, or CRM software, try picking a single source of truth and integrate your other applications with that one single source. This prevents you from having to store duplicate data all over the place and worry about synchronization issues.
Moving pieces of your legacy application to different SaaS/PaaS products can allow for easy integration across providers. This will save time since you aren't having to rebuild everything from scratch.
Reasons to use the refactoring approach
- Project is just too big to tackle all at once.
- Cost of a complete rewrite is too high.
- You can slowly build out your perfect solution.
- You can fix the processes that need improving.
Potential downsides
- Could take years to get to where you want to be.
- Your application can become more complex.
- Refactoring any application takes skill.
Re-platform on the Cloud
To re-platform means to take the custom software solution or legacy on-premise software and move it to the cloud. This will require some rewiring of the integrations and changing the architecture of the application, but it's not as complicated as you might think.
When you re-platform for the cloud, you go through and retool all the old processes and find ways to improve old processes for the better. Business users most often love the end results of this process.
We see this happen regularly in the Enterprise Performance Management space. Before the cloud, most vendors only provided software that you installed on your own infrastructure. So when moving to the cloud, you're required to rebuild, hence re-platform, things to fit into the new SaaS providers software.
A few vendors provide an upgrade 'path' when moving to the cloud, but many older versions of on-premise software do not. Oracle is a classic case where the old on-premise software suite was completely rewritten when they built their new cloud product offerings. There is no easy way to migrate the on-premise instances to the cloud because the architecture is so different.
Oracle customers wanting to modernize are having to re-architect their application in order to successfully upgrade to the cloud. Tevpro specializes in this complex process, and we're always here to help.
Reasons to Re-Platform to the cloud
- No more hardware/software updates to worry about.
- Easier to scale your applications as usage grows.
- Future upgrades should be easier.
- Cost can be cheaper in the long run.
- Easier integration with other SaaS or cloud products.
Potential downsides
- Lack of customization. You have to live within the bounds of the cloud providers products.
- Complicated process that requires specialized resources to complete the migration and integrations.
- May lose functionality users were accustomed to.
Conclusion
There isn't a single right answer when it comes to legacy system modernization. You really have to get everyone to the table to figure out the best strategy to resolve your legacy issues. Sometimes you'll need to convince a steering committee or two of your plans to future proof your legacy system, but hang in there. You're making progress and modernizing any legacy application is big undertaking. If you ever want to bounce an idea off of Tevpro or have questions, feel free to reach us at info@tevpro.com.
Photo by Alex Motoc
Angular • React • Ionic • NestJS • C# • Azure • Next.js