This is going to be a large and very involved project. I've been responsible for migrating Access databases to .NET many times, but never on this scale. I agree that a gradual approach will probably be the most realistic. Trying to take on everything in one shot is an easy way to fail.
As in other answers, the first and most important step will be to move everything to SQL Server. While doing this, document the database if this hasn't already been done, and identify areas for refactoring if they exist. Access databases that grow to meet evolving needs often have data models that can be improved upon when looking at the big picture.
Next, identify modules of the application that are "self contained". Because this is a do-everything database, there will probably be modules of it that are nearly completely disjoint from each other. After having these disjoint pieces, identify one of the smaller modules that has the most to gain from being updated, and take it on first.
While migrating to .NET, don't just do a simple 1 to 1 copy of the application. Gather input from users to identify pain points with the current application. You want your first migration unit to be a huge success to gain the complete buy in from everyone else.
After you have the first unit done, look at what happened in terms of challenges, difficulties, etc, and use this moving forward.
One thing that I would strongly discourage would be to implement partially working modules (ex: "we migrated the CRM, but features X,Y,Z are not in the new system yet"). This will cause users to quickly become frustrated from having an incomplete system when the old one to them was "perfectly fine". This kind of development may work fine for other domains, but not in businesses where users see "nothing wrong" with the old Access monolith and don't understand the migration needs.
The TPL is a new(ish) framework that provides a simplified API for concurrent programming. The Task-Based Asynchronous Pattern is a framework design guideline that leverages the TPL to deliver consistently designed concurrent operations.
The async/await keywords are syntactic sugar that allow you to consume TAP APIs without diving into the details of continuation.
Best Answer
Comments from a colleague of mine from yesterday regarding this very same topic
Jon Galloway's article from 2005 "//TODONT: Use a Windows Service just to run a scheduled process" is a good read. I suggest that the comments also be read because the discussion still continues till today and provide some good counter-arguments as well.
Personally, I agree with my colleague on this one. Keep it simple for as long as possible. And if you are deploying to Win2008 server, check out the Task scheduler and all the features the standard scheduler offers. For me, the killer was to start a scheduled task when an event occurs.