Not just hard, but expensive. The Acquired podcast episode on AWS[1] highlighted a particularly ironic angle of this:
> David: I can do you one better. Another example. Amazon.com used Oracle databases when it was started. Amazon.com did not finish their migration off of Oracle databases and onto AWS products until 2019.
> Ben: Oh, my God.
> David: Thirteen years after AWS launched.
> Ben: That is insane.
> David: It took that long for Amazon itself to migrate off of Oracle.
Anecdotally, from when I worked there in ~2015, there were a few good reasons:
(a) a lot of Amazon's software was so old that it connected directly to the databases. We had to finish all of the SOA migrations that were long overdo -- all the misc random tools no one had gotten around to migrating -- before we could even contemplate moving off Oracle.
(b) it wasn't done as a simple port; instead, the systems were re-architected in the process to no longer share backing databases as at all, which basically meant it needed a complete rewrite, which took a long time to get funded and then a long time to deliver.
No doubt. This was an amusing aside, not a critique, intended to illustrate the long-term impact of storage choices. That's part of the bull-case for AWS long-term, and why we see projects like AWS Snowball.
True. I felt like they were good reasons at the time, or rather that they were basically the best you could do given that the can had been kicked down the road for far too long. As usual putting off solving tech debt ends up costing >10x in total.
> David: I can do you one better. Another example. Amazon.com used Oracle databases when it was started. Amazon.com did not finish their migration off of Oracle databases and onto AWS products until 2019.
> Ben: Oh, my God.
> David: Thirteen years after AWS launched.
> Ben: That is insane.
> David: It took that long for Amazon itself to migrate off of Oracle.
[1]: https://www.acquired.fm/episodes/amazon-web-services