I did it once. The first step was ditching the ORM and replacing it with a well-defined repository layer. Because the ORM was encouraging interaction with the

I did it once. The first step was ditching the ORM and replacing it with a well-defined repository layer. Because the ORM was encouraging interaction with the database to be scattered everywhere, and that was making it impossible to understand scope of impact. With the data access layer, though, we had a relatively small, clearly defined chunk of code that we could isolate and test, and that made the migration manageable. We didn't need to ditch the ORM, of course. And, at first, we weren't going to. But we saw that, with things so clearly isolated like that, the ORM library wasn't really making the code any easier to understand, so we decided it wasn't really worth the added indirection or the performance cost. I also worked on a product that simultaneously supported two different DBMSes. It didn't use an ORM, either.