“Big Bang”
Rollout a complete replacement system in one go.
Reading time
9 minutes
Published
16.05.2022
A Definitive Guide to Application Modernization
Legacy applications continue running mission critical business tasks. But when they imminently come to the end
of their lifecycle, you need to choose the right option for cost-efficient modernization.
What is Application Modernization
In simple terms, software modernization, or legacy modernization, or legacy application modernization is the
process of replacing or upgrading older software. Modernization options vary from light touches to a
complete replacement, depending on an application in question and company situation. This is similar to
upgrading an airplane – sometimes you can refit it with new avionics, engines or saloon, but sometimes you
just need a new one.
Reasons for Modernizing Legacy Applications
The main drivers for legacy applications modernization fall into two categories: eliminating the risks and
costs associated with supporting old technologies and taking advantage of the new ones.
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:
It cannot be supported. Examples: a vendor goes out of business, there is no staff with required
expertise.
It cannot be upgraded to meet new system or business requirements. Examples: a desktop application that
cannot provide users access via browser, an application has a hardcoded business process which does not
fit business requirements anymore.
Or transitively, it can only work with obsolete software or hardware. Example: a mobile application that
requires Symbian OS or a website that requires Flash player.
Here “cannot” also means “can, but at an unacceptable cost”.
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.
Modernization Strategies
An optimal application modernization strategy depends on the answers to the questions below:
- 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.
01
Postpone and Do Nothing
It is the basic and the easiest one. This can be the right choice when business benefits do not justify the
modernization costs or risks. Or, when resources have been allocated to higher priority tasks. Or, when
modernization is not possible until other applications we depend on are modernized.
02
Re-hosting or lift and shift
Here, we simply move the application to a new infrastructure, usually by means of containerization and
hosting on a local Kubernetes instance or a public cloud. This is a relatively simple and cheap option. As a
result, the company can reduce maintenance costs, improve hardware utilization, scalability, monitoring, and
cut down recovery time.
03
Re-plaforming
This is an advanced variant of re-hosting. For instance, minor changes to the application source code can
help utilize cloud resources like database, authentication, or full text search services.
04
Application Front-end Modernization
Another popular option is exposing API and modernizing application front-end. Again, with relatively small
changes it is usually possible to expose application API via, for example, REST services. This enables other
applications to communicate with the legacy one. Also, we can build a modern web or mobile interface around
this API, eliminating one of the most common pain points of legacy applications. Of course, this can be
combined with re-hosting/re-platforming.
05
Refactoring
Often applications were not built for the scale they are facing now, or become too complex as a result of
their evolution. In this case, refactoring, or re-architecting may come to rescue. The most popular pattern
is splitting monolithic applications into microservices. Other options are optimizing the most
heavily-loaded business logic, implementing caching, cluster support, moving some data to a NoSQL database,
and so on. The main principle is that the functionality of the application remains the same during the
process.
06
Complete rewrite
The ultimate option is “rip and replace”, or a complete rewrite. In this case, the application is replaced
with a new one. This might be the best or the only option in scenarios, when:
The functionality of the application does not suit business needs and cannot be amended with light touches
We do not control or do not have resources or skills to modify the source code of the application
There is a newer, better and well supported product available on the market
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?
Jmix is an open-source application development platform that can dramatically cut costs
and time of
modernization in the “complete rewrite” scenario. It is highly productive, developer-friendly and does not
imply any license fees on your applications. We have seen many examples of teams and applications
successfully migrated from Delphi, MS Lightswitch, FoxPro, Oracle Forms. Jmix applications can work on top
of a legacy database, which might be a good option for “parallel running”.
A natural fit
Modernize enterprise applications with convenient data centric development approach and enterprise-grade
UI components.
Future proof
Build on top of mainstream open-source technologies trusted by millions of developers.
Easy to onboard
Use Java or Kotlin as a single language. Simplify engaging legacy teams with visual tooling.
Productive
Develop even large applications relying on extensive data model and business logic in record time.
Cloud-enabled
Deploy your applications to any cloud or host them on-premise. Don’t get hooked on vendor infrastructure.
Cost-efficient
Run the applications built with Jmix free of any usage or distribution fees.
Jmix is developed and maintained by Haulmont – an ISO-certified software development house with 500+
staff. You can be sure you will get all the support you require on your journey: from training and
consulting to custom development.
Discuss your application modernization requirements with an expert
Frequently Asked Questions
Application modernization is the process of upgrading or replacing software which doesn’t meet the business
requirements.
There might be several reasons:
- 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.
- Re-hosting.
- Re-platforming.
- Replace customer-facing frontend.
- Refactoring
- Completely rewrite.
Modernization Stories by Our Customers
Gradual Replacement
Replace complex or mission-critical systems gradually to minimize disruption risks.
Extending capabilities.
A comprehensive task management environment for a global leader in secure electronic transactions
systems.
