The Critical Need to Modernize Your Infrastructure: Why Delaying Upgrades Puts Your Business at Risk

Why Customers do not Upgrade their Platforms

One can wonder why customers put themselves into this uncomfortable situation and it is most probably a combination of the following:

“If it works, don’t fix it” 

There is a natural resistance to change and maybe even more so in IT. When the infrastructure has been working like a swiss clock for many years and there are real revenues attached to it (as it is the case for API Security which is the center pillar of the application economy), the last thing you want to do is to change it un-necessarily. Hence this tendency to let things work, once deployed and not upgrade or change it. Electricity is provided, backups are made (in best cases) and that’s it. It works, so why fix it?

Not a Priority

Imagine you are in charge of a team and have a budget to manage, with the pressure from end-users constantly looking for new enhancements. You naturally allocate your resources - people and investments - to the latest “shiny toy” to drive revenue streams. Even more so, these days when everybody seems to be rushing - and running around to be fair - to jump on the latest and greatest bandwagon called AI. AI here and AI there … This is where I am going to put my money into and certainly not into that old platform which I know I need to upgrade and modernize. You would also be silly not investing your resources into AI for a couple of good reasons: 1/ there is a promise for rapid return on investment which is great, especially regarding productivity gains; 2/ your management and end-users are knocking at your door asking when your AI platform will be ready. 

So much for planning and working on upgrading an infrastructure that has been working well without any P1 incident, about which no-one complained. It is actually quite a challenge to allocate resources properly these days and the right commercially driven balance needs to be found between short term benefits or into longer term investments.

Security is not Important

A few years ago I decided to leave a company that was doing “API Management” for one that was more focused on “API Security”. It was quite obvious for me that securing APIs (which somehow can be compared to putting the right lock at your house front door) was (and would become) more important than distributing and managing APIs. Back then, my colleagues were saying that security is something really boring, often very complex to get right and actually very few companies allocate the necessary budget to it, unless a damaging incident occurs. As the world in general is becoming more challenged when it comes to cyber-defence, companies have changed their view and approach to security. However, in general, it is still quite true that security does not get the right attention, focus and budget it requires, until typically something goes wrong. 

Integration

API security gateways are proxies between applications consuming APIs and back-ends exposing APIs. It provides key capabilities such as access control management (with a support of a wide range of protocols such as OAuth, JWT, SAML), message transformation, OWASP compliance and cyberthreat management, overall security (schema validation, rate limitations, etc.). A typical scenario is an API security gateway proxying several back-ends (over various protocols - HTTP/S, FTP/S, etc.) and exposing APIs to potentially 100’s of critical applications and millions of end users, using omni-channel devices. And that is really a hurdle to get over when you want to upgrade or modernize your infrastructure as you must have no disruption of service. Of course, this is something standard nowadays but it is one more item that will significantly impact the motivation for upgrading your API Management platform as complexity is often at play and the need to have zero downtime.

The Risks of Postponing Infrastructure Modernization: What You Stand to Lose

The above reasons are all very valid and may put you in a comfortable position … but for a limited time only. Indeed, the more you wait, the more you expose yourself to a likely business-impacting disaster. It will be “panic on-board” and you are likely to face a combination of the challenges outlined below.

The Product is Longer Supported

As with all enterprise solutions, the Layer7 API Security platform is supported for a specific duration. Supporting products has a high associated cost as you need to maintain both the platforms as well as the team knowledge for providing 24/7 customer support. Extended support can be provided under some strict conditions but very rarely at no cost. In actual fact, one can wonder why a solution provider would have to bear the cost for a customer that has been negligent with its infrastructure. 

In case you run a production environment with an unsupported product and call the support for a major issue, you can be assured that your relationship with the solution provider will be complicated and this is the last thing you need when you are facing a crisis.

The High Cost of Non-Compliance

