What's a good approach for migrating from LINQ to SQL to DocumentDB?

First, a little background to our situation. Several years ago I started an ASP.NET MVC project using LINQ to SQL as DAL. As the only developer on the project at the time, I decided to use it because it was very well supported in the community and I needed to focus more on application logic and interface design so I could get it to market. This strategy has worked out quite well for us.

It was five years ago. We have succeeded in our project to the point that this success is now a commitment not with LINQ or an enterprise library, but with SQL itself. Now, before anyone suggests that we are giving our SQL database an index overhaul and all of this, we did just that. We added the DBA to the contract and he solved the problem for us. Performance was restored and everything was fine. The problem is that it requires, in our opinion, too frequent maintenance of our business model and requirements.

Fortunately, Microsoft has stepped up its game with Azure services. Of particular interest to us (we currently have two developers) is DocumentDB. In SQL, we have several large, flat, busy tables that give some areas of our application serious performance issues when we start to approach the need for database maintenance. We simply don't have the resources to provide ongoing service. We decided to move our application partially or completely to DocumentDB. Several proofs of concept internally tell us that this is a good move for the type of application we have.

If you've read this far, thanks, and here's my question. What would be a good way to migrate LINQ to SQL classes and generated logic to DAL supported by DocumentDB? Fortunately, I used the IRepository approach as a precaution in the past, so the application won't actually be affected. I am most interested in all the "magic" CRUD stuff that for me is tied to the LINQ to SQL design surface. 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 encodes to expect from LINQ to SQL support.

My instinct is to basically expose all the generated code that LINQ to SQL did for me five years ago, and dilute it with a LINQ to SQL designer, add it to our own DAL via DI, and navigate from there. My other developer is more advanced than me on that part of things, so I have pretty decent confidence that we can do this. Just hoping that someone out there can help us avoid mistakes so that we can do it effectively.