Oracle E-Business Suite (EBS) has proven over the years to be a substantial ingredient in many business organizations. From mission-critical applications to end-to-end workflows for daily tasks, EBS is a powerful ally.
As such, Oracle continues to invest in this flagship product that has a large number of clients. In fact, in November 2022, Oracle announced an important update to the Oracle EBS roadmap, subsequent to the 12.2.12 release, which is the latest release. In its continued investment effort, Oracle has pledged to offer support through at least 2033 via Premier Support.
Ongoing support and investments have proven to be extremely valuable for EBS customers who are continuously receiving new functionality in recent releases, like online patching to reduce downtime, UI improvements, performance enhancements, and other value-add architectural features. As of today, the latest Oracle EBS release is version 12.2.12 which was released back in November 2022.
Still, there are a number of EBS clients who are on the fence about doing the upgrade or feel pressed for time to get it done in time as Oracle announced that EBS instances below release 12.2.X will lose Premier Support at the end of December 2021.
In this hesitation and/or urgency, we can safely say that Oracle EBS 12.2.X brings an array of interesting and groundbreaking innovations, new functionalities, a decrease in costs, and it gives you better tools to ensure business continuity with a competitive edge. By leaving your instance desupported, you would be exposing your system to unwanted costs and security vulnerabilities that threaten the optimal functioning of EBS.
So, what are these risks, costs, and vulnerabilities that you’ll be exposed to by leaving your instance unsupported?
For starters, working with old code can be a real pain point for customers, who right after losing Premier Support, will have their instance considered as a legacy application, no longer receiving new updates, features, or security patches.
Old code is unstable, unreliable, and is somewhat incomprehensible for developers to understand as it grows older. At a point in time, old code has been tweaked, expanded, or patched to heavily that is difficult to maintain, understand, or work with. Most of this old code can have many dependencies that rely on it, causing another issue to your EBS instance as in-house teams will find it increasingly difficult to work in tackling the codebase, and could even risk breaking something bigger in an attempt to fix something.
Now, you might think to yourself that as long as it works, why change something that is giving you a perceived sense of stability? Well, it all might be a mirage in the grand scheme of things as code that is no longer tested and tried can lead to safety issues.
Many organizations end up creating workarounds to pile new fixes on top of legacy code. In a nutshell, after a while, this practice will stop working or will lead to something breaking.
Another critical aspect to consider is the cost of it all. As the EBS platform continues to age, there are inherent costs worth considering. For one, legacy code is not only difficult to work with, it’s also hard to make it compatible to work with other applications. On top of that, legacy code requires significant refactoring to ensure it’s compliant with modern standards, and because of this, many organizations fall into the trap of making no changes to it so as to not mess anything up.
As a result, your code is not modern, only growing outdated and more convoluted by the minute. This lack of modernization leads to added costs as you need to invest resources and time to keep it running optimally. Also, older code typically requires investments in older hardware and systems to run in, driving up your costs as obsolete systems are always harder and more expensive to maintain. So in a way, legacy code is technical debt that you don’t want dragging up your budget through the ground.
When talking about risks, one comes to mind: cyberattacks. Old code is inadvertently more prone to cyberattacks as it is not receiving the latest security patches and updates. Cybercriminals, unlike old code, are increasingly using more sophisticated methods to bypass security thresholds and leaving your code exposed is an important danger to your organization.
More often than we’d like, we’ve heard news about crippling cyberattacks that use ransomware, malware, or any other form of malicious attack to penetrate software systems and syphon money out of them. These sorts of threats thrive in out of date, unsupported systems where it’s easy to not only bypass lax security, but to remain virtually undetectable.
We understand that system upgrade projects are daunting, especially one as critical as the one to EBS R12.2. The process doesn’t come without its challenges but there are more things to gain. We recommend that you download our latest ebook where we detail the four main pitfalls you should avoid when embarking on the Oracle EBS 12.2 upgrade.
There are proven strategies and approaches that you can leverage to ensure your upgrade is a success and that it can be done as efficiently and quickly as possible, so your system is not exposed to the risks of working with an unsupported version of EBS.