Does my application require modernisation? It is a question that often comes to mind, especially when we have a substantial number of legacy applications running within the organisation. If you have not had the pleasure to think about it so far, do not worry, one day you will.
To solve such problem is not easy, even for those with an extensive technical background. That’s because the answer goes beyond architectural aspects. Knowing when to modernise, which strategy to apply and especially understanding whether the investment is worth it are factors that must be considered.
In this blog, I will explore this issue more deeply by classifying and quantifying the factors to consider when determining whether your application needs refactoring. If so, which strategy is most appropriate? This post is not about recommending a specific framework, but rather focusing on the considerations for choosing the right strategies for a modernisation project. I will also reflect on decisions I made early in my career, and which ones I would change. After all, none of us are born knowing everything, and despite our best efforts, there are always things we wish we’d known earlier.
Look out for the signs
The first step is analysis and identification. There are some signs that can help you determine whether your application requires refactoring. Some are easy to identify, while others are more subtle.
End of support
The end of support (EoS) for software, frameworks, or tools is a key indicator that your application may need modernisation or refactoring.
For example, older database systems like SQL Server 2008 or Sybase may no longer be supported, creating risks for applications dependent on them. Similarly, frameworks like AngularJS require migration to newer versions to ensure long-term viability. Here’s how EoS can affect your application and why it’s important to act proactively:
Security Risks
- Vulnerability: Vendors stop releasing updates, leaving the system exposed to known exploits.
- Compliance violations: Failing to meet industry security standards can result in penalties.
- Increased attack surface: Hackers often target outdated software, knowing that vulnerabilities won’t be patched.
Incompatibility with Modern Ecosystems
- Dependency conflicts: Unsupported software may not work with newer operating systems, frameworks, or libraries.
- Integration issues: The application may struggle to interact with modern APIs or cloud services.
Limited Vendor Support
- No technical assistance: Vendors will no longer provide help with troubleshooting or migration.
- No enhancements: Lack of updates means missing out on new features or improvements that competitors might have.
- Additional cost for extended support: You may need to purchase extended support agreements at an extra cost.
Obsolete Stack
This is another clear sign to look for, as technology evolves, older stacks can become a bottleneck for performance, scalability, and security. Below are key aspects to watch for, along with some examples:
Legacy Frameworks
- Core components (e.g., Sybase, old versions of Java) are no longer supported.
- Outdated architecture: Monolithic designs limit agility, making scaling and updates more complex.
- Incompatibility with modern tools: The system may fail to integrate smoothly with cloud services, CI/CD pipelines, or automation tools. For example, applications using outdated SOAP APIs instead of REST or GraphQL.
Developer Fatigue
- Developers may find the stack outdated and difficult to work with due to the lack of modern tools. This can lead to decreased interest from developers and greater difficulty in finding replacement resources. For instance, consider a team maintaining an application written in COBOL or Perl—languages that are still in use but becoming increasingly rare. Finding skilled professionals to maintain these applications is now more challenging.
High Maintenance Costs
- In some cases, keeping the stack running requires significant manual intervention, workarounds, or reliance on external consultants/vendors. For example, managing an on-premises database versus migrating to AWS RDS.
Bad User Experience (UX)
An outdated UI can be a key reason why your clients are migrating to the competition. Limited functionality or a lack of accessibility are factors that should always be reviewed. Here are some examples:
Outdated UI Design
- Back-end developers may think this is trivial, but don’t underestimate it—an unattractive interface is a big issue. A poor first impression can reduce user engagement with your product. A common example is web applications using outdated CSS styles that aren’t responsive on mobile devices.
Poor Performance
- Applications that load slowly or take too long to process actions frustrate users, impacting both their experience and potential return ($$$). Slow rendering times caused by heavy queries are a major factor and need to be regularly monitored.
Lack of Accessibility
- This is a crucial factor for any web platform. Users with disabilities should be able to navigate the application just as easily as others. A system without accessibility features not only limits your market reach but also exposes you to potential legal compliance risks.
High Operational Costs
Your stack has grown substantially, leading to excessive costs for servers, compute, storage and personnel. Manual intervention is often required, or due to technical debt, you’re spending too much time and money managing outdated systems instead of investing in innovation. Here are some examples that illustrate this:
Limited Automation
- Lack of CI/CD pipelines or automated testing/deployment processes.
- No horizontal scalability: Unable to scale out dynamically to meet growing demand.
Difficulty in Data Handling
- Rigid Data Structures: Struggling to adapt to changing data models or integrate with external APIs.
- Inefficient Data Processing: Performance bottlenecks during ETL or analytics workflows.
High Data Transfer and Storage Costs
- Excessive data transfer charges due to inefficient data flows or redundant operations between systems. For example, storing archived files in S3 Standard instead of S3 Glacier.
The fun part begins
Okay, now that you’ve come to your senses and realised your application needs modernisation, you’re eager to head back to the technical board and define the architecture. Well, sorry to tell you, but there’s much more to it. To assess and define your architectural strategy, you need to go beyond the technical scope, which is just as important as choosing the new stack. Below, I’ve listed some factors to consider and the best strategies to follow:
Requirements and deadline
It sounds obvious (and it is) to mention that the requirements are the first step in defining the architecture, but sometimes there are certain aspects that prevent us from choosing the most efficient strategy, and often, time is the biggest factor.
I bet that at least once in your life, you’ve worked on a project where you’ve thought, “How did the previous engineer create such bad code?” It’s easy to say that after years have passed, but we don’t know what circumstances made the code the way it is. But, if I had to guess, I’d say it was the deadline. A short deadline is a pain and throws all the best strategies out the window.
Strategy: For short deadlines, keep it simple. Then, negotiate a second delivery phase so you can refine the architecture for phase 2.
Another aspect I want to mention is the risk that the requirements are going to change. Sometimes you’re given promises which make you design the new architecture to capture most of its time/performance, and then suddenly all these promises are broken. I remember in the early stages of my career, when I had to design a complex architecture, the objective was to implement more than 40 web transactions. Based on that, I designed the architecture in the most reusable way, with lots of abstraction and reusable components. After some stages in the project and successfully delivering three web transactions, the company cancelled the project due to contract and political reasons. As a result, we ended up with an over-engineered solution for handling just three transactions.
Strategy: Analyse how well-defined your requirements are and take into consideration quick actions to re-adapt to changes.
Don’t believe the hype
Choosing frameworks for modernisation can be an exciting process, giving us the chance to explore new trends and patterns that might meet our specific needs. But be cautious—picking a trending framework is rarely the best choice.
For one, you may not get the same level of support as you would with stable frameworks already on the market. Plus, it’s hard to predict whether that framework will evolve positively with future versions.
Most importantly, even if you confirm the framework is solid, finding people with the right expertise can be challenging. Even if your project has a long deadline, giving you time to upskill your team, this challenge will arise again each time a team member leaves and you need to onboard a new one. So, consider the time and money you’ll invest in this process.
Strategy 1: Choose a stable framework, check for new version releases, and assess the strength of its community.
Strategy 2: If you still decide to go with a new framework, allocate some project time for developing POCs (Proof of Concepts).
Conclusion
How Cevo can help in your Modernisation
If you are not sure that your platforms require modernisation, or need help to assess your workloads, review licensing, identify potential modernisation pathways, and build a business case for modernisation, reach out to us, with years of experience in the market Cevo Australia will tailor a solution specifically for your requirements.
Alan Terriaga.
AWS Tech Specialist – Modernisation and Cloud Native
