First, a little background to our situation. Several years ago I started an ASP.NET MVC project using LINQ to SQL as the DAL. Being the only developer on the project at the time, I chose to use it because it was pretty well supported in the community and I needed to focus more on the application logic and UI design so I could get it to market. That strategy worked out quite well for us.
It wasn't long, though, until I needed to write some multi-threaded code in a Windows service against the same data store. LINQ to SQL encountered all sorts of problems with crossing threads. Still being the only developer at the time and needing to get this service up quickly, I resorted to duplicating just enough of the DAL and models using POCOs and Enterprise Library. Though not ideal architecture with duplicate models and DAL functionality, it worked well enough and got me through.
That was five years ago. We've been successful with our project to the point where that very success is now a liability not with LINQ or Enterprise Library, but with SQL itself. Now, before anyone suggests that we give our SQL database an overhaul with indexes and all of that, we have done exactly that. We added a DBA on contract and he solved the problem for us. Performance was restored and things were okay. The problem, though is that it requires (in our opinion) too frequent maintenance for our business model and requirements.
Thankfully, Microsoft has stepped up their game with Azure services. Of specific interest to us (we have two developers now), is DocumentDB. In SQL we have several large, flat, busy tables that give some areas of our application severe performance problems when we start to approach the need for DB maintenance. We simply don't have the resources to devote to ongoing maintenance. We've decided to move our application either in part or entirely to DocumentDB. A few proof of concept demos internally tell us that this is a good move for the type of application we have.
If you've read this far, thank you, and here is my question. What would be a good way to migrate the LINQ to SQL classes and generated logic to a DAL backed by DocumentDB? Thankfully, I had the foresight early on to use an IRepository approach such that the application itself won't be impacted, hopefully at all. I'm mostly concerned with all of the "magic" CRUD stuff that the LINQ to SQL design surface coded for me. My other developer and I certainly understand how to write our own DAL code, but we need a quick and consistent approach that takes into account the behavior that the application is coded to expect from having been backed by LINQ to SQL.
My instinct is to basically unwind all of the generated code that LINQ to SQL did for me five years ago and divorce it from the LINQ to SQL designer, add in our own DAL via DI and go from there. My other developer is more advanced than I am on that part of things, so I have a pretty decent amount of confidence that we can get it done. Just hoping somebody out there can help us avoid pitfalls so we can get this done efficiently.
As David Makogon points out in a comment, this question really has no "correct" answer as it is very broad and opinion-based. I'm getting a broad range of suggestions, but nothing I would consider a definitive answer.