When Customers Asks: Help Me Move Away From Oracle

A few weeks ago, our REAL (Red Expert Alliance) colleague and friend Lucas Jellema (AMIS - Netherlands) invited us to peer review and co-edit a quite thoughtful and comprehensive article that candidly discusses the nuances and dynamics of this kind of scenario, which might sound familiar to many long-time Oracle partners, especially in the last few years.

Even though the title is quite suggestive, this is not a rant by any stretch of the imagination but a rather down-to-earth writeup that is neither an indictment nor an endorsement of Oracle technology.

Take a look at: Original article from Medium.

The following are some of the most important questions the article poses and tries to answer:

• Are there any common denominators that keep triggering this sentiment among customers?
• What are the foreseeable consequences of acting upon it? Especially when it leads to drastic & potentially de-stabilizing changes within an organization
• What is the best course of action for us as technology advisors when faced with this kind of challenge? How do we steer our customers/companies in the right direction whilst keeping a balanced yet progressive approach?

Summary

With the former questions in mind, let's quickly round up and comment a bit on the answers presented by the article:

The Sentiment

When an organization expresses a wish to "move away from Oracle", it is important to pinpoint exactly what this means and where it is coming from; so, is it the whole business relationship that is going south? Or is it a specific piece of technology that isn't up to expectations?; perhaps the shiny new tools offered by other vendors look much more appealing now that the "honeymoon phase" is long gone, and the old loyalties have inevitably dwindled.

Has Oracle itself played a part in all of this? Quite possibly, yes. On a personal observation (in addition to what has already been discussed at length throughout the article), I must say that in my own experience, companies with high Oracle usage would always associate its technology offering with praises the likes of modern, battle-tested, stable, etc.; however, somewhere along the frantic journey to try & become a major Cloud player, this perception shifted quite violently into not so flattering adjectives such as: buzzword-happy, error-prone, unreliable, hit-or-miss and so on; the good news nowadays is that Oracle really seems to have turned a corner, steadying the ship at last, and improving their self-awareness together with a much better understanding of their strengths, weaknesses and distinct opportunities in both the Hybrid & Cloud Native landscapes. A couple of good examples of the latter are OCI and Autonomous Database, both of which have more than enough measurables to be among the cream of the crop.

For disenchanted customers, it is important to realize that the Oracle train is still going places and, in fact, keeps finding ways to reinvent itself and stay in position as a key player within the technological ecosystem. So even if the good old days are not likely to come back, existing commercial agreements and technological footprints should be seen as assets that can be leveraged through appropriate communication and diligent analysis, regardless of whether our choices eventually lead to continuity or change.

Consequences

It is important to understand that a technology migration will always have a profound impact on the organization at many levels, some of which are apparently easier to measure like, for example, time, cost, acceptable downtime, etc., but others which end up being really hard to gauge and keep under control such as people, processes, and culture.

Making sure you're fully ready and equipped to undergo a transition is also paramount, as major changes will inevitably put the company under a lot of stress for an extended amount of time, especially when it becomes apparent we've reached a point of no return. There are, of course, multiple mitigating factors to all of this, which might bring upon a smoother experience if they are in place, for example, automated testing & continuous deployment capabilities, mature DevOps practices, relevant skills widespread among the team, vendor engagement, external counseling, etc.

So, this kind of decision mustn't be taken lightly or without proper due diligence covering external and internal key aspects. Changing course can be smart and ultimately yield positive results. Still, with the right planning and controlled steps, we are more likely to succeed than by doing an abrupt u-turn that might leave our organization exposed to harmful outcomes whilst struggling to regain control.

Course of Action

For those of us who work in the IT consulting business, one of the best recommendations we can give to our customers (regardless of whether they will be doing a migration or not in the near future) is to conduct periodic evaluations of their architecture and technology stacks. This good practice will help organizations keep an updated roadmap with well-balanced medium-term plans for consolidation, evolution, or deprecation & replacement with viable alternatives. Another argument in favor of continuous evaluation is that market pressure can be unpredictable and rapidly force our hand when we least expect it; that's when the ability to take decisive but informed action (as opposed to reckless & ill-informed choices) can be a game changer.

Sometimes it happens that decision-makers have already made up their mind about changing or replacing the existing technology stack. In this scenario, it is very common for other opportunistic vendors to swoop in, promise the world and go as far as they possibly can in order to sweep the organization off its feet and secure a win. When this is the case, there are two very good pieces of advice:

• Add objectivity to the process by bringing in and seriously considering additional options. A direct comparison pitting your incumbent tools against that new and shiny piece of tech you've become infatuated with will never be a fair game and can lead to biased choices as well as unfortunate omissions, which might prove to be costly in the future.

• Making the business case for continuity is never a waste of time. Even if the final decision seems to be a foregone conclusion, it won't hurt anybody to identify positives, potential benefits, and any other elements the business generally appreciates. The organizational awareness stemming from this kind of exercise is not trivial and carries incredible value.

Conclusions

With all that being said, we can wrap up this discussion by highlighting a couple of quotes from the article, which in my humble opinion, are quite on point:

"Moving away from the problematic state of IT in many organizations makes perfect sense — in order to achieve a situation in which IT can propel the business as it used to do decades ago, when the current legacy situation originated. This undoubtedly means shedding some Oracle products. It may very well involve retaining and even adopting new Oracle technology offerings."

"Replacing technologies or existing software solutions should ideally never be exclusively motivated by emotional or technical or business reasons; a middle way should be found which manages to consider not only cost and technology but also the impact this kind of decision might have on organizational culture, and the people that are the organization."

Thanks for reading!!