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.
Best Answer
We used it in the large corporation where I work. We didn't plan on it from the start of the project but it just worked out that way.
We had an internal project that we developed in .NET, once we got into UAT, the business owner wanted to open the app up to some customers as well as the internal staff. The majority of our external (DMZ) servers are Linux based and the Windows servers that are in the DMZ weren't a good fit (too close to capacity). Instead of buying new hardware someone suggested running the app on Mono. We spent a couple of days doing our own testing and then released the app to QA, then UAT. We had no issues.
If we had been given the requirement at the start of the project, we may not have chosen to write it in .NET, but this was one nice outcome to a very, very late requirement change. Now we're pretty confident that if it came up again we could successfully deploy to Mono (although I would think eventually we'd have to tweak some code, I think we just got lucky).