With all the database engines available, is there really not another one that can match Oracle without massive customizations?
It's not really "switching relational DBs", it's "rebuilding all of the legacy systems to not use relational DBs". Their scale had long since left the realm where it was reasonable to run everything on massive monolithic DBs, but the technical debt hadn't been paid down -- so they just kept putting more money into bigger and bigger hardware and larger DBA teams to support them. For instance when I last worked the there each warehouse ran on a single massive Oracle DB. That isn't solved by swapping to another database; it was well beyond reasonable.
I suspect that this article seems like a bit of self-promotion but it's actually intended as a giant middle-finger to Oracle.
When they were all cheering, I actually felt bad for Oracle for a nanosecond.
But that is not what happens.
First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer.
Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years.
Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job.
And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks.
And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.
In practise, you want to cheap out on paying for training, have your team do their job and learn an entirely new system to expert level at the same time, the "cool new tech" isn't and your team knows that you're trying to sell it as "cool" to pull a fast one on them because you think they're idiot children, and you won't even commit to using it for long enough to make it worth the bother of trying to learn before changing your mind or prioritising something else, and you're humming and hawing about investing in the tools to make the new tech work well because it's free software so why should it cost you any money?
Besides, you won't prioritise maintenance or design, so the codebase is a mess and people are incentivised towards panic-of-the-day fixes and don't-ever-ever-break-anything conservatism - their fault not yours, obviously, it can't be your fault, you don't even work with the tech (you just choose it by fiat).
Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.
But you'll probably have Forms, Reports, and Apex too. These are all designed to make building an app a piece of cake but make it impossible to migrate except if you rewrite the whole thing.