A Definitive Guide to Application Modernization
What is Application Modernization
Reasons for Modernizing Legacy Applications
Old Technologies Risks
When it comes to old technologies, developers fairly say: “if it works don't touch it”. For instance, many enterprises still rely on COBOL applications, built decades ago. They work fast and they are remarkably stable. But what if you need to change or troubleshoot something? Hiring a COBOL developer is a challenge. The folks who wrote these legacy applications are probably retired now, and young developers just don’t want to learn it. Even if you are lucky to find one, (s)he will have to spend weeks or months trying to understand the code before making the actual change.
Quite often, you might be using a 3rd party software, which becomes unsupported. Then you are stuck completely and can only pray it keeps on working and no critical vulnerabilities are discovered until you manage to replace it.
Adopting new technologies
Meanwhile, new technologies and architectural patterns are emerging at an incredible pace. Web and mobile interfaces offer great user experience. Containerization abstracts applications from the hardware they run on, so that they can be easily deployed anywhere and behave exactly the same. Microservices architecture improves scalability and resilience. It also breaks down the complexity of huge monolithic applications, facilitating easier support and faster modifications. DevOps tools enable shipping new versions of applications in minimal time, eliminating human factor. Public clouds provide ready-to-use services, endless scalability and the highest levels of failover with minimal maintenance efforts.
Finally, modern development languages are much more expressive and less error-prone. Their ecosystems include 1000s of proven libraries and powerful developer tools with code completion, debugging, refactoring, smart hints and error corrections. All of that boosts developer productivity, helping to build advanced software faster.
The ability to adapt becomes critical to survival in today’s super-dynamic digital world. But enterprises running legacy software simply cannot keep up the pace with competition. They spend too much on support, wait too long for the changes they need and cannot deliver the features their customers want.
As Bill Gates once stated:"The only big companies that succeed will be those that obsolete their own products before someone else does."
When Does an Application Become Legacy?
We see new shiny frameworks and technologies originating every year. Does it immediately make all business applications obsolete? Of course, not! “Obsolete” is a relative term which can only be considered in a certain context.
In the enterprise world, 10-20 years is a normal life span of an application. During this period, it is actively supported internally or by a vendor and can evolve according to the business needs. Some standalone back-office tasks can be run by even older software without a noticeable impact on business agility. On the other side, a customer facing portal might require a complete system modernization every few years to stay competitive.
We can define software as obsolete if any of the following is true:
Modernization or Digital Transformation?
This is a strategic question you must answer before embarking on the modernization voyage. Digital transformation implies that you not just modernize your IT landscape, but actually change your business processes to embrace new digital opportunities.
Let’s consider a hypothetic example. You run a traditional retail bank, backed by COBOL software on mainframes. If you believe the time for change has come, you may plan for modernizing your software and hardware. Usually, this is a demanding, long, and expensive endeavor. At the same time, fintech startups will still be ahead of you. They have zero legacy and can deliver features without painful analysis of dependencies between hundreds of systems in production use.
Alternatively, you can leave everything as is and start a new fintech business in a green field. This way you can use top notch technologies and practices with hands untied – e.g., no physical offices, mobile superapp, AI-driven scoring and so on. After a while, you can stop the old business and migrate customers to the new platform – data migration is easier compared to enterprise applications modernization. This customer base combined with your banking experience and top-notch tech can be a powerful mix. I hope this oversimplified example is illustrative enough to highlight the fundamental differences between the approaches.
- What result do we want to achieve?
- What resources do we have?
- Do we control the application source code, can we modify it?
- Do other applications depend on the one in question or vice versa?
- How critical is the application downtime? Does it have to run 24/7?
Below we will start from the easiest and cheapest to the hardest and most expensive modernization option.
Postpone and Do Nothing
Re-hosting or lift and shift
Application Front-end Modernization
Unless we replace with a ready solution with good migration tools, “rip and replace” is almost never easy. So, there are a number of approaches:
“Big bang” assumes that we build a new application, thoroughly test it, work out data migration strategy, pray, and replace the old one in one go. Ideally, we should have a rollback strategy if things go wrong. Big bang works when the target application is not overly complex and we can afford some downtime.
This will hardly work for large scale mission-critical systems like ERPs, especially the ones running 24/7 like in the taxi business. One option here is splitting a monolith app into microservices first. Each microservice is simpler and can be replaced easier, so we can go one by one. Another strategy is “parallel running”, when data between the old and the new system is synchronized. In case a new module fails, we can fall back to the old one.
How to Start Modernization?
In real life, companies have different levels of ambition and risk appetite, as well as constraints like budget, time, resources, and dependencies between applications. The best starting point is the assessment of existing applications to identify the legacy ones and possible modernization options. For each option, you can then estimate the effect versus costs and risks – effectively, ROI.
It is important to stay reasonable with modernization requirements. For instance, scalability is often overrated, leading to unnecessary costs and suboptimal strategies. Knowing ROI and dependencies you can prioritize the candidates and choose the best modernization solution.
How Jmix can help?
A natural fit
Easy to onboard
Frequently Asked Questions
- Lack of specialists or providers to support a legacy technology.
- Unsupported 3rd party dependencies.
- Lack of new features required for business development.
- You can’t get support for the solution.
- You can’t meet business requirements at an acceptable cost.
- A solution relies on another legacy system.
- Accept risks and do nothing.
- Replace customer-facing frontend.
- Completely rewrite.