You definitely sound like you're backpeddling to avoid admitting an error. He was specific. He was clear. He simply mis-stated. And you act as if anyone who believed his mis-statement was the fool.
It can be hard to admit error, I understand.
He specifically said that his 8 weeks of coding only took 8 hours to migrate. If I had not asked any questions, that is the point he would have left this thread with. It was a specific claim, specifically about coding.
He then changed it to 1 week of work, when he realized he had not said what he meant. He admitted his error, and changed his original claim. Yet you can't even admit his original claim was wrong, instead blaming the folks who believed what was said.
As far as multiple DBs, the chaos comes in when you try to centralize all data storage, in my experience. Especially data integrity becomes a nightmare. A monolithic, centralized data store requires a corps of specialized folks to run it. I want the people who use the data to maintain the data, because they're the only ones who know what the data means and when it's bad most of the time.
As I said, as long as the architecture is done right, there is no chaos at all. Everyone can use whatever they want, as long as it supports ODBC.
I'm seeing it all over the industry. It's become the standard.
A "componentized" approach, with each dept using whatever DB 'component' best suits their needs. I don't need for force anyone to use any technology they aren't comfortable with.
In almost every way, the old "integrated" approach to software design is dying out, being replaced by 'componentized' versions. This is just more of that.
As long as the middle-tier uses only standard SQL to communicate with the DBs, it will never have to be changed. Your business logic can work on *any* DB, migrating at will.