Let’s first start with some definitions.
If we take a glimpse at Wikipedia, we will end up at the term “Software Modernization”
“Legacy modernization, also known as software modernization or platform modernization, refers to the conversion, rewriting, or porting of a legacy system to modern computer programming languages, architectures (e.g. microservices), software libraries, protocols, or hardware platforms. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms to benefit from the advantage of the new technologies.” (source: Software modernization - Wikipedia)
Okay... That’s a broad definition. If we look at what others have to say about this we’ll quickly notice that the consensus on App Modernization is to revamp your solution using more modern programming languages, platforms, and software architectures.
“Application modernization is the process of taking existing legacy applications and modernizing their platform infrastructure, internal architecture, and/or features” (source: Application Modernization: An Essential Guide | IBM)
And then we have TechBeacon with a more to the point definition:
“Application modernization is the process of taking old applications and the platforms they run on and making them "new" again by replacing or updating each with modern features and capabilities that better align with current business needs.” (source: App modernization 101: Understand your options—and how to get started | TechBeacon).
There are some caveats here. I mean, what is legacy? If we look at the above definitions there is a huge assumption that the solution in question is “old” and didn’t receive much TLC. Even though there are solutions out there that have been neglected for far too long, that is not usually the case. Surely you have been developing your solution and adding value for your customers in the past years. If you didn’t, how relevant are you still? Yes, some solutions cause an enormous vendor lock-in and nobody is worried that customers will leave because of well.. the lock-in. But, compared to all the software that’s out there, that’s a niche market.
It’s safe to assume you have been doing some modernization up until now.
When do you need to Modernize your solution?
So, when do you need to modernize? Well, let’s first agree that adding value to your solution throughout the years is not exactly modernizing. I would state that the time to modernize is when you are being limited by the technology stack, software architecture, or platform you are using. Let’s do this by example.
Learn more about what Intercept can do for you regarding Application Modernization
The use case
You have a solution that runs on a Windows Server. Every 3 months you release a new version of your solution, package it in an installer, and ship it to the customers. They can then install the new version and voila.
This has been going well for many years but you have some internal and external requirements. You have expanded your business and are now servicing customers globally. Additionally, you want to provide more features more frequently and not support a whole lot of different versions anymore. At this point, you are somewhat bound to what version your customer installs and if they regularly run the updates. There’s also the risk of customers having a negative experience because of performance issues on a platform and infrastructure you can’t control. The success of your solution heavily depends on the IT teams on site.
The solution
Right... So let’s pull this apart. You have some requirements:
- Service customers globally
- Not depend on local IT teams for installation and systems administration
- Ship new features more often
Let’s look at a couple of solutions.
We can lift and shift every Virtual Machine to the Public Cloud (Azure of course 😊). This would result in a couple of machines per customer but you would be in charge of the infrastructure. This eliminates the dependency of the customers’ IT Teams. Throw some Azure Virtual Desktop in there and you can even “Saasify” your Client/Server application.
This would be a great first step but you will have a lot of overhead. However, if we look at the definitions stated before then we’re modernizing the platform here. We’re going from an on-premise solution to a cloud-hosted solution with much more capabilities.
So… that is one way to do it, but we’re not ticking all the boxes. Even though we can deploy virtual machines all over the world, we never implemented something to ship new features more often and we’ve got a lot of overhead.
Other options
There are other options... Not just a few... A lot. What if we were to modernize the platform and get rid of those virtual machines? We could go for App Services or containerize the solution. What if we’re currently running a website on IIS and running MSSQL as a database? Maybe we can refactor that code a little bit and use the Platform As A Service offerings that Microsoft Azure provides.
We can still go for that single-tenant scenario and give each customer its app service. But it’s a lot easier to update App Services from a pipeline as opposed to virtual machines.
Once you’ve modernized the platform you can start enjoying even more benefits of that Public Cloud. This is when we can truly start modernizing to epic proportions.
Wherewith traditional infrastructure your ideas were perhaps a bit futuristic and you couldn’t implement all that your customer desire because the platform was the limiting factor, now you can.
Once you modernized the platform and you want to use all those awesome new features you will quickly learn that your software architecture might be your new limiting factor. And that’s the time you will start focusing on doing a lot of development. There are cases where companies decide to start from scratch and rebuild everything to a cloud-native platform, skipping all the intermediate steps. But, there is a big risk involved here. You will allocate a lot of development capacity that can’t be spending on the current solution and platform which might even result in less value-added for the time being. If you have the financial capabilities and the time, it is an interesting path to take but I don’t see it happen often.
To answer the question: When do you need to modernize your solution?
Well... Before anything platform, software architecture, or technology stack becomes a limiting factor and you can no longer provide that what your customers ask. You don’t need to create multi-year roadmaps but you do need to understand your solution, your market, and your customers.
Learn more about what Intercept can do for you regarding Application Modernization