“We are just one critical security incident away from a disaster.” This is the statement made by an IT architect who is concerned about his applications. Why was this statement made? A decision was taken at a higher level to put upgrades on hold and focus instead on feature development.
The reasons for this are simply the time and cost involved in such a move. However, this decision carries a significant risk: should a security incident occur, the resulting costs could quickly turn out to be considerably higher than the cost of upgrading to the next version.
What technicians take for granted is often met with a great deal of incomprehension at management level. In this article, I’ll explore the reasons behind a technical upgrade and provide an insight into practical tools that simplify the process.
Contents
- End of support for third-party libraries: identifying risks and taking timely action
- Tools in practice
- Reasons for technical upgrades
- Conclusion
End of support for third-party libraries: identifying risks and taking timely action
Development relies on external libraries, which regularly release new versions. However, these versions are not maintained indefinitely; after a certain period, they are no longer provided with bug fixes and security updates. As soon as a version is no longer within the support window, caution is advised. Companies should therefore develop a strategy at an early stage to determine how to proceed in such cases.
One possible strategy would be to postpone the update and record it as technical debt in order to focus on other issues. However, this comes with the obligation to settle the technical debt at a later date.
Furthermore, commercial enterprise support could be purchased, which is offered by certain external libraries or third-party providers, or the libraries could be updated within the individual applications, thereby ensuring that bug fixes and security updates can continue to be applied.
Tools in practice
To give you a better idea of the possible steps involved in a technical upgrade, I will now look at a specific example – a Spring Boot application with an Angular front end. This involves the use of tools that can carry out upgrades automatically, or at least semi-automatically.
1. Spring Boot Upgrade
Once you have a certain number of applications, it makes sense to use tools for the upgrade. This means that developers can carry out the process not manually, but with the help of tried-and-tested tools, either automatically or semi-automatically. The advantage of this is that, as a result, only a few – and, in the best-case scenario, no – manual steps need to be carried out by the developer to ensure the application is fully migrated. Two of the most effective tools for upgrading Spring applications are as follows:
Spring Application Advisor
Tanzu Spring – the company behind the Spring ecosystem – offers commercial enterprise support. This includes not only extended maintenance for existing Spring versions, but also the Spring Application Advisor: a tool that supports automated upgrades of Spring Boot applications, thereby significantly simplifying modernisation [1] [2].
OpenRewrite
As purchasing an enterprise licence involves high costs, a number of open-source projects have emerged within the community to facilitate the migration of Spring applications. The best-known and most powerful of these is OpenRewrite [3].
2. Angular Upgrade
Angular allows for automatic migrations, but only to the immediately subsequent version at a time. This means that this step must be carried out several times when there are major version jumps. However, if you do not wish to be restricted to the next version, you should take a closer look at Nx [4].
Nx is an extension of the Angular CLI and, amongst other things, supports automatic migrations of Angular applications across multiple version jumps.
It should be noted, however, that the automatic migration is limited to Angular itself and does not automatically update any added dependencies. That said, major dependencies such as NgRx provide their own migration scripts, which enable automatic migration for these packages as well.
The latest Angular versions have introduced additional concepts which, on the one hand, significantly improve the Time to First Paint (TFP) – that is, the point at which the first pixel is rendered – and the First Contentful Paint (FCP) – the moment when visible content first appears. Furthermore, by utilising signals, they enable a substantial performance boost, as unnecessary re-rendering is reduced.
Angular provides dedicated automated migration scripts for each new concept [5]. These handle the majority of the necessary adjustments, although a few manual steps still need to be carried out.
To provide an insight into the technical workflow of a migration process, I have published a blog post. This also discusses the advantages of Signals and explains the areas in which they can be used.
3. Renovate Bot
To ensure that all dependencies are up to date, a tried-and-tested tool called Renovate [6] can be used. This scans all dependencies within an application and attempts to adopt the newer versions. It can be configured to automatically apply minor updates without developers having to approve the changes. In a well-configured CI/CD pipeline, these changes would be deployed directly and end-to-end (E2E) tests would be run before deploying to the next stage. The Renovate bot should only be run on specified days and outside regular operating hours to avoid placing an unnecessary load on the system.
Reasons for technical upgrades
The previous section discussed strategies that companies can employ when carrying out technical upgrades. This section will now look in more detail at postponing upgrades or treating them as technical debt. Technical debt is often only addressed once sufficient budget is available for such a project.
However, this very approach can lead to a critical security vulnerability (CVE) having serious consequences: either the versions are updated in a time-consuming process, the affected version is patched manually, or a paid enterprise licence is purchased at short notice. In such situations, time is a crucial factor – and any delay can prove costly.
This results in an ever-widening gap between the version in use and the latest version still being supported, thereby increasing both the cost of the upgrade and the risk of security vulnerabilities. In addition, this means accepting poorer performance, which is noticeable not only during development but also in production.
In the worst-case scenario, a product upgrade is delayed until the underlying framework or the technology itself is no longer supported. In such cases, there is often no alternative but to migrate the entire application to a modern technology stack – which represents the most labour-intensive and costly form of upgrade. The reason for this is simple: an automated or semi-automated migration is usually no longer possible because there is neither tool support nor sufficient documentation. Instead, a large part of the application has to be redeveloped.
A real-life anecdote: I was at a client meeting discussing the modernisation of a rich-client application. When I asked why this upgrade was being initiated now rather than a few years ago, I was told that the developers familiar with the old technology stack and the code were due to retire soon, and that this was why it had to be done now.
This brings me to the next important point. The maintainability of a product is very much linked to the technology stack used. Newer technology stacks and newer versions of libraries are easier to maintain. If implementing bug fixes and feature requests in an application takes weeks, this is a sign that either technical debt needs to be reduced and/or an upgrade would be advisable. This means that the maintainability of legacy systems is compromised, on the one hand due to a lack of expertise and, on the other, because of the enormous amount of time required to familiarise oneself with old technologies.
Furthermore, the use of legacy technologies does not contribute to developer satisfaction. Outdated documentation, long waiting times in CI/CD pipelines and lengthy build times lead, on the one hand, to frustration amongst developers and, on the other, to a failure to focus on the actual functionality – which is, after all, one of a developer’s main tasks. As a result, it takes longer to develop features.
Anyone wishing to ensure both the performance of their application and a faster time-to-market must recognise that the key to success lies in a modern technology stack combined with a clearly defined upgrade strategy.
Conclusion
Technical upgrades are not a one-off endeavour, but an ongoing process that should be embedded within organisations at an early stage. This is the only way to implement migrations efficiently, either automatically or at least semi-automatically. The longer an upgrade is delayed, the higher not only the costs rise, but also the risk of security vulnerabilities, which could have critical consequences. Tools such as Renovate [7] can provide targeted support for this process – they are easy to integrate and designed to ensure that dependencies are always kept up to date. Furthermore, tools such as OpenRewrite [3] or the migration scripts provided by Angular help to simplify the migration process.
Plan an upgrade strategy at an early stage – otherwise, the only option left as a last resort will be costly redevelopment.
Links
[1] https://enterprise.spring.io/spring-application-advisor
[2] https://www.vmware.com/docs/data-sheet-tanzu-spring-application-advisor
[3] https://docs.openrewrite.org/
[4] https://nx.dev/
[5] https://angular.dev/reference/migrations#
[6] https://docs.renovatebot.com/
Do you have any questions or need assistance?
You can find out more about the possibilities of IT modernisation for your business on our website. Feel free to get in touch with us.
