I just read this post from an ex-googler, talking about how they tried to move from MySQL to another (presumbely Enterprise. Most likely DB2 or Oracle), and failed. I'll gloss over the fact that they implement such a critical system over a database with no trasaction support (and the comments about "it is easy to add on the application level" that made me cringe so hard that for a moment I looked like a fat bagel).

I want to talk about migrating a single application from one database to another. This is not something that you see done often when you're talking about Line of Business application. Especially not in-house one. But, and this is important, it's both possible and straight-forward in most cases if (and only if) you know something about layering and seperated the database from the rest of your application properly.

If my recent ActiveRecord & NHibernate would ever need to support anything beyond SQL Server, here are the list of steps that I would need to do:

• Create an equivalent schema for the other database (most probably automatically via some tool).
• Research on how the connection string looks like and put it in the config file.
• Re-write a single trigger, which is done in T-SQL for efficently.
• Run the tests against the new database.

Total time that this should take is two days, and I'm including in that the time that it will take me to install the database (even if it's an Oracle) and then learn its SQL deriative.

Now, that is not to say that I might get into places where the application relies on some SQL spesific behavior (identity columns, for instance), or something similar, but those should be isolated incidents. The application itself should move without anything major happening. You know, if I didn't have NHibernate, I would have had to re-write all the queries from scratch, and that might have added a week or so if I had really complex queries (I honestly don't know, NHibernate handles it all). But the application would still not know that anything had happened. The one caveat that may happen is if I needed to port it to something like MySQL 4.0, which doesn't support Transactions, Nested Queries, etc.

This is ABC in application design. The inability to move from one database to the other means that your application relies on way too much on database spesific stuff. There may be reasons for this, but I think that saying something like: "You get what you pay for, and with free you get much more..." is bullshit.