Compliance issues are also something you need to be careful with. Following best practices, IT-OPs are basically advised to avoid running a production platform with unsupported products in a majority of enterprises such as Banking, Pharmaceuticals, etc. In fact, the Digital Operations Risk Assessment (DORA) Act, which took effect in January 2025, effectively demands that financial institutions and their suppliers need to have support frameworks in place for the critical solutions. 

Should something happen, you are likely to expose yourself to monetary consequences, i.e. insurance issues, penalties and - not the least - a significant impact of your company’s brand with a deprecation of your image and confidence level. 

Procrastinating on Infrastructure Upgrades Hurts Your Business

Upgrading an outdated platform is often a much more complicated process than upgrading a supported platform. And the more outdated your platform is, the more difficult - and costly - the upgrade becomes. It is often referred to as a ‘square peg problem, when different version components just are incompatible with one another especially when consuming downstream third party solutions. Also, when you upgrade a supported platform, you basically go to the next (which is usually the latest) supported version. In case you upgrade an unsupported platform, you will need to jump over a couple of versions to have the latest supported one and there come complex hurdles to overcome. The process typically becomes a multi-stage path, which basically means a more complicated project, a longer timeline, and a costlier engagement. 

Enterprises usually have multiple environments (dev, integration, qualification, pre-production, production) and each “hop” in the upgrade path has to be executed throughout each environment. I would draw a parallel here with the discovery of a bug in development or in production. The sooner you discover a bug, the easier and cheaper it is to fix. Same for the platform upgrade: the further you are from the latest version, the longer and more expensive it is to upgrade. 

Losing Expertise When You Don’t Upgrade

People in organisations come and go especially in today’s high turnover IT environments that are often outsourced. This is true both for your organization as well as for your solution provider. How does this relate to your platform modernization? If you are waiting too long before you upgrade your platform it is likely that the people that deployed your platform in your organization are no longer there and have moved either inside (in the best case) or outside your organization.

Alternatively, this problem is compacted further if the deployment of the solution has been performed by a System Integrator. As a result of that, you can expect a significant knowledge loss that will certainly impact the duration it will take to upgrade your platform. This can - of course - get worse if the solution has been significantly customized and poorly documented, as it is often the case. Likewise, your solution may be using some specific product features that have not been carried forward “as is” into more recent versions of the product. As a consequence, a specific upgrade path has to be followed, which only some engineers of your solution provider’s company are aware of. As things often get worse, you can expect these engineers to be gone especially at the time you need this “experience based” knowledge the most.

The Benefits of Upgrading to the Latest Features and Architectures

One of the key considerations of this regular upgrading topic: new product features don't normally get introduced into old product versions. This statement is something we would all agree about … yet, the perspective of missing the latest and greatest features or security patches does not seem to be a strong enough incentive for (some) customers to keep their product and platform up to date. 

The Layer7 API Security platform can be deployed on a variety of form factors - hardware, software, virtual machines and k8s containers. One would agree that hardware deployment is - by far - the least agile and flexible platform compared to containers (actually, the form factor list provided above can be seen as ordered by increased agility and flexibility). Whilst moving to container platforms running on Kubernetes was “something to be tested at some stage” by most organizations a few years ago, it is now a mainstream platform architecture that is being widely adopted. 

However, there is a real ramping-up curve, as well as a knowledge gap to be crossed, given that Kubernetes is a completely new paradigm for today’s complex IT enterprises. This means that if you stay with an old version on an old architecture, you get a triple penalty:

• You don’t get all the flexibility (and the benefits) that a platform architecture like containers on Kubernetes provides;

• You miss new product features, bug fixes, security standards and crypto algorithms, provided by the latest product versions;

• As it takes time to ramp up on new enterprise architecture paradigms, it will take you quite some time before you have the latest version running on a new architecture (up to the point that your operational team is really confident it can run a Kubernetes platform). And by the time you are ready, your competitors are already one step ahead and focusing on the next challenge (which is likely to be AI).